[Red Hat JIRA] (WFLY-14162) EE-9 distribution must use jakarta JAXB API & Impl versions
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14162?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFLY-14162:
---------------------------------------
Hello [~xf01213] , there's no plan to Upgrade CXF to 3.3.8 - we detected few issues with 3.3.8, right [~ema1] ?
> EE-9 distribution must use jakarta JAXB API & Impl versions
> -----------------------------------------------------------
>
> Key: WFLY-14162
> URL: https://issues.redhat.com/browse/WFLY-14162
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 22.0.0.Alpha1
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
> Labels: EE9
>
> 2020-12-04 10:24:37,138 INFO [stdout] (MSC service thread 1-7) DefaultValidationEventHandler: [ERROR]: unexpected element (uri:"https://jakarta.ee/xml/ns/jakartaee", local:"handler-name"). Expected elements are <\{http://java.sun.com/xml/ns/javaee}display-name>,<\{http://java.sun.com/xml/ns/javaee}init-param>,<\{http://java.sun.com/xml/ns/javaee}soap-role>,<\{http://java.sun.com/xml/ns/javaee}soap-header>,<\{http://java.sun.com/xml/ns/javaee}handler-class>,<\{http://java.sun.com/xml/ns/javaee}icon>,<\{http://java.sun.com/xml/ns/javaee}handler-name>,<\{http://java.sun.com/xml/ns/javaee}description>
> 2020-12-04 10:24:37,138 INFO [stdout] (MSC service thread 1-7) Location: node: [handler-name: null]
> 2020-12-04 10:24:37,139 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."WSEjbWSRefAndAddressingCombinedTest.ear"."WSEjbWSRefAndAddressingCombinedTest_ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."WSEjbWSRefAndAddressingCombinedTest.ear"."WSEjbWSRefAndAddressingCombinedTest_ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "WSEjbWSRefAndAddressingCombinedTest_ejb.jar" of deployment "WSEjbWSRefAndAddressingCombinedTest.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189) [wildfly-server-14.0.0.Beta3-SNAPSHOT.jar:14.0.0.Beta3-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_271]
> Caused by: jakarta.xml.ws.WebServiceException: jakarta.xml.ws.WebServiceException: Chain not specified
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:375)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:80)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
> at org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:236)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182) [wildfly-server-14.0.0.Beta3-SNAPSHOT.jar:14.0.0.Beta3-SNAPSHOT]
> ... 8 more
> Caused by: jakarta.xml.ws.WebServiceException: Chain not specified
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:158)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:327)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.buildHandlerChain(JaxWsServerFactoryBean.java:248)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.initializeResourcesAndHandlerChain(JaxWsServerFactoryBean.java:227)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:212)
> at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
> ... 16 more
> Caused by: java.lang.IllegalArgumentException: Could not unmarshal handler chain
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerElement(AnnotationHandlerChainBuilder.java:313)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerChainElement(AnnotationHandlerChainBuilder.java:211)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:150)
> ... 22 more
> Caused by: jakarta.xml.bind.UnmarshalException: unexpected element (uri:"https://jakarta.ee/xml/ns/jakartaee", local:"handler-name"). Expected elements are <\{http://java.sun.com/xml/ns/javaee}display-name>,<\{http://java.sun.com/xml/ns/javaee}init-param>,<\{http://java.sun.com/xml/ns/javaee}soap-role>,<\{http://java.sun.com/xml/ns/javaee}soap-header>,<\{http://java.sun.com/xml/ns/javaee}handler-class>,<\{http://java.sun.com/xml/ns/javaee}icon>,<\{http://java.sun.com/xml/ns/javaee}handler-name>,<\{http://java.sun.com/xml/ns/javaee}description>
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:713)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:232)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:227)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:94)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:75)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:238)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:543)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:525)
> at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:45)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:214)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:251)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:220)
> at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:97)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:339)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:318)
> at org.apache.cxf.common.jaxb.JAXBUtils.unmarshall(JAXBUtils.java:203)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerElement(AnnotationHandlerChainBuilder.java:310)
> ... 24 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-14199:
--------------------------------------
It looks like the issue is the test. Since there is an attempt to deploy a broken deployment the undeploy does not correctly happen leaving the {{ResteasyProviderFactory}} in an invalid state because the server is not destroyed. I'm not sure if there is a way in the {{RestEasyDeployment}} to invoke {{stop()}} on a failed deployment, but that would be the solution. It is a little concerning one deployments bean manager can end up associated with another deployment. I'll file a RESTEasy issue for that. However the WildFly fix is to fix the test which I will submit a PR for.
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (ELY-2059) SSL Tests Failing on Zulu JDK 11
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-2059:
-------------------------------------
Summary: SSL Tests Failing on Zulu JDK 11
Key: ELY-2059
URL: https://issues.redhat.com/browse/ELY-2059
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Reporter: Darran Lofthouse
The following tests are presently failing:
{code:java}
Results :Failed tests:
MaskedPasswordSSLAuthenticationTest.testTwoWay:260->performConnectionTest:273->performConnectionTest:303 Client SSL Session should be Valid
Tests in error:
SSLAuthenticationTest.testCRLMaxCertPathSucceeds:664->performConnectionTest:804 IllegalState
SSLAuthenticationTest.testCrlBlank:633->performConnectionTest:804 IllegalState
SSLAuthenticationTest.testOcspGood:720->performConnectionTest:804 IllegalState
SSLAuthenticationTest.testOcspMaxCertPathOkay:741->ocspMaxCertPathCommon:756->performConnectionTest:804 IllegalState
SSLAuthenticationTest.testOneWay:624->performConnectionTest:804 IllegalState U...
SSLAuthenticationTest.testTwoWay:690->performConnectionTest:804 IllegalState U...
SSLAuthenticationTest.testTwoWayIca:703->performConnectionTest:804 IllegalState {code}
{code:java}
$ java -version
openjdk version "11.0.9" 2020-10-20 LTS
OpenJDK Runtime Environment Zulu11.43+21-CA (build 11.0.9+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+21-CA (build 11.0.9+11-LTS, mixed mode) {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14162) EE-9 distribution must use jakarta JAXB API & Impl versions
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFLY-14162?page=com.atlassian.jira.plugi... ]
Boris Unckel commented on WFLY-14162:
-------------------------------------
[~ropalka] You're already working on CXF 3.3.9 here. Does it make sense to provide a 3.3.8 patch to WF? I don't want to slow down your work with checking/approving/denying things which will get obsolete soon. If I can help, I can provide a Jira/PR for 3.3.8. I already tried a full test, it's working.
> EE-9 distribution must use jakarta JAXB API & Impl versions
> -----------------------------------------------------------
>
> Key: WFLY-14162
> URL: https://issues.redhat.com/browse/WFLY-14162
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 22.0.0.Alpha1
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
> Labels: EE9
>
> 2020-12-04 10:24:37,138 INFO [stdout] (MSC service thread 1-7) DefaultValidationEventHandler: [ERROR]: unexpected element (uri:"https://jakarta.ee/xml/ns/jakartaee", local:"handler-name"). Expected elements are <\{http://java.sun.com/xml/ns/javaee}display-name>,<\{http://java.sun.com/xml/ns/javaee}init-param>,<\{http://java.sun.com/xml/ns/javaee}soap-role>,<\{http://java.sun.com/xml/ns/javaee}soap-header>,<\{http://java.sun.com/xml/ns/javaee}handler-class>,<\{http://java.sun.com/xml/ns/javaee}icon>,<\{http://java.sun.com/xml/ns/javaee}handler-name>,<\{http://java.sun.com/xml/ns/javaee}description>
> 2020-12-04 10:24:37,138 INFO [stdout] (MSC service thread 1-7) Location: node: [handler-name: null]
> 2020-12-04 10:24:37,139 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."WSEjbWSRefAndAddressingCombinedTest.ear"."WSEjbWSRefAndAddressingCombinedTest_ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."WSEjbWSRefAndAddressingCombinedTest.ear"."WSEjbWSRefAndAddressingCombinedTest_ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "WSEjbWSRefAndAddressingCombinedTest_ejb.jar" of deployment "WSEjbWSRefAndAddressingCombinedTest.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189) [wildfly-server-14.0.0.Beta3-SNAPSHOT.jar:14.0.0.Beta3-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) [jboss-msc-1.4.12.Final.jar:1.4.12.Final]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) [jboss-threads-2.4.0.Final.jar:2.4.0.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_271]
> Caused by: jakarta.xml.ws.WebServiceException: jakarta.xml.ws.WebServiceException: Chain not specified
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:375)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:80)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
> at org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:236)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182) [wildfly-server-14.0.0.Beta3-SNAPSHOT.jar:14.0.0.Beta3-SNAPSHOT]
> ... 8 more
> Caused by: jakarta.xml.ws.WebServiceException: Chain not specified
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:158)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:327)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.buildHandlerChain(JaxWsServerFactoryBean.java:248)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.initializeResourcesAndHandlerChain(JaxWsServerFactoryBean.java:227)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:212)
> at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
> ... 16 more
> Caused by: java.lang.IllegalArgumentException: Could not unmarshal handler chain
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerElement(AnnotationHandlerChainBuilder.java:313)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerChainElement(AnnotationHandlerChainBuilder.java:211)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:150)
> ... 22 more
> Caused by: jakarta.xml.bind.UnmarshalException: unexpected element (uri:"https://jakarta.ee/xml/ns/jakartaee", local:"handler-name"). Expected elements are <\{http://java.sun.com/xml/ns/javaee}display-name>,<\{http://java.sun.com/xml/ns/javaee}init-param>,<\{http://java.sun.com/xml/ns/javaee}soap-role>,<\{http://java.sun.com/xml/ns/javaee}soap-header>,<\{http://java.sun.com/xml/ns/javaee}handler-class>,<\{http://java.sun.com/xml/ns/javaee}icon>,<\{http://java.sun.com/xml/ns/javaee}handler-name>,<\{http://java.sun.com/xml/ns/javaee}description>
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:713)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:232)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:227)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:94)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:75)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:238)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:543)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:525)
> at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:45)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:214)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:251)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:220)
> at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:97)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:339)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:318)
> at org.apache.cxf.common.jaxb.JAXBUtils.unmarshall(JAXBUtils.java:203)
> at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.processHandlerElement(AnnotationHandlerChainBuilder.java:310)
> ... 24 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5226) No acceptedIssuers is sent when CRLs are configured
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5226?page=com.atlassian.jira.plug... ]
Farah Juma edited comment on WFCORE-5226 at 12/11/20 11:56 AM:
---------------------------------------------------------------
[~szaldana] I think the underlying issue here is in {{X509RevocationTrustManager}}:
* Notice that the {{trustStore}} that is specified using the {{X509RevocationTrustManager.Builder}} is successfully used to instantiate the {{trustManager}} in the {{X509RevocationTrustManager}} [constructor|https://github.com/wildfly-security/wildfly-elytron/blob/1.x/...].
* A call to {{trustManager.getAcceptedIssuers()}} would return the correct accepted issuers.
* However, the {{X509RevocationTrustManager#getAcceptedIssuers}} method actually returns the value of {{builder.acceptedIssuers}}. This means that if no accepted issuers have been explicitly configured using the {{builder}}, {{X509RevocationTrustManager#getAcceptedIssuers}} returns {{X500.NO_CERTIFICATES}}.
* If no accepted issuers have been explicitly configured, I think we should delegate to the {{trustManager#getAcceptedIssuers}} method instead of using {{X500.NO_CERTIFICATES}}.
* We should also deprecate the {{X509RevocationTrustManager.Builder#setAcceptedIssuers}} method. It's not clear why it was added in the first place. There's no need for this method since we should always be delegating to {{trustManager#getAcceptedIssuers}}.
was (Author: fjuma):
[~szaldana] I think the underlying issue here is in {{X509RevocationTrustManager}}:
* Notice that the {{trustStore}} that is specified using the {{X509RevocationTrustManager.Builder}} is successfully used to instantiate the {{trustManager}} in the {{X509RevocationTrustManager}} [constructor|https://github.com/wildfly-security/wildfly-elytron/blob/1.x/...].
* A call to {{trustManager.getAcceptedIssuers()}} would return the correct accepted issuers.
* However, the {{X509RevocationTrustManager#getAcceptedIssuers}} method actually returns the value of {{builder.acceptedIssuers}}. This means that if no accepted issuers have been explicitly configured using the {{builder}}, {{X509RevocationTrustManager#getAcceptedIssuers}} returns {{X500.NO_CERTIFICATES}}.
* If no accepted issuers have been explicitly configured, I think we should delegate to the {{trustManager#getAcceptedIssuers}} method instead of using {{X500.NO_CERTIFICATES}}.
> No acceptedIssuers is sent when CRLs are configured
> ---------------------------------------------------
>
> Key: WFCORE-5226
> URL: https://issues.redhat.com/browse/WFCORE-5226
> Project: WildFly Core
> Issue Type: Bug
> Reporter: David MAFFRAND
> Assignee: Sonia Zaldana
> Priority: Major
>
> When CRLs are configured there're no client certificate CA names sent for a tls 2 way connexion.
> Method setAcceptedIssuers of X509RevocationTrustManager builder is never called, so acceptedIssuers is always empty.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (ELY-2058) Accepted Issuers should not be manually configured in X509RevocationTrustManager
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/ELY-2058?page=com.atlassian.jira.plugin.... ]
Sonia Zaldana updated ELY-2058:
-------------------------------
Description:
In the X509RevocationTrustManager.Builder class, we can currently configure the trust manager's accepted issuers. However, the accepted issuers should only be the certificates stored in the trust store.
Allowing users to specify their own accepted issuers could contradict the trust manager's actual accepted issuers.
was:
In the X509RevocationTrustManager.Builder class, we can currently configure the trust manager's accepted issuers. However, the accepted issuers should only be the certificates stored in the trust store.
Allowing users to specify their own accepted issuers could contradict the trust store's actual accepted issuers.
> Accepted Issuers should not be manually configured in X509RevocationTrustManager
> --------------------------------------------------------------------------------
>
> Key: ELY-2058
> URL: https://issues.redhat.com/browse/ELY-2058
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> In the X509RevocationTrustManager.Builder class, we can currently configure the trust manager's accepted issuers. However, the accepted issuers should only be the certificates stored in the trust store.
> Allowing users to specify their own accepted issuers could contradict the trust manager's actual accepted issuers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months