Issues with Attachments: week of 2012-10-22
CXF - Monday, October 22, 2012 9 Issues with Attachments (sorted oldest to newest) [CXF-4524] Large request causes socket timeout on subsequent requests on WebLogic hosted service - Created: 2012-09-27 - Updated: 2012-09-27 - Type: Bug - Fix Versions: [] - Reporter: Chris Pimlott - Assigned: Unassigned - Attachments: [stacktrace.client.txt, stacktrace.weblogic.txt, weblogic-socketTimeoutBug.zip] - https://issues.apache.org/jira/browse/CXF-4524 [CXF-4534] SortedMap is returned as HashMap - Created: 2012-10-02 - Updated: 2012-10-16 - Type: Bug - Fix Versions: [] - Reporter: Vassilis Virvilis - Assigned: Daniel Kulp - Attachments: [ws-test-issue-4534.tgz] - https://issues.apache.org/jira/browse/CXF-4534 [CXF-4575] Could not find any node with XPath expression - Created: 2012-10-16 - Updated: 2012-10-17 - Type: Bug - Fix Versions: [] - Reporter: Osmar Miraval - Assigned: Unassigned - Attachments: [Order.xsd, WSOrder.wsdl] - https://issues.apache.org/jira/browse/CXF-4575 [CXF-4577] Support EHCACHE 2.5.2+ - Created: 2012-10-17 - Updated: 2012-10-17 - Type: Improvement - Fix Versions: [] - Reporter: Jason Pell - Assigned: Unassigned - Attachments: [EhCacheIssue.tar.gz] - https://issues.apache.org/jira/browse/CXF-4577 [CXF-4583] When the logical handler return false processing the outbound message, the SoapMessage's body is always empty. - Created: 2012-10-19 - Updated: 2012-10-22 - Type: Bug - Fix Versions: [] - Reporter: Yi Xiao - Assigned: Willem Jiang - Attachments: [CXF-4853.patch] - https://issues.apache.org/jira/browse/CXF-4583 [CXF-4587] Signature Confirmation does not work with TransportBinding and EndorsingSupportingToken - Created: 2012-10-19 - Updated: 2012-10-19 - Type: Bug - Fix Versions: [] - Reporter: Sunil Bapat - Assigned: Unassigned - Attachments: [patch.txt] - https://issues.apache.org/jira/browse/CXF-4587 [CXF-4588] cxf-codegen-plugin: Error resolving component - Created: 2012-10-19 - Updated: 2012-10-19 - Type: Bug - Fix Versions: [] - Reporter: Chris Phillipson - Assigned: Unassigned - Attachments: [spp-im-mui-ws-api.zip] - https://issues.apache.org/jira/browse/CXF-4588 [CXF-4590] STSUtils: DRY refactoring and support Soap12 via property - Created: 2012-10-21 - Updated: 2012-10-21 - Type: Improvement - Fix Versions: [] - Reporter: Andrei Shakirin - Assigned: Unassigned - Attachments: [STSSoap12.patch] - https://issues.apache.org/jira/browse/CXF-4590 [CXF-4591] Fix @XmlTransient handling for exception types - Created: 2012-10-22 - Updated: 2012-10-22 - Type: Bug - Fix Versions: [2.4.11, 2.5.7, 2.6.4, 2.7.1] - Reporter: Richard Opalka - Assigned: Unassigned - Attachments: [CXF4591.patch] - https://issues.apache.org/jira/browse/CXF-4591
[jira] [Commented] (DOSGI-66) The DSW only loads the intent map when certain spring bundles are loaded and started upfront
[ https://issues.apache.org/jira/browse/DOSGI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481258#comment-13481258 ] Christian Schneider commented on DOSGI-66: -- I was really confused when I saw that the spring config was only used to initialize an Activator. We should document such side effects so people know we need the spring config. For the future I would like to remove the spring dependency again. Is there any drawback when I try to load the xml intent file without spring? > The DSW only loads the intent map when certain spring bundles are loaded and > started upfront > > > Key: DOSGI-66 > URL: https://issues.apache.org/jira/browse/DOSGI-66 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.1, 1.2 >Reporter: Marc Schaaf >Assignee: Marc Schaaf > Fix For: 1.2 > > > The DSW loads the intent map via Spring from an XML file. For this import it > needs access to some namespace handlers that are provided by the CXF bundle. > If the Spring OSGi Extender bundles are not completely started before the DSW > tries to load the map, the loading fails as the namespace handlers are not > found. > A possible solution would be to change the startup of the DSW from the OSGi > activator to Spring. This way the DSW would be started by the Spring OSGi > Extender bundles once they are ready and the DSW could successfully load the > map. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4587) Signature Confirmation does not work with TransportBinding and EndorsingSupportingToken
[ https://issues.apache.org/jira/browse/CXF-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-4587: - Affects Version/s: 2.5.6 2.7.0 Fix Version/s: 2.7.1 2.6.4 2.5.7 > Signature Confirmation does not work with TransportBinding and > EndorsingSupportingToken > --- > > Key: CXF-4587 > URL: https://issues.apache.org/jira/browse/CXF-4587 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.6.2, 2.5.6, 2.7.0 >Reporter: Sunil Bapat >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: patch.txt > > > This is based on the discussion in > http://cxf.547215.n5.nabble.com/TransportBinding-and-SignatureConfirmation-td5715655.html. > > Signature Confirmation does not work on the client side, when the web service > is secured by TransportBinding with EndorsingSupportingToken. > The response from the server contains a Signature Confirmation element, and > the response fails with the error: > Received a SignatureConfirmation element, but there are no stored signature > values > Debugging through the CXF code, here's what is happening: > - After configuring the client, the WSS11Builder calls > setRequireSignatureConfirmation(true) based on the policy > (). > - In the constructor of AbstractBindingBuilder, it initializes the signatures > array property with an empty array, and puts it in the message as follows: > message.getExchange().put(WSHandlerConstants.SEND_SIGV, signatures) > - In the TransportBindingHandler.handleEndorsingToken (line 300), it calls > addSig, which eventually calls the doSignature. However, the signature is > never added to the signatures array. (SymmetricBindingHandler and > AsymmetricBindingHandler do a signatures.add) > - As a result when the service response comes to the WSS4JInInterceptor, it > calls checkSignatureConfirmation in WSHandler, which retrieves the > savedSignatures using > List savedSignatures = > (List) getProperty(reqData.getMsgContext(), > WSHandlerConstants.SEND_SIGV); > - This array is empty, since the signature was never added by > TransportBindingHandler. Therefore it throws the above exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4587) Signature Confirmation does not work with TransportBinding and EndorsingSupportingToken
[ https://issues.apache.org/jira/browse/CXF-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-4587: Assignee: Colm O hEigeartaigh > Signature Confirmation does not work with TransportBinding and > EndorsingSupportingToken > --- > > Key: CXF-4587 > URL: https://issues.apache.org/jira/browse/CXF-4587 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.6.2, 2.5.6, 2.7.0 >Reporter: Sunil Bapat >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: patch.txt > > > This is based on the discussion in > http://cxf.547215.n5.nabble.com/TransportBinding-and-SignatureConfirmation-td5715655.html. > > Signature Confirmation does not work on the client side, when the web service > is secured by TransportBinding with EndorsingSupportingToken. > The response from the server contains a Signature Confirmation element, and > the response fails with the error: > Received a SignatureConfirmation element, but there are no stored signature > values > Debugging through the CXF code, here's what is happening: > - After configuring the client, the WSS11Builder calls > setRequireSignatureConfirmation(true) based on the policy > (). > - In the constructor of AbstractBindingBuilder, it initializes the signatures > array property with an empty array, and puts it in the message as follows: > message.getExchange().put(WSHandlerConstants.SEND_SIGV, signatures) > - In the TransportBindingHandler.handleEndorsingToken (line 300), it calls > addSig, which eventually calls the doSignature. However, the signature is > never added to the signatures array. (SymmetricBindingHandler and > AsymmetricBindingHandler do a signatures.add) > - As a result when the service response comes to the WSS4JInInterceptor, it > calls checkSignatureConfirmation in WSHandler, which retrieves the > savedSignatures using > List savedSignatures = > (List) getProperty(reqData.getMsgContext(), > WSHandlerConstants.SEND_SIGV); > - This array is empty, since the signature was never added by > TransportBindingHandler. Therefore it throws the above exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4583) When the logical handler return false processing the outbound message, the SoapMessage's body is always empty.
[ https://issues.apache.org/jira/browse/CXF-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481266#comment-13481266 ] Willem Jiang commented on CXF-4583: --- Hi Xiao Yi, Thanks for reporting it and providing the patch. I did some changed on the patch and also added an unit test to verify the patch. Please try out the latest SNAPSHOT for verification. Willem > When the logical handler return false processing the outbound message, the > SoapMessage's body is always empty. > -- > > Key: CXF-4583 > URL: https://issues.apache.org/jira/browse/CXF-4583 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.6.2 >Reporter: Yi Xiao >Assignee: Willem Jiang > Labels: handler > Attachments: CXF-4853.patch > > > According to the spec, when return false: > Normal message processing stops, close is called on each previously invoked > handler in the chain, the message is dispatched. > So the message returned by endpoint should be dispatched to client, not > always the empty body element. > In my case, the endpoint has built the soapMessage: > http://schemas.xmlsoap.org/soap/envelope/";> > > > xmlns:ns2="http://jaxws.samples.ibm.com/";> > 116 > > > > but the client receives： > http://schemas.xmlsoap.org/soap/envelope/";> > > > > I find the LogicalHandlerOutInterceptor does not set the SoapMessage correct > when the logicalHandler return false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4590) STSUtils: DRY refactoring and support Soap12 via property
[ https://issues.apache.org/jira/browse/CXF-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-4590: - Affects Version/s: 2.5.6 2.6.3 2.7.0 Fix Version/s: 2.7.1 2.6.4 2.5.7 > STSUtils: DRY refactoring and support Soap12 via property > - > > Key: CXF-4590 > URL: https://issues.apache.org/jira/browse/CXF-4590 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.5.6, 2.6.3, 2.7.0 >Reporter: Andrei Shakirin >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: STSSoap12.patch > > > Hi, > Actually if STSClient uses direct location (not a WSDL) to communicate with > STS, it is not very easy to switch binding to SOAP 1.2. Only the way is > create STSClient in own interceptor, set the binding and put client in > message property SecurityConstants.STS_CLIENT. > Proposal: introduce boolean contextual message property to switch STSClient > to SOAP 1.2 binding (ws-security.sts.client-soap12-binding). > Additionally patch contains small DRY refactoring for STSUtils.getClient() > methods. > Regards, > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4590) STSUtils: DRY refactoring and support Soap12 via property
[ https://issues.apache.org/jira/browse/CXF-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-4590: Assignee: Colm O hEigeartaigh > STSUtils: DRY refactoring and support Soap12 via property > - > > Key: CXF-4590 > URL: https://issues.apache.org/jira/browse/CXF-4590 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.5.6, 2.6.3, 2.7.0 >Reporter: Andrei Shakirin >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: STSSoap12.patch > > > Hi, > Actually if STSClient uses direct location (not a WSDL) to communicate with > STS, it is not very easy to switch binding to SOAP 1.2. Only the way is > create STSClient in own interceptor, set the binding and put client in > message property SecurityConstants.STS_CLIENT. > Proposal: introduce boolean contextual message property to switch STSClient > to SOAP 1.2 binding (ws-security.sts.client-soap12-binding). > Additionally patch contains small DRY refactoring for STSUtils.getClient() > methods. > Regards, > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4592) Some tests fail when CachedOutputStream's file caching is enforced
Aki Yoshida created CXF-4592: Summary: Some tests fail when CachedOutputStream's file caching is enforced Key: CXF-4592 URL: https://issues.apache.org/jira/browse/CXF-4592 Project: CXF Issue Type: Bug Components: Core, JAX-RS, Transports Reporter: Aki Yoshida Assignee: Aki Yoshida When the entire CXF build is executed with the CachedOutputStream's file caching mode practically enforeced (using -Dorg.apache.cxf.io.CachedOutputStream.Threahold=8), there are test errors in rt/transport/local systests/ws-rm systests/transports systests/jaxrs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DOSGI-118) Make Spring only as an optional dependency for DSW
[ https://issues.apache.org/jira/browse/DOSGI-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-118: - Assignee: Christian Schneider > Make Spring only as an optional dependency for DSW > -- > > Key: DOSGI-118 > URL: https://issues.apache.org/jira/browse/DOSGI-118 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Balazs Zsoldos >Assignee: Christian Schneider > > Due to issue DOSGI-66 the Activator of DSW was made to be Spring based. My > problem is that I wanted to use only the JAX-RS feature that does not need > spring in an OSGI container. Because of the change in the mentioned issue > Spring becomes a hard wired dependency of DSW. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4590) STSUtils: DRY refactoring and support Soap12 via property
[ https://issues.apache.org/jira/browse/CXF-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4590. -- Resolution: Fixed > STSUtils: DRY refactoring and support Soap12 via property > - > > Key: CXF-4590 > URL: https://issues.apache.org/jira/browse/CXF-4590 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.5.6, 2.6.3, 2.7.0 >Reporter: Andrei Shakirin >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: STSSoap12.patch > > > Hi, > Actually if STSClient uses direct location (not a WSDL) to communicate with > STS, it is not very easy to switch binding to SOAP 1.2. Only the way is > create STSClient in own interceptor, set the binding and put client in > message property SecurityConstants.STS_CLIENT. > Proposal: introduce boolean contextual message property to switch STSClient > to SOAP 1.2 binding (ws-security.sts.client-soap12-binding). > Additionally patch contains small DRY refactoring for STSUtils.getClient() > methods. > Regards, > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4587) Signature Confirmation does not work with TransportBinding and EndorsingSupportingToken
[ https://issues.apache.org/jira/browse/CXF-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4587. -- Resolution: Fixed > Signature Confirmation does not work with TransportBinding and > EndorsingSupportingToken > --- > > Key: CXF-4587 > URL: https://issues.apache.org/jira/browse/CXF-4587 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.6.2, 2.5.6, 2.7.0 >Reporter: Sunil Bapat >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.5.7, 2.6.4, 2.7.1 > > Attachments: patch.txt > > > This is based on the discussion in > http://cxf.547215.n5.nabble.com/TransportBinding-and-SignatureConfirmation-td5715655.html. > > Signature Confirmation does not work on the client side, when the web service > is secured by TransportBinding with EndorsingSupportingToken. > The response from the server contains a Signature Confirmation element, and > the response fails with the error: > Received a SignatureConfirmation element, but there are no stored signature > values > Debugging through the CXF code, here's what is happening: > - After configuring the client, the WSS11Builder calls > setRequireSignatureConfirmation(true) based on the policy > (). > - In the constructor of AbstractBindingBuilder, it initializes the signatures > array property with an empty array, and puts it in the message as follows: > message.getExchange().put(WSHandlerConstants.SEND_SIGV, signatures) > - In the TransportBindingHandler.handleEndorsingToken (line 300), it calls > addSig, which eventually calls the doSignature. However, the signature is > never added to the signatures array. (SymmetricBindingHandler and > AsymmetricBindingHandler do a signatures.add) > - As a result when the service response comes to the WSS4JInInterceptor, it > calls checkSignatureConfirmation in WSHandler, which retrieves the > savedSignatures using > List savedSignatures = > (List) getProperty(reqData.getMsgContext(), > WSHandlerConstants.SEND_SIGV); > - This array is empty, since the signature was never added by > TransportBindingHandler. Therefore it throws the above exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-117) Stopping single bundle distribution hits NPE at org.apache.felix.cm.impl.ConfigurationManager.stop line: 267
[ https://issues.apache.org/jira/browse/DOSGI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481292#comment-13481292 ] Christian Schneider commented on DOSGI-117: --- Felix config admin 1.4.0 is now in central > Stopping single bundle distribution hits NPE at > org.apache.felix.cm.impl.ConfigurationManager.stop line: 267 > > > Key: DOSGI-117 > URL: https://issues.apache.org/jira/browse/DOSGI-117 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 > Environment: CXF single bundle distribution 1.3.0 > ZooKeeper 3.4.3 > java version "1.6.0_29" > Mac OS X 10.7.3 >Reporter: Glyn Normington > > The following NPE occurs in Felix Config Admin when stopping the single > bundle distribution of CXF dosgi. It seems likely that the NPE will be fixed > by FELIX-2813 which was implemented in Felix Config Admin 1.4.0, so the fix > to this bug is to upgrade Felix Config Admin to 1.4.0. > Daemon Thread [Thread-34] (Suspended (exception > java.lang.NullPointerException)) > > org.apache.felix.cm.impl.ConfigurationManager.stop(org.osgi.framework.BundleContext) > line: 267 > > org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stopEmbeddedActivators(org.osgi.framework.BundleContext) > line: 137 > > org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stop(org.osgi.framework.BundleContext) > line: 51 > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run() > line: 771 > > java.security.AccessController.doPrivileged(java.security.PrivilegedExceptionAction) > line: not available [native method] > org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop() line: > 764 > org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(int) > line: 510 > > org.eclipse.osgi.framework.internal.core.BundleHost(org.eclipse.osgi.framework.internal.core.AbstractBundle).stop(int) > line: 464 > org.apache.felix.gogo.command.Basic.stop(boolean, > org.osgi.framework.Bundle[]) line: 817 > sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, > java.lang.Object, java.lang.Object[]) line: not available [native method] > > sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 39 > sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 25 > java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) > line: 597 > > org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, > java.lang.Object, java.lang.String, java.util.List) line: > 136 > > org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 82 > org.apache.felix.gogo.runtime.Closure.executeCmd(java.lang.String, > java.util.List) line: 469 > > org.apache.felix.gogo.runtime.Closure.executeStatement(java.util.List) > line: 395 > org.apache.felix.gogo.runtime.Pipe.run() line: 108 > > org.apache.felix.gogo.runtime.Closure.execute(java.util.List) > line: 183 > > org.apache.felix.gogo.runtime.Closure.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 120 > > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(java.lang.CharSequence) > line: 89 > org.apache.felix.gogo.shell.Console.run() line: 62 > > org.apache.felix.gogo.shell.Shell.console(org.apache.felix.service.command.CommandSession) > line: 203 > > org.apache.felix.gogo.shell.Shell.gosh(org.apache.felix.service.command.CommandSession, > java.lang.String[]) line: 128 > sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, > java.lang.Object, java.lang.Object[]) line: not available [native method] > > sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 39 > sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 25 > java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) > line: 597 > > org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, > java.lang.Object, java.lang.String, java.util.List) line: > 136 > > org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 82 > org.apache.felix.gogo.runtime.Closure.executeCmd(java.lang.String, > java.util.List) line: 469
[jira] [Resolved] (DOSGI-59) Required service properties for autodiscovery using Zookeeper are automatically removed
[
https://issues.apache.org/jira/browse/DOSGI-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-59.
--
Resolution: Cannot Reproduce
Fix Version/s: 1.3.1
Assignee: Christian Schneider
Can not reproduce with 1.3.1. I can export and import services using zookeeper
based discovery. Can you check with the current version?
> Required service properties for autodiscovery using Zookeeper are
> automatically removed
>
>
> Key: DOSGI-59
> URL: https://issues.apache.org/jira/browse/DOSGI-59
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Discovery
>Affects Versions: 1.1
>Reporter: Christian Marmolejo
>Assignee: Christian Schneider
> Fix For: 1.3.1
>
>
> Server side: service S exported under interface X (using DOSGi 1.1)
> Client side: Zookeeper configured and running properly + ServiceTracker for
> interface X trying to consume remote service
> Problem: Local framework on client side doesn't create a proxy for remote
> service S
> Observations:
> - When publishing service S on server side, method
> OsgiUtils.flattenServiceDescription(...) invoked by
> CxfPublishHook.publishEndpoint(...) removes property
> Constants.EXPORTED_INTERFACES in respective ServicePublication registration.
> This service is published in Zookeeper server.
> - Node created correctly in Zookeeper server with every original property but
> without Constants.EXPORTED_INTERFACES.
> - On client side, after starting Service Tracker, Zookeeper node is detected.
> In method AbstractClientHook.processNotification(...) a property check code
> is executed:
> ServiceEndpointDescription sd = notification.getServiceEndpointDescription();
> if ((sd.getProperty(Constants.EXPORTED_INTERFACES) == null) &&
> (sd.getProperty(Constants.EXPORTED_INTERFACES_OLD) == null)) {
> return; //LINE ALWAYS REACHED
> }
> //...PROXY CREATION CODE
> just before invoking proxy creation code
> (AbstractClientHook.proxifyMatchingInterface(...)). This code is never
> reached because the Endpoint description doesn't contain either property
> Constants.EXPORTED_INTERFACES or Constants.EXPORTED_INTERFACES_OLD, that were
> removed automatically on server side. The proxy for service S is never
> created on client side. If this check code is removed, proxy is created
> properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-126) Allow to use the servlet transport with automatic discovery
Christian Schneider created DOSGI-126: - Summary: Allow to use the servlet transport with automatic discovery Key: DOSGI-126 URL: https://issues.apache.org/jira/browse/DOSGI-126 Project: CXF Distributed OSGi Issue Type: Improvement Components: Discovery Affects Versions: 1.3.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.4 Currently you can use org.apache.cxf.ws.address = /MyService already. This specifies that you want to use the servlet transport. The complete uri would then be : http://servername:port/cxf/MyService Where "cxf" is symbolic for where the servlet transport registers itself. The problem is that we send the /MyService address to zookeeper which results in a strange entry with -1 as port. Of course this address is then quite useless for other containers. So I think what we could do is define a variable in the config admin pid cxf-dsw: servletPrefix: http://myserver:8080/cxf This could then be prepended to any servlet address we find. So zookeeper will be happy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-58) Better handling for port conflicts when using property org.apache.cxf.rs.address
[ https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481301#comment-13481301 ] Christian Schneider commented on DOSGI-58: -- We could add this behaviour to CXF (not CXF DOSGi). I propose a different solution though. In CXF you can specify to use the servlet transport using a url without server and port. So I would rather use this syntax instead of using the same port as the HTTPService. Basically I think using servlet transport is the cleaner way anyway as you do not have to care about ports then. Currently servlet transport can not be used with zookeeper based discovery though as it will not publish an address that can be used from another system. I will create an issue that should solve this. > Better handling for port conflicts when using property > org.apache.cxf.rs.address > > > Key: DOSGI-58 > URL: https://issues.apache.org/jira/browse/DOSGI-58 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: REST >Affects Versions: 1.1 >Reporter: Daniel Bimschas >Priority: Minor > Labels: configuration > > Below is an exception from the mailing list thread that describes the > issue... (reverse order!) > I seePerhaps it could recognize that a conflict will occur and print a > more meaningful exception message advising users to use a context property. > If DOSGI will try to silently attach the endpoint to a paxweb-enabled > HttpService then it might become complicated (paxweb may not be installed in > case of multibindle distro) or a user might've used the explicit address > exactly because a standalone jetty were expected to start, etc... > Can you please open a JIRA in a DOSGI subproject so that we can track this > issue and discuss how to fix it ? > thanks, Sergey > - Original Message - From: "Daniel Bimschas" > > To: > Sent: Friday, February 05, 2010 3:07 PM > Subject: Re: DOSGi and JSON responses > Oh, I know of the org.osgi.service.http.port value that lets Pax Web start > it's Jetty instance on 8080 per default. I tried to say that users of DOSGI > (especially newbies) would certainly expect that using > "org.apache.cxf.rs.address" would work nevertheless by simply using the same > port (i.e. if there's no web context conflict). > I guess that some DOSGI (or CXF) bundle which is responsible for registering > the JAX-RS servlet to some Jetty instance could surely check if there's a > servlet container instance running on the desired port and reusing that > instance... > Daniel > Am 05.02.2010 um 15:56 schrieb Sergey Beryozkin: > Hi > This can be easily fixed AFAIK, I can't recall the name of the paxweb > property but you can ensure its Httpservice occupies some other port...Just > checked in ServiceMix, it is > org.osgi.service.http.port=8181, > add it to felix/etc/config.properties. etc > cheers, Sergey > Sergey, > I just stumbled over another issue that may annoy DOSGI users. If you start > the single bundle distribution (no idea if it's the same with multi bundle) > it starts a Jetty on localhost:8080 which should be usable like a OSGi > compendium HTTP service (that's what I understood at least). Now if one uses > the JAX-RS stuff and registers it's instance with the > "org.apache.cxf.rs.address" property he will have to choose a port other than > 8080 or he'll get the following exception: > WARNUNG: WARNING : Problem creating a remote endpoint for > de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource from CXF > PublishHook, reason is null > org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:114) > at > org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:129) > at > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80) > at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:637) > Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty server: > Address already in use > at > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:339) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:157)
[jira] [Comment Edited] (DOSGI-58) Better handling for port conflicts when using property org.apache.cxf.rs.address
[ https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481301#comment-13481301 ] Christian Schneider edited comment on DOSGI-58 at 10/22/12 11:11 AM: - We could add this behaviour to CXF (not CXF DOSGi). I propose a different solution though. In CXF you can specify to use the servlet transport using a url without server and port. So I would rather use this syntax instead of using the same port as the HTTPService. Basically I think using servlet transport is the cleaner way anyway as you do not have to care about ports then. Currently servlet transport can not be used with zookeeper based discovery though as it will not publish an address that can be used from another system. See the linked issue. Would that be good enough? was (Author: ch...@die-schneider.net): We could add this behaviour to CXF (not CXF DOSGi). I propose a different solution though. In CXF you can specify to use the servlet transport using a url without server and port. So I would rather use this syntax instead of using the same port as the HTTPService. Basically I think using servlet transport is the cleaner way anyway as you do not have to care about ports then. Currently servlet transport can not be used with zookeeper based discovery though as it will not publish an address that can be used from another system. I will create an issue that should solve this. > Better handling for port conflicts when using property > org.apache.cxf.rs.address > > > Key: DOSGI-58 > URL: https://issues.apache.org/jira/browse/DOSGI-58 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: REST >Affects Versions: 1.1 >Reporter: Daniel Bimschas >Priority: Minor > Labels: configuration > > Below is an exception from the mailing list thread that describes the > issue... (reverse order!) > I seePerhaps it could recognize that a conflict will occur and print a > more meaningful exception message advising users to use a context property. > If DOSGI will try to silently attach the endpoint to a paxweb-enabled > HttpService then it might become complicated (paxweb may not be installed in > case of multibindle distro) or a user might've used the explicit address > exactly because a standalone jetty were expected to start, etc... > Can you please open a JIRA in a DOSGI subproject so that we can track this > issue and discuss how to fix it ? > thanks, Sergey > - Original Message - From: "Daniel Bimschas" > > To: > Sent: Friday, February 05, 2010 3:07 PM > Subject: Re: DOSGi and JSON responses > Oh, I know of the org.osgi.service.http.port value that lets Pax Web start > it's Jetty instance on 8080 per default. I tried to say that users of DOSGI > (especially newbies) would certainly expect that using > "org.apache.cxf.rs.address" would work nevertheless by simply using the same > port (i.e. if there's no web context conflict). > I guess that some DOSGI (or CXF) bundle which is responsible for registering > the JAX-RS servlet to some Jetty instance could surely check if there's a > servlet container instance running on the desired port and reusing that > instance... > Daniel > Am 05.02.2010 um 15:56 schrieb Sergey Beryozkin: > Hi > This can be easily fixed AFAIK, I can't recall the name of the paxweb > property but you can ensure its Httpservice occupies some other port...Just > checked in ServiceMix, it is > org.osgi.service.http.port=8181, > add it to felix/etc/config.properties. etc > cheers, Sergey > Sergey, > I just stumbled over another issue that may annoy DOSGI users. If you start > the single bundle distribution (no idea if it's the same with multi bundle) > it starts a Jetty on localhost:8080 which should be usable like a OSGi > compendium HTTP service (that's what I understood at least). Now if one uses > the JAX-RS stuff and registers it's instance with the > "org.apache.cxf.rs.address" property he will have to choose a port other than > 8080 or he'll get the following exception: > WARNUNG: WARNING : Problem creating a remote endpoint for > de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource from CXF > PublishHook, reason is null > org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:114) > at > org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:129) > at > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook
[jira] [Commented] (DOSGI-58) Better handling for port conflicts when using property org.apache.cxf.rs.address
[ https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481302#comment-13481302 ] Sergey Beryozkin commented on DOSGI-58: --- +1 > Better handling for port conflicts when using property > org.apache.cxf.rs.address > > > Key: DOSGI-58 > URL: https://issues.apache.org/jira/browse/DOSGI-58 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: REST >Affects Versions: 1.1 >Reporter: Daniel Bimschas >Priority: Minor > Labels: configuration > > Below is an exception from the mailing list thread that describes the > issue... (reverse order!) > I seePerhaps it could recognize that a conflict will occur and print a > more meaningful exception message advising users to use a context property. > If DOSGI will try to silently attach the endpoint to a paxweb-enabled > HttpService then it might become complicated (paxweb may not be installed in > case of multibindle distro) or a user might've used the explicit address > exactly because a standalone jetty were expected to start, etc... > Can you please open a JIRA in a DOSGI subproject so that we can track this > issue and discuss how to fix it ? > thanks, Sergey > - Original Message - From: "Daniel Bimschas" > > To: > Sent: Friday, February 05, 2010 3:07 PM > Subject: Re: DOSGi and JSON responses > Oh, I know of the org.osgi.service.http.port value that lets Pax Web start > it's Jetty instance on 8080 per default. I tried to say that users of DOSGI > (especially newbies) would certainly expect that using > "org.apache.cxf.rs.address" would work nevertheless by simply using the same > port (i.e. if there's no web context conflict). > I guess that some DOSGI (or CXF) bundle which is responsible for registering > the JAX-RS servlet to some Jetty instance could surely check if there's a > servlet container instance running on the desired port and reusing that > instance... > Daniel > Am 05.02.2010 um 15:56 schrieb Sergey Beryozkin: > Hi > This can be easily fixed AFAIK, I can't recall the name of the paxweb > property but you can ensure its Httpservice occupies some other port...Just > checked in ServiceMix, it is > org.osgi.service.http.port=8181, > add it to felix/etc/config.properties. etc > cheers, Sergey > Sergey, > I just stumbled over another issue that may annoy DOSGI users. If you start > the single bundle distribution (no idea if it's the same with multi bundle) > it starts a Jetty on localhost:8080 which should be usable like a OSGi > compendium HTTP service (that's what I understood at least). Now if one uses > the JAX-RS stuff and registers it's instance with the > "org.apache.cxf.rs.address" property he will have to choose a port other than > 8080 or he'll get the following exception: > WARNUNG: WARNING : Problem creating a remote endpoint for > de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource from CXF > PublishHook, reason is null > org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:114) > at > org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:129) > at > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80) > at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:637) > Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty server: > Address already in use > at > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:339) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:157) > at > org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48) > at > org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:164) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:105) > ... 8 more > Caused by: java.net.BindException: Address already in use > at sun.nio.ch.Net.bind(Native Method) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) > at sun.nio.ch.ServerSocketAdaptor.bind(
[jira] [Commented] (DOSGI-115) Use Spring DM and Eclipse Gemini Blueprint with DOSGi
[
https://issues.apache.org/jira/browse/DOSGI-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481303#comment-13481303
]
Christian Schneider commented on DOSGI-115:
---
Do we really need to load a context? I see two better options.
1) We could switch to blueprint and simply add the intentmap to the context
that starts the dsw bundle.
2) We could create the intentmap completely in code. It is a bit more work but
would make us completely independent of blueprint and spring dm
So I think if we can assume blueprint is always present like e.g. in Karaf 1 is
better. If we can not assume this then 2 might be better.
> Use Spring DM and Eclipse Gemini Blueprint with DOSGi
> -
>
> Key: DOSGI-115
> URL: https://issues.apache.org/jira/browse/DOSGI-115
> Project: CXF Distributed OSGi
> Issue Type: New Feature
> Components: DSW
>Affects Versions: 1.4
> Environment: Developped in Windows OS
>Reporter: Angelo
> Labels: patch
> Fix For: 1.4
>
> Attachments: cxf-dosgi-ri-dsw-Eclipse Projects cxf with Spring
> DM+Eclipse Gemini Blueprint.zip
>
>
> Today cxf-dosgi-ri-dsw-cxf supports only Spring DM. This goal of this issue
> is to modify cxf-dosgi-ri-dsw-cxf to support both Spring DM and Eclipse
> Gemini Blueprint.
> The idea is :
> * 1) cxf-dosgi-ri-dsw-cxf :remove Spring DM dependencies (don't use directly
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext and
> org.springframework.osgi.context.BundleContextAware) in this project but use
> a commons interface :
>
> package org.apache.cxf.dosgi.dsw.container;
> import java.util.List;
> import org.osgi.framework.BundleContext;
> import org.springframework.context.ApplicationContext;
> /**
> * OSGi Spring container API.
> *
> * @author Angelo Zerr
> *
> */
> public interface OsgiSpringContainer {
> /**
>* Publish the given springs files and returns the Spring
>* {@link ApplicationContext}.
>*
>* @param springIntentLocations
>* @param bundleContext
>* @return
>*/
> ApplicationContext publish(List springIntentLocations,
> BundleContext bundleContext);
> /**
>* Returns the {@link BundleContext} from the given Spring application
>* context.
>*
>* @param context
>* @return
>*/
> BundleContext getBundleContext(ApplicationContext context);
> }
>
> 1.1) In the class OsgiUtils:
> do like this:
>
> ApplicationContext ctx =
> OsgiSpringContainerProvider.getContainer().publish(springIntentLocations,
> bundleContext);
>
> Instead of doing that:
>
> //
> //
> //OsgiBundleXmlApplicationContext ctx = new
> OsgiBundleXmlApplicationContext(springIntentLocations
> //.toArray(new String[] {}));
> //ctx.setPublishContextAsService(false);
> //ctx.setBundleContext(bundleContext);
> //ctx.refresh();
>
> 1.2) In the Activator class:
> Implements ApplicationContextAware (instead of BundleContextAware) :
> public class Activator implements ManagedService,
> ApplicationContextAware/*,BundleContextAware*/ {
> and implements setApplicationContext liek this
>
> public void setApplicationContext(ApplicationContext context)
> throws BeansException {
> bc = OsgiUtils.getBundleContext(context);
> }
>
> where OsgiUtils.getBundleContext use the interface
>
> public static BundleContext getBundleContext(ApplicationContext context) {
> return OsgiSpringContainerProvider.getContainer().getBundleContext(context);
> }:
>
> 1.1) OsgiSpringContainerProvider:
> The OsgiSpringContainerProvider use SPI ServiceRegistry to retrieves the
> implemententation of OsgiSpringContainer :
>
> package org.apache.cxf.dosgi.dsw.container;
> import java.util.Iterator;
> import javax.imageio.spi.ServiceRegistry;
> public class OsgiSpringContainerProvider {
[jira] [Created] (DOSGI-127) Provide a default address for services
Christian Schneider created DOSGI-127:
-
Summary: Provide a default address for services
Key: DOSGI-127
URL: https://issues.apache.org/jira/browse/DOSGI-127
Project: CXF Distributed OSGi
Issue Type: Improvement
Components: DSW
Affects Versions: 1.3.1
Reporter: Christian Schneider
Fix For: 1.4
If org.apache.cxf.ws.address is not provided in the service properties we
should create an endpoint with the servlet transport and a url derived by the
service name.
So for example:
If our service has the fq name {com.example}CustomerService we could use the
uri /com/example/CustomerService
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-128) Allow to use JAXWS/JAXB service without frontend and databinding properties
Christian Schneider created DOSGI-128: - Summary: Allow to use JAXWS/JAXB service without frontend and databinding properties Key: DOSGI-128 URL: https://issues.apache.org/jira/browse/DOSGI-128 Project: CXF Distributed OSGi Issue Type: Improvement Components: DSW Affects Versions: 1.3.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.4 To publish a JAXWS/JAXB service you currently have to use the following service properties: org.apache.cxf.ws.frontend:jaxws org.apache.cxf.ws.databinding:jaxb As these services are quite popular I propose we autodetect these when no such properties are set. So the idea is to detect if the @Webservice annotation is present and then by default use the above settings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-86) Decouple DOSGi DSW from Spring DM.
[ https://issues.apache.org/jira/browse/DOSGI-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481307#comment-13481307 ] Christian Schneider commented on DOSGI-86: -- Due to issue DOSGI-66 the Activator of DSW was made to be Spring based. I still think we can make it independent of spring. > Decouple DOSGi DSW from Spring DM. > -- > > Key: DOSGI-86 > URL: https://issues.apache.org/jira/browse/DOSGI-86 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: DSW >Reporter: Ioannis Canellos > > Currently, CXF DOSGi has a runtime dependency on Spring DM. This could be > avoided since the only classes that actually depends from from spring-dm is > OsgiUtils and Activator under project cxf-dosgi-ri-dsw-cxf. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DOSGI-118) Make Spring only as an optional dependency for DSW
[ https://issues.apache.org/jira/browse/DOSGI-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-118. --- Resolution: Duplicate I found an older issue about the same thing. I will follow up there > Make Spring only as an optional dependency for DSW > -- > > Key: DOSGI-118 > URL: https://issues.apache.org/jira/browse/DOSGI-118 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Balazs Zsoldos >Assignee: Christian Schneider > > Due to issue DOSGI-66 the Activator of DSW was made to be Spring based. My > problem is that I wanted to use only the JAX-RS feature that does not need > spring in an OSGI container. Because of the change in the mentioned issue > Spring becomes a hard wired dependency of DSW. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-20) Get rid of the DynamicImport-Package="*"
[ https://issues.apache.org/jira/browse/DOSGI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481311#comment-13481311 ] Christian Schneider commented on DOSGI-20: -- How about using the bundle classloader of the bundle that requests the service? It should know about all classes relevant to the service contract. > Get rid of the DynamicImport-Package="*" > > > Key: DOSGI-20 > URL: https://issues.apache.org/jira/browse/DOSGI-20 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert > > The current DOSGi implementation uses DynamicImport-Package="*". While this > is very convenient, it is potentially unpredictable and could have serious > performance side effects. Therefore it would be better to remove this > dependency and potentially use direct OSGi API to find the required package > potentially via the PackageAdmin only when we need to do this type of thing > i.e. when a proxy is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4593) STSClient: support different SOAP bindings for MEX call
Andrei Shakirin created CXF-4593: Summary: STSClient: support different SOAP bindings for MEX call Key: CXF-4593 URL: https://issues.apache.org/jira/browse/CXF-4593 Project: CXF Issue Type: Improvement Reporter: Andrei Shakirin Priority: Minor Hi, Actually STSClient always uses SOAP 1.1 bindings for the MEX communications. There are some use cases, where MEX should be done using SOAP 1.2 (http://cxf.547215.n5.nabble.com/Dispatching-WS-with-WSS4J-through-STS-tt5716991.html). At the moment only the way to do it is wrap STSClient in own implementation and override STSClient.configureViaEPR() method, that is not easy and comfortable. Proposal: use soapVersion from STSClient also for MEX communication (with high probability STS and MEX communications will use the same SOAP versions) Regards, Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4593) STSClient: support different SOAP bindings for MEX call
[ https://issues.apache.org/jira/browse/CXF-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated CXF-4593: - Attachment: STSClientMEX.patch Patch > STSClient: support different SOAP bindings for MEX call > --- > > Key: CXF-4593 > URL: https://issues.apache.org/jira/browse/CXF-4593 > Project: CXF > Issue Type: Improvement >Reporter: Andrei Shakirin >Priority: Minor > Attachments: STSClientMEX.patch > > > Hi, > Actually STSClient always uses SOAP 1.1 bindings for the MEX communications. > There are some use cases, where MEX should be done using SOAP 1.2 > (http://cxf.547215.n5.nabble.com/Dispatching-WS-with-WSS4J-through-STS-tt5716991.html). > At the moment only the way to do it is wrap STSClient in own implementation > and override STSClient.configureViaEPR() method, that is not easy and > comfortable. > Proposal: use soapVersion from STSClient also for MEX communication (with > high probability STS and MEX communications will use the same SOAP versions) > Regards, > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-20) Get rid of the DynamicImport-Package="*"
[ https://issues.apache.org/jira/browse/DOSGI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481320#comment-13481320 ] Sergey Beryozkin commented on DOSGI-20: --- As far as I recall there were issues with that, for DSW failing to report correctly the proxies it created, or even when creating the proxies, this would have to be experimented with > Get rid of the DynamicImport-Package="*" > > > Key: DOSGI-20 > URL: https://issues.apache.org/jira/browse/DOSGI-20 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert > > The current DOSGi implementation uses DynamicImport-Package="*". While this > is very convenient, it is potentially unpredictable and could have serious > performance side effects. Therefore it would be better to remove this > dependency and potentially use direct OSGi API to find the required package > potentially via the PackageAdmin only when we need to do this type of thing > i.e. when a proxy is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-129) NPE when stopping a bundle that exports a DOSGI service
Christian Schneider created DOSGI-129: - Summary: NPE when stopping a bundle that exports a DOSGI service Key: DOSGI-129 URL: https://issues.apache.org/jira/browse/DOSGI-129 Project: CXF Distributed OSGi Issue Type: Bug Affects Versions: 1.3.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.3.2 The following exception appears on the console (not log) when stopping a bundle that exports a DOSGI service. --- karaf@root> stop 165 ERROR: Bundle cxf-dosgi-ri-topology-manager [159] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.cxf.dosgi.topologymanager.TopologyManager.notifyListenersOfRemovalIfAppropriate(TopologyManager.java:372) at org.apache.cxf.dosgi.topologymanager.TopologyManager.notifyListenersOfRemovalIfAppropriate(TopologyManager.java:217) at org.apache.cxf.dosgi.topologymanager.TopologyManager.removeService(TopologyManager.java:201) at org.apache.cxf.dosgi.topologymanager.ServiceListenerImpl.serviceChanged(ServiceListenerImpl.java:68) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890) at org.apache.felix.framework.Felix.access$000(Felix.java:79) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:135) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:129) at org.apache.aries.blueprint.container.ServiceRecipe.unregister(ServiceRecipe.java:201) at org.apache.aries.blueprint.container.BlueprintContainerImpl.unregisterServices(BlueprintContainerImpl.java:664) at org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:813) at org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:250) at org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:242) at org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:438) at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237) at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3879) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2268) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:963) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:950) at org.apache.karaf.shell.osgi.StopBundle.doExecute(StopBundle.java:34) at org.apache.karaf.shell.osgi.BundlesCommand.doExecute(BundlesCommand.java:37) at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38) at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.karaf.shell.console.jline.Console.run(Console.java:172) at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4564) NPE in MavenToolErrorListener during wsdl2java code generation
[
https://issues.apache.org/jira/browse/CXF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Kieselhorst updated CXF-4564:
Description:
Running wsdl2java with 2.6.3 on JDK 7 causes an NPE. Everything is fine JDK 6.
{code}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-MyService.wsdl) on
project my-maven-module: Execution wsdl-MyService.wsdl of goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
java.lang.NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-MyService.wsdl) on
project MyProject: Execution wsdl-MyService.wsdl of goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
wsdl-MyService.wsdl of goal org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java
failed: java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.cxf.tools.common.ToolException:
java.lang.NullPointerException
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:308)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:380)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:257)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:477)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.NullPointerException
at java.io.File.(File.java:251)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener$1.(WSDL2JavaMojo.java:76)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener.addError(WSDL2JavaMojo.java:74)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:40)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:316)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:94)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:405)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:304)
at
com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:115)
at
com.sun.istack.XMLStreamReaderToContentHandler.handleStartElement(XMLStreamReaderToContentHandler.java:304)
at
com.sun.istack.XMLStreamReaderToContentHandler.bridge(XMLStreamReaderToCont
[jira] [Commented] (CXF-4487) cxf-codegen-plugin: Error resolving component warnings for imported types
[ https://issues.apache.org/jira/browse/CXF-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481345#comment-13481345 ] Dennis Kieselhorst commented on CXF-4487: - Yes, it works with previous CXF releases and wsimport. I'll try to create a simple testcase... > cxf-codegen-plugin: Error resolving component warnings for imported types > - > > Key: CXF-4487 > URL: https://issues.apache.org/jira/browse/CXF-4487 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.6.2 > Environment: Windows 7 x64 >Reporter: Gert Driesen >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.6.3 > > Attachments: cxf-4487.zip, cxf-codegen-plugin.log, example.zip > > > As of CXF 2.6.2 (not sure about 2.6.1)), I get warnings for several types > that have been imported from an XSD. > For example: > WARNING: > C:\cxf-plugin-issue\src\main\resources\Private\Acquittal\NisseAcquittal_V1.wsdl > [23,7]: src-resolve.4.2: Error resolving component 'meta:ApplHeaderStruct'. > It was detected that 'meta:ApplHeaderStruct' is in namespace > 'http://www.rsvz-inasti.fgov.be/PrivateWS/schema/MetaInfo/V1', but components > from this namespace are not referenceable from schema document > 'file:/C:/cxf-plugin-issue/src/main/resources/Private/Acquittal/NisseAcquittal_V1.wsdl#types1'. > If this is the incorrect namespace, perhaps the prefix of > 'meta:ApplHeaderStruct' needs to be changed. If this is the correct > namespace, then an appropriate 'import' tag should be added to > 'file:/C:/cxf-plugin-issue/src/main/resources/Private/Acquittal/NisseAcquittal_V1.wsdl#types1'. > I get none of these warning when using CXF 2.5.4, and the WSDL and XSD are > all valid. > I'll attach a repro for this issue, and a log file (taken with level FINE). > Just search for "src-resolve.4.2". > Just use "mvn clean install" to reproduce the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-130) Clean up unused code and fix warnings, use interfaces where possible in DSW
Christian Schneider created DOSGI-130: - Summary: Clean up unused code and fix warnings, use interfaces where possible in DSW Key: DOSGI-130 URL: https://issues.apache.org/jira/browse/DOSGI-130 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.3.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.3.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DOSGI-130) Clean up unused code and fix warnings, use interfaces where possible in DSW
[ https://issues.apache.org/jira/browse/DOSGI-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-130: -- Issue Type: Improvement (was: Bug) > Clean up unused code and fix warnings, use interfaces where possible in DSW > --- > > Key: DOSGI-130 > URL: https://issues.apache.org/jira/browse/DOSGI-130 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: DSW >Affects Versions: 1.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.3.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4529) PermGen Leak for CXFAuthenticator (WS Client Configuration)
[ https://issues.apache.org/jira/browse/CXF-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481426#comment-13481426 ] Petr Nídl commented on CXF-4529: I agree with Danielius. This is definitely a classloader leak. Although it is caused by design of java.net.Authenticator class the problem comes from CXF that either should not rely on java.net.Authenticator or should come with solution that allows its correct cleanup. Also the workaround mentioned by Freeman (java.net.Authenticator.setDefault(null)) will not work correctly because it can wipe out all authenticators possibly registered by other (still running) applications. > PermGen Leak for CXFAuthenticator (WS Client Configuration) > --- > > Key: CXF-4529 > URL: https://issues.apache.org/jira/browse/CXF-4529 > Project: CXF > Issue Type: Bug > Components: Configuration, JAX-WS Runtime >Affects Versions: 2.6.1 > Environment: Apache Tomcat 7, Windows 7 32bit >Reporter: Holger Sunke >Assignee: Freeman Fang > Labels: leak, permgen > > Hello, > seemes to me there is a memory leak with the CXFAuthenticator. There is a > static reference to it in java.net.Authenticator.theAuthenticator . > This prevents the GC from collecting the WebappClassLoader on hot > undeployment. > I helped myself by doing > java.net.Authenticator.setDefault(null); > on contextDestroy(). > Our web application uses CXF as a jasWS client configured with Spring 3.0.5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4583) When the logical handler return false processing the outbound message, the SoapMessage's body is always empty.
[ https://issues.apache.org/jira/browse/CXF-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481450#comment-13481450 ] Yi Xiao commented on CXF-4583: -- Hi Willem, I verify the path, it works fine. Thanks very much. > When the logical handler return false processing the outbound message, the > SoapMessage's body is always empty. > -- > > Key: CXF-4583 > URL: https://issues.apache.org/jira/browse/CXF-4583 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.6.2 >Reporter: Yi Xiao >Assignee: Willem Jiang > Labels: handler > Attachments: CXF-4853.patch > > > According to the spec, when return false: > Normal message processing stops, close is called on each previously invoked > handler in the chain, the message is dispatched. > So the message returned by endpoint should be dispatched to client, not > always the empty body element. > In my case, the endpoint has built the soapMessage: > http://schemas.xmlsoap.org/soap/envelope/";> > > > xmlns:ns2="http://jaxws.samples.ibm.com/";> > 116 > > > > but the client receives： > http://schemas.xmlsoap.org/soap/envelope/";> > > > > I find the LogicalHandlerOutInterceptor does not set the SoapMessage correct > when the logicalHandler return false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FEDIZ-25) Look for fediz_config.xml in catalina base too
[ https://issues.apache.org/jira/browse/FEDIZ-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated FEDIZ-25: -- Fix Version/s: 1.0.2 > Look for fediz_config.xml in catalina base too > -- > > Key: FEDIZ-25 > URL: https://issues.apache.org/jira/browse/FEDIZ-25 > Project: CXF-Fediz > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0.0, 1.0.1 >Reporter: Juan Manuel CABRERA >Assignee: Glen Mazza >Priority: Trivial > Fix For: 1.0.2 > > Attachments: FederationAuthenticator.java.patch > > > The FederationAuthenticator valve looks for the Fediz configuration file in > the catalina_home only, it should be fetched in the catalina_base too to > address the cases where both variables are different (which is the case with > WTP by default for instance, or in many production deployment) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FEDIZ-17) Current Fediz STS exposes SOAP 1.1 end point
[ https://issues.apache.org/jira/browse/FEDIZ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated FEDIZ-17: -- Fix Version/s: 1.0.2 > Current Fediz STS exposes SOAP 1.1 end point > > > Key: FEDIZ-17 > URL: https://issues.apache.org/jira/browse/FEDIZ-17 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.0.0 > Environment: With SOAP 1.1 end points, if send 1.2 format request, we > are receiving following error message. With current release, users have to > manually convert endpoints to 1.2 format to send 1.2 request. > If Fediz STS end points implemented in 1.2 format, it could take both 1.1 and > 1.2 request. > << > A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint. > >> >Reporter: Gina Choi >Assignee: Oliver Wulff > Fix For: 1.0.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FEDIZ-30) Relying Party can enforce re-authentication using wfresh parameter
[ https://issues.apache.org/jira/browse/FEDIZ-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated FEDIZ-30: -- Fix Version/s: 1.0.2 > Relying Party can enforce re-authentication using wfresh parameter > -- > > Key: FEDIZ-30 > URL: https://issues.apache.org/jira/browse/FEDIZ-30 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP, Plugin >Affects Versions: 1.0.1 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 1.0.2 > > > An application can enforce a re-authentication by setting the wfresh > parameter to 0 in the redirect to the IDP. > snippet from the spec > (http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html) > wfresh > This OPTIONAL parameter indicates the freshness requirements. If specified, > this indicates the desired maximum age of authentication specified in > minutes. An IP/STS SHOULD NOT issue a token with a longer lifetime. If > specified as “0” it indicates a request for the IP/STS to re-prompt the user > for authentication before issuing the token.Note that this serves roughly > the same purpose as the Freshness element in the WS-Trust SOAP RST messages. > email thread: > http://cxf.547215.n5.nabble.com/Logout-from-Fediz-from-single-web-application-td5713780.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FEDIZ-28) Logout capability in IDP
[ https://issues.apache.org/jira/browse/FEDIZ-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated FEDIZ-28: -- Issue Type: New Feature (was: Improvement) > Logout capability in IDP > > > Key: FEDIZ-28 > URL: https://issues.apache.org/jira/browse/FEDIZ-28 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP >Affects Versions: 1.0.1 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 1.0.2 > > > The IDP doesn't support a way to logout a user from the IDP. This is not the > Single Sign Out feature. Basically, it invalidates the session with the IDP > thus a new authentication is required. > If you send an HTTP GET like > https://:/fedizidp/?logout > the session is invalidated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4564) NPE in MavenToolErrorListener during wsdl2java code generation
[
https://issues.apache.org/jira/browse/CXF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482015#comment-13482015
]
Freeman Fang commented on CXF-4564:
---
Hi,
Could you please please append a maven project which we can reproduce this
issue?
Especially the wsdl-MyService.wsdl you used here.
Thanks
Freeman
> NPE in MavenToolErrorListener during wsdl2java code generation
> --
>
> Key: CXF-4564
> URL: https://issues.apache.org/jira/browse/CXF-4564
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.6.3
> Environment: JDK 7
>Reporter: Dennis Kieselhorst
>
> Running wsdl2java with 2.6.3 on JDK 7 causes an NPE. Everything is fine JDK 6.
> {code}
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-MyService.wsdl) on
> project my-maven-module: Execution wsdl-MyService.wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
> java.lang.NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-MyService.wsdl)
> on project MyProject: Execution wsdl-MyService.wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> wsdl-MyService.wsdl of goal org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java
> failed: java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.cxf.tools.common.ToolException:
> java.lang.NullPointerException
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:308)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> at
> org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:380)
> at
> org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:257)
> at
> org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:477)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> Caused by: java.lang.NullPointerException
> at java.io.File.(File.java:251)
> at
> org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener$1.(WSDL2JavaMojo.java:76)
> at
> org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener.addError(WSDL2JavaMojo.java:74)
> at
> org.apa
[jira] [Created] (CXF-4594) Incompatible fault type is generated in the wsdl if no setter method in Exception
iris ding created CXF-4594:
--
Summary: Incompatible fault type is generated in the wsdl if no
setter method in Exception
Key: CXF-4594
URL: https://issues.apache.org/jira/browse/CXF-4594
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 2.7.0, 2.6.3
Reporter: iris ding
Fix For: 2.7.0
with the exception class below , it only has a get*** method for the
info property.
@WebFault
public TestException extends Exception {
private String message = null;
public TestException () {
}
public TestException (String message) {
this.message = message;
}
public String getInfo() {
return message;
}
}
With the RI wsgen command, the generated schema type is :
RI:
If using CXF tool or on the CXF runtime, the generated schema type for the
exception is :
With the JaxWS spec, 3.7 Service Specific Exception, considering that no
getFaultInfo or faultBean in WebFault annotation is provided, the
special algorithm will be used to map the exception to jaxb bean, one of
the steps write below:
For each getter in the exception and its superclasses, a property of the
same type and name is added to
the bean. All the getter methods except
getMessagefromjava.lang.Throwabletype hierarchy
are excluded from the list of getters to be mapped.
Seems that only getter method is required, with the current codes in static
boolean JAXBContextInitializer.isMethodAccepted, it will check whether the
setter exists. I am thinking that this is not required for this scenario,
as we only need to read the information from the user exception.
The patch will return true is the getter method has no corresponding setter
method to let CXF comply with the jax-ws 2.2 spec:
For each getter in the exception and its superclasses, a property of the
same type and name is added to
the bean. All the getter methods except
getMessagefromjava.lang.Throwabletype hierarchy
are excluded from the list of getters to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4594) Incompatible fault type is generated in the wsdl if no setter method in Exception
[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
iris ding updated CXF-4594:
---
Attachment: JAXBContextInitializer.java.patch
Patch
> Incompatible fault type is generated in the wsdl if no setter method in
> Exception
> -
>
> Key: CXF-4594
> URL: https://issues.apache.org/jira/browse/CXF-4594
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.6.3, 2.7.0
>Reporter: iris ding
> Labels: patch
> Fix For: 2.7.0
>
> Attachments: JAXBContextInitializer.java.patch
>
>
> with the exception class below , it only has a get*** method for the
> info property.
> @WebFault
> public TestException extends Exception {
> private String message = null;
> public TestException () {
> }
> public TestException (String message) {
> this.message = message;
> }
> public String getInfo() {
> return message;
> }
> }
> With the RI wsgen command, the generated schema type is :
> RI:
>
>
>
>
>
>
>
> If using CXF tool or on the CXF runtime, the generated schema type for the
> exception is :
>
>
>
>
> With the JaxWS spec, 3.7 Service Specific Exception, considering that no
> getFaultInfo or faultBean in WebFault annotation is provided, the
> special algorithm will be used to map the exception to jaxb bean, one of
> the steps write below:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
> Seems that only getter method is required, with the current codes in static
> boolean JAXBContextInitializer.isMethodAccepted, it will check whether the
> setter exists. I am thinking that this is not required for this scenario,
> as we only need to read the information from the user exception.
> The patch will return true is the getter method has no corresponding setter
> method to let CXF comply with the jax-ws 2.2 spec:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4595) RequireClientCertificate is not validated
Jason Pell created CXF-4595: --- Summary: RequireClientCertificate is not validated Key: CXF-4595 URL: https://issues.apache.org/jira/browse/CXF-4595 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.7.0 Reporter: Jason Pell I can execute a web service which has a RequireClientCertificate="true" policy in the transport binding, the problem is that my client is not providing a certificate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4595) RequireClientCertificate is not validated
[ https://issues.apache.org/jira/browse/CXF-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Pell updated CXF-4595: Attachment: PolicySample.tar.gz Run the test case SecurityServiceTest, the test fails because no Policy Exception is returned even though i do have a RequireClientCertificate="true" > RequireClientCertificate is not validated > - > > Key: CXF-4595 > URL: https://issues.apache.org/jira/browse/CXF-4595 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.0 >Reporter: Jason Pell > Attachments: PolicySample.tar.gz > > > I can execute a web service which has a RequireClientCertificate="true" > policy in the transport binding, the problem is that my client is not > providing a certificate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4595) RequireClientCertificate is not validated
[ https://issues.apache.org/jira/browse/CXF-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482066#comment-13482066 ] Jason Pell commented on CXF-4595: - Related email trail http://cxf.547215.n5.nabble.com/RequireClientCertificate-confusion-td5717199.html I am happy to contribute a patch as discussed in the email, but I need some advice from the devs as to why the code is in TransportBindingPolicyValidator > RequireClientCertificate is not validated > - > > Key: CXF-4595 > URL: https://issues.apache.org/jira/browse/CXF-4595 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.0 >Reporter: Jason Pell > Attachments: PolicySample.tar.gz > > > I can execute a web service which has a RequireClientCertificate="true" > policy in the transport binding, the problem is that my client is not > providing a certificate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4594) Incompatible fault type is generated in the wsdl if no setter method in Exception
[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482086#comment-13482086
]
Freeman Fang commented on CXF-4594:
---
Hi,
Thanks for the patch.
A couple of quick issues I found so far,
1. the patch break several checkstyle and PMD rules,
2. moreover, it at least break
org.apache.cxf.systest.ws.addr_fromjava.WSAFromJavaTest.
A patch shouldn't break any test and also should follow CXF checkstyle and PMD
rules.
You generally should ensure have "mvn clean install" run successfully from the
root pom
Freeman
> Incompatible fault type is generated in the wsdl if no setter method in
> Exception
> -
>
> Key: CXF-4594
> URL: https://issues.apache.org/jira/browse/CXF-4594
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.6.3, 2.7.0
>Reporter: iris ding
> Labels: patch
> Fix For: 2.7.0
>
> Attachments: JAXBContextInitializer.java.patch
>
>
> with the exception class below , it only has a get*** method for the
> info property.
> @WebFault
> public TestException extends Exception {
> private String message = null;
> public TestException () {
> }
> public TestException (String message) {
> this.message = message;
> }
> public String getInfo() {
> return message;
> }
> }
> With the RI wsgen command, the generated schema type is :
> RI:
>
>
>
>
>
>
>
> If using CXF tool or on the CXF runtime, the generated schema type for the
> exception is :
>
>
>
>
> With the JaxWS spec, 3.7 Service Specific Exception, considering that no
> getFaultInfo or faultBean in WebFault annotation is provided, the
> special algorithm will be used to map the exception to jaxb bean, one of
> the steps write below:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
> Seems that only getter method is required, with the current codes in static
> boolean JAXBContextInitializer.isMethodAccepted, it will check whether the
> setter exists. I am thinking that this is not required for this scenario,
> as we only need to read the information from the user exception.
> The patch will return true is the getter method has no corresponding setter
> method to let CXF comply with the jax-ws 2.2 spec:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4594) Incompatible fault type is generated in the wsdl if no setter method in Exception
[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482097#comment-13482097
]
Freeman Fang commented on CXF-4594:
---
Hi,
Take a close look at the logic from your patch, it doesn't follow what you
wanna here.
Some outstanding issue, from your logic
1. any method without a counterpart setter would be accepted Method, like the
java.lang.Object.wait
2. some special get method like java.lang.Object.getClass would be accepted
Method
both are incorrect...
Freeman
> Incompatible fault type is generated in the wsdl if no setter method in
> Exception
> -
>
> Key: CXF-4594
> URL: https://issues.apache.org/jira/browse/CXF-4594
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.6.3, 2.7.0
>Reporter: iris ding
> Labels: patch
> Fix For: 2.7.0
>
> Attachments: JAXBContextInitializer.java.patch
>
>
> with the exception class below , it only has a get*** method for the
> info property.
> @WebFault
> public TestException extends Exception {
> private String message = null;
> public TestException () {
> }
> public TestException (String message) {
> this.message = message;
> }
> public String getInfo() {
> return message;
> }
> }
> With the RI wsgen command, the generated schema type is :
> RI:
>
>
>
>
>
>
>
> If using CXF tool or on the CXF runtime, the generated schema type for the
> exception is :
>
>
>
>
> With the JaxWS spec, 3.7 Service Specific Exception, considering that no
> getFaultInfo or faultBean in WebFault annotation is provided, the
> special algorithm will be used to map the exception to jaxb bean, one of
> the steps write below:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
> Seems that only getter method is required, with the current codes in static
> boolean JAXBContextInitializer.isMethodAccepted, it will check whether the
> setter exists. I am thinking that this is not required for this scenario,
> as we only need to read the information from the user exception.
> The patch will return true is the getter method has no corresponding setter
> method to let CXF comply with the jax-ws 2.2 spec:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4595) RequireClientCertificate is not validated
[
https://issues.apache.org/jira/browse/CXF-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482112#comment-13482112
]
Jason Pell commented on CXF-4595:
-
The HttpsTokenInInterceptor is PRE-STREAM
The PolicyBasedWSS4JInInterceptor is PRE-PROTOCOL
So according to http://cxf.apache.org/docs/interceptors.html, the
HttpsTokenInInterceptor executes first. So TransportBindingPolicyValidator is
definately
overriding what has already been set in HttpsTokenInInterceptor.
Should it not be ignoring anything that has already been checked by
HttpsTokenInInterceptor?
In fact should the following code:
if (binding.getTransportToken() != null) {
assertPolicy(aim, binding.getTransportToken());
assertPolicy(aim, binding.getTransportToken().getToken());
}
be removed from TransportBindingPolicyValidator
> RequireClientCertificate is not validated
> -
>
> Key: CXF-4595
> URL: https://issues.apache.org/jira/browse/CXF-4595
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.0
>Reporter: Jason Pell
> Attachments: PolicySample.tar.gz
>
>
> I can execute a web service which has a RequireClientCertificate="true"
> policy in the transport binding, the problem is that my client is not
> providing a certificate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4595) RequireClientCertificate is not validated
[ https://issues.apache.org/jira/browse/CXF-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482137#comment-13482137 ] Jason Pell commented on CXF-4595: - To provide further clarification. The binding.getTransportToken().getToken() returns the HttpsToken > RequireClientCertificate is not validated > - > > Key: CXF-4595 > URL: https://issues.apache.org/jira/browse/CXF-4595 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.0 >Reporter: Jason Pell > Attachments: PolicySample.tar.gz > > > I can execute a web service which has a RequireClientCertificate="true" > policy in the transport binding, the problem is that my client is not > providing a certificate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4595) RequireClientCertificate is not validated
[
https://issues.apache.org/jira/browse/CXF-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482157#comment-13482157
]
Jason Pell commented on CXF-4595:
-
This is the code in HttpsTokenInInterceptor that does actually check for the
client certificate. And in my case, my debugging tells me that the setAsserted
is false, which is a good thing, but then gets overriden.
TLSSessionInfo tlsInfo = message.get(TLSSessionInfo.class);
if (tlsInfo != null) {
if (token.isRequireClientCertificate()
&& (tlsInfo.getPeerCertificates() == null
|| tlsInfo.getPeerCertificates().length == 0)) {
asserted = false;
}
} else {
asserted = false;
}
ai.setAsserted(asserted);
> RequireClientCertificate is not validated
> -
>
> Key: CXF-4595
> URL: https://issues.apache.org/jira/browse/CXF-4595
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.0
>Reporter: Jason Pell
> Attachments: PolicySample.tar.gz
>
>
> I can execute a web service which has a RequireClientCertificate="true"
> policy in the transport binding, the problem is that my client is not
> providing a certificate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
