[jira] [Comment Edited] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741838#comment-16741838 ] Freeman Fang edited comment on CXF-7907 at 1/14/19 8:01 AM: Yup, I'm still one, running more tests. Btw, org.glassfish.jaxb artifacts are not OSGi bundles was (Author: ffang): Yup, I'm still one, running more tests > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741841#comment-16741841 ] Dennis Kieselhorst commented on CXF-7907: - Ok sad, but looks like except for jaxb-core the old com.sun.xml.bind artifacts still exist for 2.3.2. > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
Sean created CXF-7943: - Summary: MAPCodec: Memory leak due to growing uncorrelatedExchanges Key: CXF-7943 URL: https://issues.apache.org/jira/browse/CXF-7943 Project: CXF Issue Type: Bug Affects Versions: 3.2.0 Environment: CXF 3.2.0, JDK 1.8 Reporter: Sean Attachments: histogram.PNG, leak_suspect_1.PNG When running load tests, my system begin to get memory leak after 4 hours or so. When analyzing the heap dump using VisualVM (please see attachments), I can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as well as being the main "suspect" for this leak. This leads me to believe that it is the uncorrelatedExchanges attribute since this map is being reference from the MAPCodec class. I believe that the map, in my case, for whatever reason, does not always remove the Exchange after the synchronous request/responses are done, however I could be wrong. IF this is indeed a bug, what could the cause of this be, as well as any work around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741939#comment-16741939 ] Freeman Fang commented on CXF-7907: --- can't use com.sun.xml.bind 2.3.2 artifacts as missing jaxb-core For now I use servicemix wrapped org.glassfish.jaxb 2.3.1, though I created servicemix wrapped org.glassfish.jaxb 2.3.2, but that requires another Servicemix bundles release. IMO it's not a show-stopper for us to release CXF 3.3 using org.glassfish.jaxb 2.3.1 bundles > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741966#comment-16741966 ] Andriy Redko commented on CXF-7910: --- Thanks [~deki], I will check it with a few samples we have, [~ffang] could you please take a look as well? Thanks! > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.3.0 > > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: cxf7941.zip > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[
https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742219#comment-16742219
]
Tomas Vanhala commented on CXF-7941:
Please find attached a test case that illustrates the issue.
Our understanding is that it is related to
[https://svn.apache.org/repos/asf/webservices/wss4j/trunk/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/Merlin.java.|https://svn.apache.org/repos/asf/webservices/wss4j/trunk/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/Merlin.java]
On line 920 there is a strange comment:
{code:java}
//
// Search the keystore for the transmitted public key (direct trust).
If not found
// then search the truststore for the transmitted public key (direct
trust)
//
{code}
In the implementation of findPublicKeyInKeyStore(), the public key from the
SAML Token does not ever end up in the variable "certs". As s a result:
* the certificate chain does not include the public key
* the checks on line 1309 do not succeed
* the method cannot ever return true in the case of chain-of-trust
> SamlValidator does not work with chain trust
>
>
> Key: CXF-7941
> URL: https://issues.apache.org/jira/browse/CXF-7941
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.2.7
>Reporter: Tomas Vanhala
>Priority: Major
> Attachments: cxf7941.zip
>
>
> As explained here
> [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,]
> WSS4J supports specifying constraints on the subject DN of the certificate
> used for signature validation.
> We have successfully applied "direct trust" when receiving SOAP requests
> containing a signed SAML token.
> We attempted to migrate to "chain trust" by removing the certificate used to
> sign the requests from the Merlin trust store, and setting an appropriate
> Subject DN Cert Constraint.
> It did not work. Our analysis is that WSS4J's SamlValidator is not able to
> handle a scenario where the certificate used to sign the requests is not in
> the trust store. The problem seems to be in the method
> findPublicKeyInKeyStore() of Merlin.java.
> We were able to make chain trust (and the Subject DN Cert Constraint) work by
> including the needed PKI code in a customised SamlValidator, but we would
> rather not go this route.
> Please fix chain trust in WSS4J SAML validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742310#comment-16742310 ] Colm O hEigeartaigh commented on CXF-7941: -- The way the PublicKey verification works in Merlin is that the certificate corresponding to the public key must be contained directly in the keystore or truststore. That's why your "direct-trust.jks" test-case works. However, "chain-of-trust.jks" fails as Merlin can't find the public key in the keystore/truststore to match against the key it is trying to trust. The chain trust method only works with certificates. How are we supposed to know who issued a public key if we have no corresponding certificate? > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?focusedWorklogId=184898&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-184898 ] ASF GitHub Bot logged work on CXF-7910: --- Author: ASF GitHub Bot Created on: 14/Jan/19 17:11 Start Date: 14/Jan/19 17:11 Worklog Time Spent: 10m Work Description: deki commented on pull request #500: [CXF-7910] Change JAX-WS javax to jakarta artifact dependencies URL: https://github.com/apache/cxf/pull/500 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 184898) Time Spent: 10m Remaining Estimate: 0h > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742316#comment-16742316 ] Dennis Kieselhorst commented on CXF-7910: - Ok please update once more, I've just merged the latest changes from CXF-7907 to the branch. > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742317#comment-16742317 ] Dennis Kieselhorst commented on CXF-7907: - Ok, cxf-xjc-utils needs an update too. > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742341#comment-16742341 ] Tomas Vanhala commented on CXF-7941: Yes, that is why findPublicKeyInKeyStore() will not work for us when validating a SAML assertion. The SOAP header of the message we are validating contains the public key, inside wsse:Security as the value of wssse:BinarySecurityToken. Since the X.509 Certificate Token Profile is used, the BinarySecurityToken is at the same time both the public key and the "corresponding" certificate. What we then need to do is check whether the received certificate can be trusted. For the chain trust method, the chain would need to be constructed using: * the leaf certificate from the received BinarySecurityToken * the root and intermediate issuing certificate from the (Merlin) trust store It seems that when validating chain trust, Merlin ignores the received leaf certificate. > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742394#comment-16742394 ] Colm O hEigeartaigh commented on CXF-7941: -- CXF/WSS4J SAML trust verification should work fine with BinarySecurityTokens containing X.509 certs. What I don't understand is how you are getting to Merlin.verifyTrust(PublicKey) though if you are using a certificate. Could you post a sample of a SOAP Reuqest that is causing the problem? You can sanitise any sensitive information from it. Also a stacktrace from Merlin.verifyTrust would be helpful. > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXFXJC-31) upgrade to jaxb 2.3.2
Freeman Fang created CXFXJC-31: -- Summary: upgrade to jaxb 2.3.2 Key: CXFXJC-31 URL: https://issues.apache.org/jira/browse/CXFXJC-31 Project: CXF XJC Utils Issue Type: Task Reporter: Freeman Fang also use the org.glassfish.jaxb artifacts instead of the old ones from com.sun.xml.bind -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXFXJC-31) upgrade to jaxb 2.3.2
[ https://issues.apache.org/jira/browse/CXFXJC-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXFXJC-31: -- Assignee: Freeman Fang > upgrade to jaxb 2.3.2 > - > > Key: CXFXJC-31 > URL: https://issues.apache.org/jira/browse/CXFXJC-31 > Project: CXF XJC Utils > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > also use the org.glassfish.jaxb artifacts instead of the old ones from > com.sun.xml.bind -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742674#comment-16742674 ] Freeman Fang commented on CXF-7910: --- [~reta] Sure, I will test against that branch > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[
https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742701#comment-16742701
]
Andriy Redko commented on CXF-7910:
---
Thanks [~ffang], from my side I did the fresh build from this branch and
deployed jaxws_tracing_brave_osgi into Karaf 4.2.2, no issues. Bundle starts
and works as expected.
{noformat}
exports | grep javax.xml.soap
javax.xml.soap | 1.3.0
| 0 | org.apache.felix.framework
javax.xml.soap | 1.4.1
| 48 | jakarta.xml.soap-api
{noformat}
Thanks [~deki]!
> Change JAX-WS javax to jakarta artifact dependencies
>
>
> Key: CXF-7910
> URL: https://issues.apache.org/jira/browse/CXF-7910
> Project: CXF
> Issue Type: Task
> Components: JAX-WS Runtime
>Reporter: Dennis Kieselhorst
>Assignee: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See https://github.com/eclipse-ee4j/jax-ws-api/issues/46
> According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be
> released on 2018-12-14.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[
https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742701#comment-16742701
]
Andriy Redko edited comment on CXF-7910 at 1/15/19 3:17 AM:
Thanks [~ffang], from my side I did the fresh build from this branch and
deployed jaxws_tracing_brave_osgi into Karaf 4.2.2, no issues. Bundle starts
and works as expected. The SOAP 1.4 is present.
{noformat}
exports | grep javax.xml.soap
javax.xml.soap | 1.3.0
| 0 | org.apache.felix.framework
javax.xml.soap | 1.4.1
| 48 | jakarta.xml.soap-api
{noformat}
Thanks [~deki]!
was (Author: reta):
Thanks [~ffang], from my side I did the fresh build from this branch and
deployed jaxws_tracing_brave_osgi into Karaf 4.2.2, no issues. Bundle starts
and works as expected.
{noformat}
exports | grep javax.xml.soap
javax.xml.soap | 1.3.0
| 0 | org.apache.felix.framework
javax.xml.soap | 1.4.1
| 48 | jakarta.xml.soap-api
{noformat}
Thanks [~deki]!
> Change JAX-WS javax to jakarta artifact dependencies
>
>
> Key: CXF-7910
> URL: https://issues.apache.org/jira/browse/CXF-7910
> Project: CXF
> Issue Type: Task
> Components: JAX-WS Runtime
>Reporter: Dennis Kieselhorst
>Assignee: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See https://github.com/eclipse-ee4j/jax-ws-api/issues/46
> According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be
> released on 2018-12-14.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[
https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742718#comment-16742718
]
Freeman Fang commented on CXF-7910:
---
Hi [~reta], when you build, all tests passed?
I ran into this error when building CXF-7910_jakarta_jaxws-api branch with JDK8
{code}
[INFO] Running org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.195
s <<< FAILURE! - in org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR]
testBearerSAML2Token(org.apache.cxf.systest.sts.itests.unit.STSUnitTest) Time
elapsed: 2.99 s <<< ERROR!
javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factory:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl cannot be cast to
javax.xml.soap.SAAJMetaFactory
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.requestSecurityToken(STSUnitTest.java:135)
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.testBearerSAML2Token(STSUnitTest.java:84)
{code}
Should be SAAJ related(javax.xml.soap)
> Change JAX-WS javax to jakarta artifact dependencies
>
>
> Key: CXF-7910
> URL: https://issues.apache.org/jira/browse/CXF-7910
> Project: CXF
> Issue Type: Task
> Components: JAX-WS Runtime
>Reporter: Dennis Kieselhorst
>Assignee: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See https://github.com/eclipse-ee4j/jax-ws-api/issues/46
> According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be
> released on 2018-12-14.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[
https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742718#comment-16742718
]
Freeman Fang edited comment on CXF-7910 at 1/15/19 3:44 AM:
Hi [~reta], when you build, all tests passed?
I ran into this error when building CXF-7910_jakarta_jaxws-api branch with JDK8
and JDK11
{code}
[INFO] Running org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.195
s <<< FAILURE! - in org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR]
testBearerSAML2Token(org.apache.cxf.systest.sts.itests.unit.STSUnitTest) Time
elapsed: 2.99 s <<< ERROR!
javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factory:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl cannot be cast to
javax.xml.soap.SAAJMetaFactory
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.requestSecurityToken(STSUnitTest.java:135)
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.testBearerSAML2Token(STSUnitTest.java:84)
{code}
Should be SAAJ related(javax.xml.soap)
was (Author: ffang):
Hi [~reta], when you build, all tests passed?
I ran into this error when building CXF-7910_jakarta_jaxws-api branch with JDK8
{code}
[INFO] Running org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.195
s <<< FAILURE! - in org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR]
testBearerSAML2Token(org.apache.cxf.systest.sts.itests.unit.STSUnitTest) Time
elapsed: 2.99 s <<< ERROR!
javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factory:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl cannot be cast to
javax.xml.soap.SAAJMetaFactory
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.requestSecurityToken(STSUnitTest.java:135)
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.testBearerSAML2Token(STSUnitTest.java:84)
{code}
Should be SAAJ related(javax.xml.soap)
> Change JAX-WS javax to jakarta artifact dependencies
>
>
> Key: CXF-7910
> URL: https://issues.apache.org/jira/browse/CXF-7910
> Project: CXF
> Issue Type: Task
> Components: JAX-WS Runtime
>Reporter: Dennis Kieselhorst
>Assignee: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See https://github.com/eclipse-ee4j/jax-ws-api/issues/46
> According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be
> released on 2018-12-14.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[
https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742718#comment-16742718
]
Freeman Fang edited comment on CXF-7910 at 1/15/19 3:56 AM:
Hi [~reta], when you build, all tests passed?
I ran into this error when building CXF-7910_jakarta_jaxws-api branch with JDK8
and JDK11
{code}
[INFO] Running org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.195
s <<< FAILURE! - in org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR]
testBearerSAML2Token(org.apache.cxf.systest.sts.itests.unit.STSUnitTest) Time
elapsed: 2.99 s <<< ERROR!
javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factory:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl cannot be cast to
javax.xml.soap.SAAJMetaFactory
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.requestSecurityToken(STSUnitTest.java:135)
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.testBearerSAML2Token(STSUnitTest.java:84)
{code}
Should be SAAJ related(javax.xml.soap), two versions of
javax.xml.soap.SAAJMetaFactory were loaded and wired. I'm checking this
was (Author: ffang):
Hi [~reta], when you build, all tests passed?
I ran into this error when building CXF-7910_jakarta_jaxws-api branch with JDK8
and JDK11
{code}
[INFO] Running org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.195
s <<< FAILURE! - in org.apache.cxf.systest.sts.itests.unit.STSUnitTest
[ERROR]
testBearerSAML2Token(org.apache.cxf.systest.sts.itests.unit.STSUnitTest) Time
elapsed: 2.99 s <<< ERROR!
javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factory:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl cannot be cast to
javax.xml.soap.SAAJMetaFactory
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.requestSecurityToken(STSUnitTest.java:135)
at
org.apache.cxf.systest.sts.itests.unit.STSUnitTest.testBearerSAML2Token(STSUnitTest.java:84)
{code}
Should be SAAJ related(javax.xml.soap)
> Change JAX-WS javax to jakarta artifact dependencies
>
>
> Key: CXF-7910
> URL: https://issues.apache.org/jira/browse/CXF-7910
> Project: CXF
> Issue Type: Task
> Components: JAX-WS Runtime
>Reporter: Dennis Kieselhorst
>Assignee: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See https://github.com/eclipse-ee4j/jax-ws-api/issues/46
> According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be
> released on 2018-12-14.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742720#comment-16742720 ] Freeman Fang commented on CXF-7907: --- [~deki], the cxf-xjc-untils jaxb upgrade tracked by https://issues.apache.org/jira/browse/CXFXJC-31 > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7907. --- Resolution: Fixed > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742748#comment-16742748 ] Freeman Fang commented on CXF-7910: --- OK, I figured out why. The jakarta soap-api 1.4 can't find saaj-impl bundle in OSGi container. I'd say the SPI mechanism in OSGi is one of the most tricky part when running CXF in OSGi container. And that's why we use Servicemix wrapped specs bundles.There is definitely more work to use jaxws 2.3 and hence saaj-api 1.4(And some work need to be done at both Karaf and Servicemix side). I suggest we postpone this issue to CXF 3.3.1, as I don't think we want to delay CXF 3.3.0 release indefinitely. What do you think guys? Thanks! Freeman > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
