[JBoss JIRA] (JBWS-4123) SAMLTokenPrincipal is not propagated to EJB
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4123?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4123:
----------------------------------
Fix Version/s: jbossws-cxf-5.2.3.Final
(was: jbossws-cxf-5.2.2.Final)
Priority: Major (was: Critical)
OK, so with the actual issue here being the ElytronSecurityDomainContextImpl not propagating the subject to the EJB layer (which is tracked by WFLY-10480), this jira is now only about providing a generic JBossWS CXF interceptor that does what the user is doing in his application (relying on JBossWS-SPI). As such, this jira is not critical anymore and can be moved to next release (I'd like to think about other possible usecases too before adding such an interceptor to JBossWS).
The actual fix in WFLY-10480 is already included in a PR and the jira is blocking for next WildFly release.
> SAMLTokenPrincipal is not propagated to EJB
> --------------------------------------------
>
> Key: JBWS-4123
> URL: https://issues.jboss.org/browse/JBWS-4123
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.2.1.Final
> Reporter: Viral Gohel
> Assignee: Jim Ma
> Fix For: jbossws-cxf-5.2.3.Final
>
> Attachments: redhat-saml-interceptor.zip, redhat.zip
>
>
> SAML Token Principal can be propagated to the EJB layer, which right now we are not seeing.
> Here are the results we see,
> 16:23:43,521 INFO [stdout] (default task-9) class org.apache.wss4j.common.principal.SAMLTokenPrincipalImpl
> 16:23:43,522 INFO [stdout] (default task-9) subjectName
> 16:23:58,617 INFO [stdout] (default task-9) class org.jboss.security.SimplePrincipal
> 16:24:15,751 INFO [stdout] (default task-9) anonymous
> CXF code isn't creating the Subject for the security context in a way that the EAP, or JEE containers, can understand. For UsernameToken type authentication this is done through org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor, but I'm unsure if this applies to SAML tokens.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4088:
----------------------------------
Fix Version/s: jbossws-cxf-5.2.3.Final
(was: jbossws-cxf-5.2.2.Final)
I'm moving the issue to 5.2.3 for creating a testcase verifying the scenario.
> Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
> ---------------------------------------------------------------------------------------------
>
> Key: JBWS-4088
> URL: https://issues.jboss.org/browse/JBWS-4088
> Project: JBoss Web Services
> Issue Type: Enhancement
> Reporter: david.boeren
> Priority: Minor
> Fix For: jbossws-cxf-5.2.3.Final
>
>
> I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following:
> protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>());
> and the getResponseContext() is implemented this way:
> public Map<String, Object> getResponseContext() {
> if (!responseContext.containsKey(Thread.currentThread())) {
> responseContext.put(Thread.currentThread(), new HashMap<String, Object>());
> }
> return responseContext.get(Thread.currentThread());
> }
> Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled).
> I would suggest to try explicitly cleaning up the response message context contents.
> The customer has successfully done this using this on their client side:
> dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter");
> Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-4088:
---------------------------------------
This is actually a known issue of Apache CXF, which is currently being dealt with. CXF 3.2.5 introduced a Client.getContexts() method that returns an autocloseable object that allows getting req/res context and cleans them up in try-with blocks: https://github.com/apache/cxf/commit/6abad1864187457984b0dff2622eafb4b5df... . The context clear method also removes the current thread association with the current context.
It should hence be a user responsibility to either explicitly call clear() on the response context or get the context thought the afore mentioned Contexts mechanism, all before returning the client to the pool.
> Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
> ---------------------------------------------------------------------------------------------
>
> Key: JBWS-4088
> URL: https://issues.jboss.org/browse/JBWS-4088
> Project: JBoss Web Services
> Issue Type: Enhancement
> Reporter: david.boeren
> Priority: Minor
> Fix For: jbossws-cxf-5.2.2.Final
>
>
> I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following:
> protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>());
> and the getResponseContext() is implemented this way:
> public Map<String, Object> getResponseContext() {
> if (!responseContext.containsKey(Thread.currentThread())) {
> responseContext.put(Thread.currentThread(), new HashMap<String, Object>());
> }
> return responseContext.get(Thread.currentThread());
> }
> Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled).
> I would suggest to try explicitly cleaning up the response message context contents.
> The customer has successfully done this using this on their client side:
> dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter");
> Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (JBWS-4132) Upgrade to ASM 6.2.1
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-4132:
-------------------------------------
Summary: Upgrade to ASM 6.2.1
Key: JBWS-4132
URL: https://issues.jboss.org/browse/JBWS-4132
Project: JBoss Web Services
Issue Type: Task
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-5.2.2.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (JBWS-4131) Cannot register web service, fails with NullPointerException in DelegateClassLoader
by Brad Maxwell (JIRA)
Brad Maxwell created JBWS-4131:
----------------------------------
Summary: Cannot register web service, fails with NullPointerException in DelegateClassLoader
Key: JBWS-4131
URL: https://issues.jboss.org/browse/JBWS-4131
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Reporter: Brad Maxwell
Assignee: R Searls
Fix For: jbossws-cxf-5.2.1.Final
While deploying a EAR application, which contains a WAR which is trying to register a web service, I get the follwing exception:
{code}
13:53:34,624 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/standalone/data/wsdl/dms-new-ear-services-0.0.8.1.ear/dms-new-war-0.0.7.1.war/BusinessWebServiceService.wsdl
13:53:34,658 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/jboss/ws/jaxws-client/main/jbossws-cxf-client-5.1.9.Final.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-tools-wsdlto-frontend-jaxws-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-services-ws-discovery-api-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,773 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "dms-new-war-0.0.7.1.war" of deployment "dms-new-ear-services-0.0.8.1.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory could not be instantiated: java.lang.NullPointerException
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:204)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232)
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120)
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2180)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:163)
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:85)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:217)
at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:160)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:129)
at org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.<init>(ProviderImpl.java:574)
at org.jboss.wsf.stack.cxf.client.ProviderImpl.createServiceDelegate(ProviderImpl.java:258)
at javax.xml.ws.Service.<init>(Service.java:57)
at com.tullettprebon.dms.tmmalternativeaddress.ws.TMMMarkitWireService.<init>(TMMMarkitWireService.java:60)
at com.tullettprebon.dms.webservices.ReferenceWebService.<init>(ReferenceWebService.java:232)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.jboss.wsf.stack.cxf.configuration.BusHolder.newInstance(BusHolder.java:322)
at org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:212)
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:165)
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
... 33 more
{code}
I wasted 3 days trying to find a solution thinking that the problem was in my dependencies with xerces or any other xml resolver.
Then I decided to checkout the code near the root cause:
{code}
Caused by: java.lang.NullPointerException
at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
... 33 more
{code}
and I think I have fixed a bug in {{jbossws-common-3.1.5}}.
I have downloaded the latest version of {{jbossws-common-master}} from github (with which the problem was still showing).
Then I fixed the class {{org/jboss/ws/common/utils/DelegateClassLoader.java}} changing this:
{code}
/** {@inheritDoc} */
@Override
public InputStream getResourceAsStream(final String name)
{
InputStream is = parent.getResourceAsStream(name);
return (is == null) ? delegate.getResourceAsStream(name) : is;
}
{code}
to this:
{code}
/** {@inheritDoc} */
@Override
public InputStream getResourceAsStream(final String name)
{
InputStream is = null;
if (parent != null)
{
is = parent.getResourceAsStream(name);
}
return (is == null) ? delegate.getResourceAsStream(name) : is;
}
{code}
and then built again the jbossws-common jar and replaced the (suspected) faulty one under the WildFly modules. With the new jar the webservice can be registered.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (JBWS-4102) Investigate warnings in build log
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-4102?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-4102:
--------------------------------
I refer you back to my comment on 25/Jun/18. I still stand with that opinion. If you want to
move that to a separate jira. I have not objection.
> Investigate warnings in build log
> ---------------------------------
>
> Key: JBWS-4102
> URL: https://issues.jboss.org/browse/JBWS-4102
> Project: JBoss Web Services
> Issue Type: Task
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.2.0.Final
> Reporter: Jan Blizňák
> Assignee: R Searls
> Priority: Minor
> Fix For: jbossws-cxf-5.2.2.Final
>
> Attachments: build.log
>
>
> Maven build process in current version outputs few warnings that should be investigated.
> Command used:
> {code:java}
> mvn -V -B clean install -Dnodeploy -Pwildfly1200,testsuite -Dserver.home=/tmp/wildfly/dist/target/wildfly-12.0.0.Beta2-SNAPSHOT
> {code}
> *case 1*
> {code:java}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ jbossws-cxf-client ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 17 source files to /tmp/jbossws-cxf/modules/client/target/test-classes
> [WARNING] The following options were not recognized by any processor: '[generatedTranslationFilesPath]'
> ....
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ jbossws-cxf-server ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 44 source files to /tmp/jbossws-cxf/modules/server/target/classes
> [WARNING] The following options were not recognized by any processor: '[generatedTranslationFilesPath]'
> ....
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ jbossws-cxf-server ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to /tmp/jbossws-cxf/modules/server/target/test-classes
> [WARNING] The following options were not recognized by any processor: '[generatedTranslationFilesPath]'
> {code}
> *case 2*
> {code:java}
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ jbossws-cxf-test-utils ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 9 source files to /tmp/jbossws-cxf/modules/test-utils/target/classes
> [WARNING] /tmp/jbossws-cxf/modules/test-utils/src/main/java/org/jboss/wsf/test/JBossWSTestHelper.java:[54,20] sun.net.util.IPAddressUtil is internal proprietary API and may be removed in a future release
> [WARNING] /tmp/jbossws-cxf/modules/test-utils/src/main/java/org/jboss/wsf/test/JBossWSTestHelper.java:[240,57] sun.net.util.IPAddressUtil is internal proprietary API and may be removed in a future release
> {code}
> *case 3*
> {code:java}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ jbossws-cxf-specific-tests ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 414 source files to /tmp/jbossws-cxf/modules/testsuite/cxf-tests/target/test-classes
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/samples/wsrm/store/Endpoint.java:[28,34] org.apache.cxf.annotations.Logging in org.apache.cxf.annotations has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws3648/PolicyAttachmentTestCase.java:[35,34] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[34,34] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[35,34] org.apache.cxf.interceptor.LoggingOutInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/LoggingFeatureEndpointImpl.java:[30,34] org.apache.cxf.annotations.Logging in org.apache.cxf.annotations has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/MessageLoggingTestCase.java:[35,34] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/asyncclient/AsyncEnabledInfoInterceptor.java:[27,34] org.apache.cxf.interceptor.AbstractLoggingInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/CustomInInterceptor.java:[6,34] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/samples/wsrm/store/Endpoint.java:[36,2] org.apache.cxf.annotations.Logging in org.apache.cxf.annotations has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws3648/PolicyAttachmentTestCase.java:[104,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws3648/PolicyAttachmentTestCase.java:[132,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[108,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[109,43] org.apache.cxf.interceptor.LoggingOutInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[138,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[139,43] org.apache.cxf.interceptor.LoggingOutInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[188,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/fastinfoset/FastInfosetTestCase.java:[189,43] org.apache.cxf.interceptor.LoggingOutInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/LoggingFeatureEndpointImpl.java:[35,2] org.apache.cxf.annotations.Logging in org.apache.cxf.annotations has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/MessageLoggingTestCase.java:[111,10] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/MessageLoggingTestCase.java:[111,58] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/asyncclient/AsyncEnabledInfoInterceptor.java:[33,50] org.apache.cxf.interceptor.AbstractLoggingInterceptor in org.apache.cxf.interceptor has been deprecated
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws4046/JBWS4046TestCase.java:[82,64] non-varargs call of varargs method with inexact argument type for last parameter;
> cast to javax.xml.ws.WebServiceFeature for a varargs call
> cast to javax.xml.ws.WebServiceFeature[] for a non-varargs call and to suppress this warning
> [WARNING] /tmp/jbossws-cxf/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/logging/CustomInInterceptor.java:[9,42] org.apache.cxf.interceptor.LoggingInInterceptor in org.apache.cxf.interceptor has been deprecated
> {code}
> *case 4*
> {code:java}
> [INFO] --- maven-surefire-plugin:2.20.1:test (forked-integration-tests) @ jbossws-cxf-specific-tests ---
> [WARNING] The parameter forkMode is deprecated since version 2.14. Use forkCount and reuseForks instead.
> {code}
> *case 5*
> {code:java}
> [INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ jbossws-cxf-specific-tests ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar: /tmp/jbossws-cxf/modules/testsuite/cxf-tests/target/jbossws-cxf-specific-tests-5.2.1-SNAPSHOT.jar
> ...
> [INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ jbossws-cxf-shared-tests ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar: /tmp/jbossws-cxf/modules/testsuite/shared-tests/target/jbossws-cxf-shared-tests-5.2.1-SNAPSHOT.jar
> {code}
> *case 6* - JDK9+ only
> {code}
> [WARNING] /home/travis/build/jbossws/jbossws-cxf/modules/server/src/main/java/org/jboss/wsf/stack/cxf/security/authentication/SubjectCreatingInterceptor.java:[25,25] java.security.acl.Group in java.security.acl has been deprecated and marked for removal
> [WARNING] /home/travis/build/jbossws/jbossws-cxf/modules/server/src/main/java/org/jboss/wsf/stack/cxf/security/authentication/SubjectCreatingPolicyInterceptor.java:[25,25] java.security.acl.Group in java.security.acl has been deprecated and marked for removal
> [WARNING] /home/travis/build/jbossws/jbossws-cxf/modules/server/src/main/java/org/jboss/wsf/stack/cxf/security/authentication/SubjectCreatingInterceptor.java:[25,25] java.security.acl.Group in java.security.acl has been deprecated and marked for removal
> [WARNING] /home/travis/build/jbossws/jbossws-cxf/modules/server/src/main/java/org/jboss/wsf/stack/cxf/security/authentication/SubjectCreatingPolicyInterceptor.java:[25,25] java.security.acl.Group in java.security.acl has been deprecated and marked for removal
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months