[jira] [Created] (CXF-6944) cacerts is loaded while different truststore is specified
David Tarr created CXF-6944:
---
Summary: cacerts is loaded while different truststore is specified
Key: CXF-6944
URL: https://issues.apache.org/jira/browse/CXF-6944
Project: CXF
Issue Type: Improvement
Components: Transports
Affects Versions: 2.7.18
Reporter: David Tarr
Priority: Minor
It seems cxf still loads the cacerts eventhough a different truststore is
specified (programmatically - not via cxf.xml). Could this potentially load to
a security-risk?
When I remove the trusted key from the different truststore, the server is not
trusted and the handshake fails.
{noformat}
2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
configuration file cxf.xml.
2016-06-17 13:45:21,213 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [META-INF/cxf/cxf.xml]
2016-06-17 13:45:21,322 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [cxf.xml]
2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
Creating Service
{http://www.quinity.com/qis/soap/coveragedecisionservice}CoverageDecisionServiceService
from class com.quinity.qis.soap.coveragedecisionservice.CoverageDecisionService
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Tarr updated CXF-6944:
Description:
It seems cxf still loads the cacerts eventhough a different truststore is
specified (programmatically - not via cxf.xml). Could this potentially load to
a security-risk?
When I movethe trusted key from the different truststore to cacerts, the server
is not trusted and the handshake fails. But I have not investigated any further.
{noformat}
2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
configuration file cxf.xml.
2016-06-17 13:45:21,213 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [META-INF/cxf/cxf.xml]
2016-06-17 13:45:21,322 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [cxf.xml]
2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
Creating Service {http://wwwcom/.} from class .
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
...
{noformat}
was:
It seems cxf still loads the cacerts eventhough a different truststore is
specified (programmatically - not via cxf.xml). Could this potentially load to
a security-risk?
When I remove the trusted key from the different truststore, the server is not
trusted and the handshake fails.
{noformat}
2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
configuration file cxf.xml.
2016-06-17 13:45:21,213 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [META-INF/cxf/cxf.xml]
2016-06-17 13:45:21,322 INFO [main]
spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
definitions from class path resource [cxf.xml]
2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
Creating Service
{http://www.quinity.com/qis/soap/coveragedecisionservice}CoverageDecisionServiceService
from class com.quinity.qis.soap.coveragedecisionservice.CoverageDecisionService
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
...
{noformat}
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336020#comment-15336020
]
Colm O hEigeartaigh commented on CXF-6944:
--
Could you attach a code snippet that shows how you are configuring the
truststore?
Colm.
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6945) cxf-wadl2java-plugin wadlRoot configuration parameter typo
Jurrie Overgoor created CXF-6945:
Summary: cxf-wadl2java-plugin wadlRoot configuration parameter typo
Key: CXF-6945
URL: https://issues.apache.org/jira/browse/CXF-6945
Project: CXF
Issue Type: Bug
Components: JAX-RS, Tooling
Affects Versions: 3.1.6
Reporter: Jurrie Overgoor
Priority: Minor
[Line 48 of
WADL2JavaMojo.java|https://fisheye6.atlassian.com/browse/cxf/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/wadlto/WADL2JavaMojo.java?r=68a567632a063c6f9bb27a73c151d21f6e855f50&r=857b55796dc7fc2b302e26d99f84df1712ff9c58&r=5c0ca9032922e8d269901447c70db32a7b75ca1a&r=68a567632a063c6f9bb27a73c151d21f6e855f50#to48]
has a typo. It should be
$\{basedir\}/src/main/resources/wadl
instead of
$\{basedir\}/src/main/resources/wad
Note the missing "l"
Workaround is obvious: include
$\{basedir\}/src/main/resources/wadl
in your configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6938) Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of heap memory
[ https://issues.apache.org/jira/browse/CXF-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336175#comment-15336175 ] RANADEEP SHARMA commented on CXF-6938: -- Hi Sergei, Could you please comment your experiences on performance analysis of the module. I am sure other users must have reported similar issues. I am just trying to get some directions on how to narrow down the scope for trouble-shooting since you guys developed the library. Regards, Ranadeep. > Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of > heap memory > > > Key: CXF-6938 > URL: https://issues.apache.org/jira/browse/CXF-6938 > Project: CXF > Issue Type: Task > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.6 > Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7 >Reporter: RANADEEP SHARMA >Assignee: Sergey Beryozkin > > We have an application with REST client components for making calls to > Backend web services. During our routine performance test, JProfiler tool > shows lots of Bus property entries (with keys named > "bus.providers.set.") populated while creating instances of > ClientProviderFactory. > These Bus property entries seem to stay in heap for the whole duration of the > 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap. > In short, GC doesn't seem to happening frequently enough to keep the heap > usage within limits. > Is this some sort of a bug or, lack of necessary configuration in CXF? > Either ways, we need your guidance for trouble-shooting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6940) Bus Reference nullified pre-maturely in ClientImpl causing Exceptions while processing Responses
[ https://issues.apache.org/jira/browse/CXF-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336428#comment-15336428 ] Dhawalpatel commented on CXF-6940: -- [~dkulp] Agree but one thing I want to point out is - this is the reason we must keep the docs up-to-the date as per the fixes since since 5 years the doc was not updated and thus all the clients might have thought it still being a supported behavior. This is exactly the importance of maintaining product release notes and mentioning the major changes done in the product so that the product can be protected from un-expected changes when the javadoc remained same for 5 years untouched. Anyways, I would not be arguing this more. Maintaining the javadocs and keeping it updated is the key to giving best products. I will be closing this issue. > Bus Reference nullified pre-maturely in ClientImpl causing Exceptions while > processing Responses > > > Key: CXF-6940 > URL: https://issues.apache.org/jira/browse/CXF-6940 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.1.4 > Environment: IBM JDK 1.7, Apache CXF installed as resource Adapter on > IBM WebSphere 8.5.5.3 on RHEL 6.0 >Reporter: Dhawalpatel >Priority: Critical > > Hi Daniel, > Test Scenario: > Install CXF as Resource Adapter in J2EE Container and use below code to call > a JAX-WS API. > /* Lookup Resource Adapter of JCA and get COnnection*/ > CXFConnectionFactory connectionFactory = getCXFConnectionFactory(portClass); >CXFConnectionSpec connectionSpec = createCXFConnectionSpec(portClass, > serviceName, portName, webServiceDefinition); > /* Get the Port from JCA Connection pool*/ > connection = connectionFactory.getConnection(connectionSpec); >port = connection.getService(portClass); > /* Close the JCA Connection*/ > if(connection != null) > connection.close(); > /*WebService call*/ > port.getAccount(); > Description: > When a JCA Connection pool eviction happens due to Max Connections reached > state, the existing on-going outgoing JAX-WS Calls errors out with below > exception: > Message received on a Client that has been closed or destroyed. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:86) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:58) > at java.lang.reflect.Constructor.newInstance(Constructor.java:542) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1376) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1365) > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56) > at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215) > at > org.apache.cxf.io.AbstractWrappedOutputStream.close(AbstractWrappedOutputStream.java:77) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:520) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:429) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:283) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139) > at com.sun.proxy.$Proxy106.inquireWirelinePaymentPlan(Unknown Source) > at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at AppAdapter.executeWebService(AppAdapter.java:702) > > Caused by: > java.lang.IllegalStateException: Message received on a Client that has been > closed or destroyed. > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:707) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:15
[jira] [Created] (CXF-6946) Part ServiceException defined as element {http://exception.service.disney.com/}ServiceException which is not in the schema.
Dinesh created CXF-6946:
---
Summary: Part ServiceException defined as element
{http://exception.service.disney.com/}ServiceException which is not in the
schema.
Key: CXF-6946
URL: https://issues.apache.org/jira/browse/CXF-6946
Project: CXF
Issue Type: Bug
Environment: CXF 2.1.3
Reporter: Dinesh
Intermittently getting error at runtime while calling webservice. Here is the
ful exception trace
---
Caused by: javax.faces.FacesException: Cant instantiate class:
com.wdw.pms.web.controller.housekeeping.H2UIController.. Error creating bean
with name 'HousekeepingAdminService' defined in class path resource
[required-service-ioc-web.xml]: Cannot resolve reference to bean
'HousekeepingAdminTarget' while setting bean property 'target'; nested
exception is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'HousekeepingAdminTarget' defined in class path
resource [required-service-ioc-web.xml]: Instantiation of bean failed; nested
exception is org.springframework.beans.factory.BeanDefinitionStoreException:
Factory method [public java.lang.Object
com.wdw.pms.web.facade.PMSServiceAdapter.getService()] threw exception; nested
exception is org.apache.cxf.wsdl11.WSDLRuntimeException: Part ServiceException
defined as element {http://exception.service.disney.com/}ServiceException which
is not in the schema.
at
com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:282)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:527)
... 108 more
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'HousekeepingAdminService' defined in class path
resource [required-service-ioc-web.xml]: Cannot resolve reference to bean
'HousekeepingAdminTarget' while setting bean property 'target'; nested
exception is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'HousekeepingAdminTarget' defined in class path
resource [required-service-ioc-web.xml]: Instantiation of bean failed; nested
exception is org.springframework.beans.factory.BeanDefinitionStoreException:
Factory method [public java.lang.Object
com.wdw.pms.web.facade.PMSServiceAdapter.getService()] threw exception; nested
exception is org.apache.cxf.wsdl11.WSDLRuntimeException: Part ServiceException
defined as element {http://exception.service.disney.com/}ServiceException which
is not in the schema.
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:269)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:109)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1099)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:861)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:421)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:270)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:733)
at
com.disney.service.ioc.ServiceFactory.getService(ServiceFactory.java:77)
at
com.wdw.pms.web.facade.housekeeping.AdminServiceFacade.getService(AdminServiceFacade.java:58)
at
com.wdw.pms.web.facade.housekeeping.AdminServiceFacade.retrieveCurrentDate(AdminServiceFacade.java:572)
at
com.wdw.pms.web.controller.housekeeping.H2UIController.intialize(H2UIController.java:275)
at
com.wdw.pms.web.controller.housekeeping.H2UIController.(H2UIController.java:198)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:379)
at
com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:277)
... 109 more
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'HousekeepingAdminTarget' defined in class path
resou
