November 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3842) Cannot boot server with 2+ handlers in the same predefined configuration handler chain

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3842?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3842: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Cannot boot server with 2+ handlers in the same predefined configuration handler chain > -------------------------------------------------------------------------------------- > > Key: JBWS-3842 > URL: https://issues.jboss.org/browse/JBWS-3842 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.3 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > > Commit https://github.com/wildfly/wildfly/commit/e32f27d433ad3da41ef042f1ad9b950... introduced a regressions when having multiple handlers in the same handler-chain within one of the pre-defined configuration in the webservices subsystem: > {noformat} > 5:49:24,653 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: org.jboss.msc.service.StartException in service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60] > Caused by: org.jboss.msc.inject.InjectionException: Value already set for this injector > at org.jboss.msc.inject.RetainingInjector.inject(RetainingInjector.java:50) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.as.webservices.dmr.ListInjector.inject(ListInjector.java:23) > at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:55) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3816) WSTrustActAsTestCase.testActAs failing with move to CXF 3.0.2/2.7.13

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3816?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3816: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > WSTrustActAsTestCase.testActAs failing with move to CXF 3.0.2/2.7.13 > -------------------------------------------------------------------- > > Key: JBWS-3816 > URL: https://issues.jboss.org/browse/JBWS-3816 > Project: JBoss Web Services > Issue Type: Bug > Reporter: R Searls > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > Attachments: CXF-5885.patch > > > WSTrustActAsTestCase.testActAs is failing with the following error > Stacktrace > javax.xml.ws.soap.SOAPFaultException: The specified request failed > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159) > at com.sun.proxy.$Proxy203.sayHello(Unknown Source) > at org.jboss.test.ws.jaxws.samples.wsse.policy.trust.WSTrustActAsTestCase.testActAs(WSTrustActAsTestCase.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at junit.framework.TestSuite.run(TestSuite.java:238) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:141) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:148) > at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > Caused by: org.apache.cxf.binding.soap.SoapFault: The specified request failed > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84) > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51) > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113) > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1636) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638) > at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:839) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:52) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.getTokenFromSTS(IssuedTokenInterceptorProvider.java:394) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.issueToken(IssuedTokenInterceptorProvider.java:523) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.handleMessage(IssuedTokenInterceptorProvider.java:162) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137) > ... 31 more > Standard Error > Warning: org.apache.xerces.parsers.SAXParser: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized. > Warning: org.apache.xerces.parsers.SAXParser: Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3847: ---------------------------------- Fix Version/s: (was: jbossws-cxf-5.0) > Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor > ---------------------------------------------------------------- > > Key: JBWS-3847 > URL: https://issues.jboss.org/browse/JBWS-3847 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2 > > > {{HandlerChainSortInterceptor.handleMessage(Message)}} sorts and sets JAX-WS handlers every time it handles a SOAP message: > {code:java} > public void handleMessage(Message message) throws Fault > { > if (binding != null) { > @SuppressWarnings("rawtypes") > List<Handler> list = binding.getHandlerChain(); > if (list != null && !list.isEmpty()) { > Collections.sort(list, comparator); > binding.setHandlerChain(list); > } > } > } > {code} > However, inside the {{org.apache.cxf.jaxws.binding.AbstractBindingImpl}} and {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} implementations the handler chain is not reset every time but piled up with interceptors, which leads to subtle but indefinite memory leak in JBoss WS CXF client. > Furthermore, {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} holds the interceptors as a kind of {{java.util.concurrent.CopyOnWriteArrayList}}. So modifying the growing list of interceptors per each message should cause a growing performance drawback, which is also not a good implementation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3838) Predefined configuration handlers executing in different order when server is restarted

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3838?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3838: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Predefined configuration handlers executing in different order when server is restarted > --------------------------------------------------------------------------------------- > > Key: JBWS-3838 > URL: https://issues.jboss.org/browse/JBWS-3838 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: david.boeren > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > > Handler order can change after a reboot, which causes problems when one handler depends on the action of another. > * Description of the problem > The flow is basically the following: > 1) the container model is parsed; it can include jaxws configs, which are composed > of jaxws handler chains, which in turn has one or multiple jaxws handlers > 2) we have add operations for each jaxws handler and jaxws handler > chain. Each of them starts a service, which builds up the corresponding > metadata to be later used by jbossws; proper dependencies are set > between those services, so that for instance the service for a handler > chain waits for all its handlers' services. > 3) when the service for the handler chain runs, it gets the info from > the handler services and them in the chain metadata. This is where I get > unpredictable ordering, as the handler services are run in parallel > * Solution > The idea is that we need to derive the handlers' order from the add operation steps, which are executed in the same order they're created in the parser. > Brian also suggests to use the OperationContext.attach(...) API to pass data between handler invocations within an overall operation execution. All ws subsystem ops during boot are executed as steps within an overall operation. The API works like the attachment stuff that's used a lot in DeploymentUnitProcessors. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3847: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 > Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor > ---------------------------------------------------------------- > > Key: JBWS-3847 > URL: https://issues.jboss.org/browse/JBWS-3847 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > > {{HandlerChainSortInterceptor.handleMessage(Message)}} sorts and sets JAX-WS handlers every time it handles a SOAP message: > {code:java} > public void handleMessage(Message message) throws Fault > { > if (binding != null) { > @SuppressWarnings("rawtypes") > List<Handler> list = binding.getHandlerChain(); > if (list != null && !list.isEmpty()) { > Collections.sort(list, comparator); > binding.setHandlerChain(list); > } > } > } > {code} > However, inside the {{org.apache.cxf.jaxws.binding.AbstractBindingImpl}} and {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} implementations the handler chain is not reset every time but piled up with interceptors, which leads to subtle but indefinite memory leak in JBoss WS CXF client. > Furthermore, {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} holds the interceptors as a kind of {{java.util.concurrent.CopyOnWriteArrayList}}. So modifying the growing list of interceptors per each message should cause a growing performance drawback, which is also not a good implementation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3831) Failure of test org.jboss.test.ws.jaxws.samples.wsse.policy.oasis.WSSecurityPolicyExamples23xTestCase

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3831?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3831: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Failure of test org.jboss.test.ws.jaxws.samples.wsse.policy.oasis.WSSecurityPolicyExamples23xTestCase > ----------------------------------------------------------------------------------------------------- > > Key: JBWS-3831 > URL: https://issues.jboss.org/browse/JBWS-3831 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: R Searls > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > > This test failure started with the switch to jbossws-cxf (5.0.0-SNAPSHOT). > Only tests test2311 and test2321 in org.jboss.test.ws.jaxws.samples.wsse.policy.oasis.WSSecurityPolicyExamples23xTestCase are failing. > --- > test2321(org.jboss.test.ws.jaxws.samples.wsse.policy.oasis.WSSecurityPolicyExamples23xTestCase): > An error was discovered processing the <wsse:Security> header. > test2311(org.jboss.test.ws.jaxws.samples.wsse.policy.oasis.WSSecurityPolicyExamples23xTestCase): > SAML token security failure -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3848) Optimize HandlerChainSortInterceptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3848?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3848: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Optimize HandlerChainSortInterceptor > ------------------------------------ > > Key: JBWS-3848 > URL: https://issues.jboss.org/browse/JBWS-3848 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > > HandlerChainSortInterceptor needs to be optimized to avoid setting the handler chain after having sorted it if the sort operation actually did nothing relevant. > We should detect if we really need to sort (because of PRE/POST handlers) and relax the sorting requirement (we only care about the PRE/POST thing, not about the internal order of user handlers). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3843) Username Token Digest Authentication failure with EJB3 endpoints

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3843?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3843: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Username Token Digest Authentication failure with EJB3 endpoints > ---------------------------------------------------------------- > > Key: JBWS-3843 > URL: https://issues.jboss.org/browse/JBWS-3843 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration, ws-security > Affects Versions: jbossws-cxf-4.3.1 > Environment: JBoss EAP 6.3.1 > Reporter: Mustafa Musaji > Assignee: Jim Ma > Priority: Critical > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2 > > Attachments: ClientSample.java, javaee-ws-with-security_1413372207000.zip > > > EJB3 Web Service using username token for digest authentication fails when you load test it with parallel invocations. See attached reproducer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3789) Enable WS-Security streaming (StAX) support

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3789?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3789: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Enable WS-Security streaming (StAX) support > ------------------------------------------- > > Key: JBWS-3789 > URL: https://issues.jboss.org/browse/JBWS-3789 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: jbossws-cxf-5.0.0.Beta2 > > > WSS4J 2.0 comes with streaming (StAX) WS-Security support: http://ws.apache.org/wss4j/streaming.html > We need to verify it's working with the JBossWS integration, test & run benchmarks and possibly turn it on by default. > See also: > http://santuario.apache.org/streaming-xml-security.html > http://coheigea.blogspot.ie/2014/04/apache-santuario-xml-security-for-jav... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3817) Avoid globally installing BouncyCastle

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3817?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3817: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Avoid globally installing BouncyCastle > -------------------------------------- > > Key: JBWS-3817 > URL: https://issues.jboss.org/browse/JBWS-3817 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0.0.Beta2 > > > This is about preventing Apache CXF / WSS4J from installing BouncyCastle globally and actually setting its security provider at message exchange level as described in https://issues.apache.org/jira/browse/CXF-5905 . -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues November 2014