[JBoss JIRA] (WFLY-11505) XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11505?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-11505.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
> -------------------------------------------------------------------------
>
> Key: WFLY-11505
> URL: https://issues.jboss.org/browse/WFLY-11505
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Affects Versions: 16.0.0.Beta1
> Environment: IBM Java 8, build 8.0.5.25 or 8.0.5.26
> Reporter: Ondrej Kotek
> Assignee: Bartosz Baranowski
> Priority: Major
>
> {{org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService}} fails with security manager on IBM Java 8 due to missing permissions:
> {noformat}
> SEVERE [org.apache.cxf.frontend.WSDLGetInterceptor] (default task-3) WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader"): java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:490)
> at java.lang.J9VMInternals$2.run(J9VMInternals.java:268)
> at java.security.AccessController.doPrivileged(AccessController.java:673)
> at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:263)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:379)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:1734)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:519)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1013)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1043)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:705)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$825.000000005C9627C0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(AccessController.java:703)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:812)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4724) DMN editor to not default to LiteralExpr when no expr defined
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-4724:
--------------------------------------
Summary: DMN editor to not default to LiteralExpr when no expr defined
Key: DROOLS-4724
URL: https://issues.jboss.org/browse/DROOLS-4724
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Reporter: Matteo Mortari
Assignee: Guilherme Gomes
Attachments: image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ]
Nistor Adrian updated JGRP-2394:
--------------------------------
Description:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
was:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
> Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2394
> URL: https://issues.jboss.org/browse/JGRP-2394
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Nistor Adrian
> Assignee: Bela Ban
> Priority: Major
>
> The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
> So we propose adding someting like this:
> JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
> which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
Nistor Adrian created JGRP-2394:
-----------------------------------
Summary: Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
Key: JGRP-2394
URL: https://issues.jboss.org/browse/JGRP-2394
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.1.6
Reporter: Nistor Adrian
Assignee: Bela Ban
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4715) [DMN Designer] Structure is lost when user doesn't drag it enough
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4715?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4715:
------------------------------------
Description:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
---
⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
was:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> [DMN Designer] Structure is lost when user doesn't drag it enough
> -----------------------------------------------------------------
>
> Key: DROOLS-4715
> URL: https://issues.jboss.org/browse/DROOLS-4715
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.30.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: drag-not-enough.webm
>
>
> This issue is caused by DROOLS-4484
> If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> ---
> ⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10336) MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10336?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-10336.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10336
> URL: https://issues.jboss.org/browse/WFLY-10336
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Environment: {noformat}
> Java(TM) SE Runtime Environment (build 8.0.5.11 - pxa6480sr5fp11-20180326_01(SR5 FP11))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180309_380776 (JIT enabled, AOT enabled)
> OpenJ9 - 49fcaf39
> OMR - 5cbbadf
> IBM - 4453dac)
> JCL - 20180319_01 based on Oracle jdk8u161-b12
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Daniel Cihak
> Priority: Major
>
> There are test failures running the WildFly Test Suite: Integration - WS on IBM jdk.
> {noformat}
> wildfly/testsuite/integration/ws] $ mvn clean install
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR] EJBSignTestCase.signedRequest:86 » SOAPFault MustUnderstand headers: [{http://...
> [ERROR] SignTestCase.signedRequest:88 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:90 » SOAPFault
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:102 » SOAPFault
> [ERROR] EJBSignEncryptTestCase.encryptedAndSignedRequest:88 » SOAPFault MustUnderstand...
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:91 » SOAPFault
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:103 » SOAPFault
> [ERROR] SignEncryptTestCase.encryptedAndSignedRequest:90 » SOAPFault MustUnderstand he...
> [ERROR] WSTrustTestCase.test:318 » SOAPFault MustUnderstand headers: [{http://docs.oas...
> [ERROR] WSTrustTestCase.testActAs:441 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] WSTrustTestCase.testBearer:541 » SOAPFault MustUnderstand headers: [{http://do...
> [ERROR] WSTrustTestCase.testHolderOfKey:491 » SOAPFault MustUnderstand headers: [{http...
> [ERROR] WSTrustTestCase.testNoClientCallback:383 » SOAPFault MustUnderstand headers: [...
> [ERROR] WSTrustTestCase.testNoSignatureUsername:414 » SOAPFault MustUnderstand headers...
> [ERROR] WSTrustTestCase.testOnBehalfOf:468 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testPicketLink:518 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testUsingEPR:350 » SOAPFault MustUnderstand headers: [{http://...
> [INFO]
> [ERROR] Tests run: 119, Failures: 0, Errors: 17, Skipped: 0
> {noformat}
> *Caused by*
> {noformat}
> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:87)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:53)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:42)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:70)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:35)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:827)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1695)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1572)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1373)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:673)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:442)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:343)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> ... 129 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-11178.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: MSC
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12458) WebServices tests failing in IBM JDK8
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12458?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-12458.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> WebServices tests failing in IBM JDK8
> -------------------------------------
>
> Key: WFLY-12458
> URL: https://issues.jboss.org/browse/WFLY-12458
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Environment: java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
>
> [ERROR] EJBSignTestCase.signedRequest:86 » SOAPFault MustUnderstand headers: [{http://...
> [ERROR] SignTestCase.signedRequest:88 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:90 » SOAPFault
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:102 » SOAPFault
> [ERROR] EJBSignEncryptTestCase.encryptedAndSignedRequest:88 » SOAPFault MustUnderstand...
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:91 » SOAPFault
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:103 » SOAPFault
> [ERROR] SignEncryptTestCase.encryptedAndSignedRequest:90 » SOAPFault MustUnderstand he...
> [ERROR] WSBearerElytronSecurityPropagationTestCase.testBearer:133 » SOAPFault MustUnde...
> [ERROR] WSBearerSecurityPropagationTestCase.testBearer:133 » SOAPFault MustUnderstand ...
> [ERROR] WSTrustTestCase.test:319 » SOAPFault MustUnderstand headers: [{http://docs.oas...
> [ERROR] WSTrustTestCase.testActAs:442 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] WSTrustTestCase.testBearer:553 » SOAPFault MustUnderstand headers: [{http://do...
> [ERROR] WSTrustTestCase.testHolderOfKey:494 » SOAPFault MustUnderstand headers: [{http...
> [ERROR] WSTrustTestCase.testNoClientCallback:384 » SOAPFault MustUnderstand headers: [...
> [ERROR] WSTrustTestCase.testNoSignatureUsername:415 » SOAPFault MustUnderstand headers...
> [ERROR] WSTrustTestCase.testOnBehalfOf:469 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testPicketLink:526 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testUsingEPR:351 » SOAPFault MustUnderstand headers: [{http://...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month