May 2018 - jboss-jira - Jboss List Archives

[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 Petr Kremensky (JIRA)

Petr Kremensky created WFLY-10336: ------------------------------------- Summary: 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: Jan Blizňák 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.5.0#75005)

8 years, 2 months

1
0
0 / 0

[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 Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-10336?page=com.atlassian.jira.plugin... ] Petr Kremensky commented on WFLY-10336: --------------------------------------- [~jbliznak] Could you please take a look into this? > 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: Jan Blizňák > > 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.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9463) Deprecate jndi-name attributes of Infinispan cache-container and cache.

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-9463?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling edited comment on WFLY-9463 at 5/7/18 7:45 AM: ------------------------------------------------------------------------- Found your answer here aswell: https://developer.jboss.org/message/981088#981088 . Thanks! was (Author: jwgmeligmeyling): Nevermind, found the answer here: https://developer.jboss.org/message/981088#981088 . Thanks! > Deprecate jndi-name attributes of Infinispan cache-container and cache. > ----------------------------------------------------------------------- > > Key: WFLY-9463 > URL: https://issues.jboss.org/browse/WFLY-9463 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > There's no reason to expose these. These attributes add little value and are only a source of confusion. Applications can always leverage a resource-ref or resource-env-ref to customize the JNDI name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9463) Deprecate jndi-name attributes of Infinispan cache-container and cache.

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-9463?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling edited comment on WFLY-9463 at 5/7/18 7:45 AM: ------------------------------------------------------------------------- Nevermind, found the answer here: https://developer.jboss.org/message/981088#981088 . Thanks! was (Author: jwgmeligmeyling): Nevermind, found the answer here: https://developer.jboss.org/message/981088#981088 > Deprecate jndi-name attributes of Infinispan cache-container and cache. > ----------------------------------------------------------------------- > > Key: WFLY-9463 > URL: https://issues.jboss.org/browse/WFLY-9463 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > There's no reason to expose these. These attributes add little value and are only a source of confusion. Applications can always leverage a resource-ref or resource-env-ref to customize the JNDI name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9463) Deprecate jndi-name attributes of Infinispan cache-container and cache.

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-9463?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling commented on WFLY-9463: ------------------------------------------------- Nevermind, found the answer here: https://developer.jboss.org/message/981088#981088 > Deprecate jndi-name attributes of Infinispan cache-container and cache. > ----------------------------------------------------------------------- > > Key: WFLY-9463 > URL: https://issues.jboss.org/browse/WFLY-9463 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > There's no reason to expose these. These attributes add little value and are only a source of confusion. Applications can always leverage a resource-ref or resource-env-ref to customize the JNDI name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10335) Elytron testsuite resource should be in java directory

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-10335?page=com.atlassian.jira.plugin... ] Stuart Douglas commented on WFLY-10335: --------------------------------------- So to elaborate a bit the main reason behind this is that WildFly is different to a lot applications that are build using maven. If you are building a standard application you have one copy of each relevant descriptor, if you have special test version of them it is fine to have them in src/test/resources, as they are used for all tests. WildFly is not like this, every test has its own deployment descriptors. There is simply no point in having a mirrored package structure, it just means that you need to look at multiple locations to fully understand a test, and generally complicates the code base. In general we will follow maven conventions unless there is a good reason not to, and in this case the benefit of having all test resources being self contained is a lot more important that following the maven conventions. > Elytron testsuite resource should be in java directory > ------------------------------------------------------ > > Key: WFLY-10335 > URL: https://issues.jboss.org/browse/WFLY-10335 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > As request by [~swd847], elytron testsuite (wildfly/testsuite/integration/elytron) should have resources in src/test/java directory, instead of src/test/resources, to be consistent with the rest of the testsuites. > ??they are in src/test/resources rather than src/test/java like the rest of the test suite?? > ??If you look back maybe 6-7 years there was a discussion on wildly dev as to why we do it this way?? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9463) Deprecate jndi-name attributes of Infinispan cache-container and cache.

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9463?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-9463: ------------------------------------ [~jwgmeligmeyling] Once started, the following Infinispan artifacts are available at the following JNDI contexts: * Cache Manager: java:jboss/infinispan/container/_container-name_/ * Cache configuration: java:jboss/infinispan/configuration/_container-name_/_cache-name_ * Cache: java:jboss/infinispan/cache/_container-name_/_cache-name_ If you'd rather not reference a global JNDI namespace in your application, you can use a resource-ref or resource-env-ref to use an application-specific JNDI namespace. > Deprecate jndi-name attributes of Infinispan cache-container and cache. > ----------------------------------------------------------------------- > > Key: WFLY-9463 > URL: https://issues.jboss.org/browse/WFLY-9463 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > There's no reason to expose these. These attributes add little value and are only a source of confusion. Applications can always leverage a resource-ref or resource-env-ref to customize the JNDI name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9463) Deprecate jndi-name attributes of Infinispan cache-container and cache.

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-9463?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling commented on WFLY-9463: ------------------------------------------------- So how are we supposed to reach our caches through JNDI now? I can't seem to find them in the JNDI View? > Deprecate jndi-name attributes of Infinispan cache-container and cache. > ----------------------------------------------------------------------- > > Key: WFLY-9463 > URL: https://issues.jboss.org/browse/WFLY-9463 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > There's no reason to expose these. These attributes add little value and are only a source of confusion. Applications can always leverage a resource-ref or resource-env-ref to customize the JNDI name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1405) The password attribute of resource owner credentials should support a credential store reference

by Martin Mazanek (JIRA)

[ https://issues.jboss.org/browse/ELY-1405?page=com.atlassian.jira.plugin.s... ] Martin Mazanek updated ELY-1405: -------------------------------- Fix Version/s: 1.2.0.Final (was: 1.3.2.CR1) > The password attribute of resource owner credentials should support a credential store reference > ------------------------------------------------------------------------------------------------ > > Key: ELY-1405 > URL: https://issues.jboss.org/browse/ELY-1405 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Martin Mazanek > Fix For: 1.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10335) Elytron testsuite resource should be in java directory

by Jan Kalina (JIRA)

Jan Kalina created WFLY-10335: --------------------------------- Summary: Elytron testsuite resource should be in java directory Key: WFLY-10335 URL: https://issues.jboss.org/browse/WFLY-10335 Project: WildFly Issue Type: Enhancement Components: Test Suite Affects Versions: 12.0.0.Final Reporter: Jan Kalina Assignee: Jan Kalina Priority: Minor As request by [~swd847], elytron testsuite (wildfly/testsuite/integration/elytron) should have resources in src/test/java directory, instead of src/test/resources, to be consistent with the rest of the testsuites. ??they are in src/test/resources rather than src/test/java like the rest of the test suite?? ??If you look back maybe 6-7 years there was a discussion on wildly dev as to why we do it this way?? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2018