July 2016 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3992) wsdl diretory is not cleaned on application deploy/undeploy thereby leaving an empty folder under "/wsdl/data" directory

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3992?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3992: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > wsdl diretory is not cleaned on application deploy/undeploy thereby leaving an empty folder under "/wsdl/data" directory > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBWS-3992 > URL: https://issues.jboss.org/browse/JBWS-3992 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3, jbossws-cxf-4.3.2 > Reporter: Saisha Naik > Assignee: Jim Ma > Fix For: jbossws-cxf-5.1.5.Final > > Attachments: TestEar.ear, WsdlXsdExample.war > > > Tested the issue in two different scenarios listed below : > *Scenario 1:* > When a web-service test EAR(having an EJB JAR/WAR inside it) is deployed in JBoss EAP, it creates a wsdl folder inside the data directory with the name of the deployed application. Suppose, there is an application TestEar.ear having an EJB web-service jar(MyEjb1.jar) in it. When this application is deployed in JBoss EAP, its wsdl will be published at `/data/wsdl/TestEar.ear/MyEjb1.jar/HelloService.wsdl`. > {code:java} > wsdl > └── TestEar.ear > └── MyEjb1.jar > └── HelloWebServiceBeanService.wsdl > {code} > When the server is stopped or the application is undeployed, the wsdl content is removed from the location, however the folder is never deleted, thereby leaving an empty folder in the "/data/wsdl" directory: > {code:java} > wsdl > └── TestEar.ear > {code} > This is not the scenario when a war/jar application is deployed, in which case the content is completely removed along with the folder. > *Scenario 2:* > In case of a war, the wsdl folder inside the application has the below structure : > {code:java} > [sanaik@sanaik WEB-INF]$ tree > . > ├── classes > ..... > └── wsdl > ├── base > │ └── as > │ └── ServerInfoService_schema1.xsd > ├── ServerInfoService.wsdl > └── ServerInfoService.wsdl~ > ... > {code} > Deploying the application creates the below structure under "/data/wsdl" directory : > {code:java} > [sanaik@sanaik WsdlXsdExample.war]$ tree > . > ├── base > │ └── as > │ └── ServerInfoService_schema1.xsd > └── ServerInfoService.wsdl > {code} > On disabling the application via admin console, "ServerInfoService.wsdl" is cleared, however the below contents still remains : > {code:java} > [sanaik@sanaik WsdlXsdExample.war]$ tree > . > └── base > └── as > └── ServerInfoService_schema1.xsd > {code} > And JBoss does gives the below WARN message : > {code:java} > [Server:server-one] 11:53:30,835 WARN [org.jboss.ws.cxf.deployment] (MSC service thread 1-4) JBWS024097: Could not delete wsdl file /NotBackedUp/NEW/Cases/CASE-01604047/jboss-eap-6.4/domain/servers/server-one/data/wsdl/WsdlXsdExample.war/base > [Server:server-one] 11:53:30,836 WARN [org.jboss.ws.cxf.deployment] (MSC service thread 1-4) JBWS024100: Could not delete wsdl directory /NotBackedUp/NEW/Cases/CASE-01604047/jboss-eap-6.4/domain/servers/server-one/data/wsdl/WsdlXsdExample.war > {code} > This is only the case if any xsd is placed inside a folder under the "/wsdl" directory and referenced in the wsdl. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3980) Make removing console log handler during prepare phase of testsuite optional

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3980?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3980: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > Make removing console log handler during prepare phase of testsuite optional > ---------------------------------------------------------------------------- > > Key: JBWS-3980 > URL: https://issues.jboss.org/browse/JBWS-3980 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.3.Final > Reporter: Jan Blizňák > Assignee: Jan Blizňák > Priority: Optional > Fix For: jbossws-cxf-5.1.5.Final > > > Current groovy scripts for preparing various server configuration for tests remove console handler and set logging only to file. > This might be convenient for passing testsuite and/or for local run. For CI job or for debugging purposes it is often useful to have whole output (server log and test log) in one place to have context. So making the removal optional seems better to me. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3984) Add support for cxf-rt-features-clustering in jbossws-cxf

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3984?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3984: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > Add support for cxf-rt-features-clustering in jbossws-cxf > --------------------------------------------------------- > > Key: JBWS-3984 > URL: https://issues.jboss.org/browse/JBWS-3984 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Viral Gohel > Assignee: Jim Ma > Fix For: jbossws-cxf-5.1.5.Final > > > We need to have the cxf failover feature, http://cxf.apache.org/docs/failoverfeature.html, be made available in jbossws-cxf. > We don't ship with this feature yet and the feature actually allows us to how to implement auto fail over and fail back of CXF SOAP calls from a primary to a secondary URL. > Here's is an example hosted for this, https://github.com/jaceko/cxf-circuit-switcher. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3953) Coverity reports possible need to use doPrivileged block for MapToBeanConverter

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3953?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3953: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > Coverity reports possible need to use doPrivileged block for MapToBeanConverter > ------------------------------------------------------------------------------- > > Key: JBWS-3953 > URL: https://issues.jboss.org/browse/JBWS-3953 > Project: JBoss Web Services > Issue Type: Bug > Reporter: Rostislav Svoboda > Assignee: Jim Ma > Fix For: jbossws-cxf-5.1.5.Final > > > Coverity reports possible need to use doPrivileged block for org.jboss.wsf.stack.cxf.client.configuration.MapToBeanConverter > Please investigate if the doPrivileged block is needed or not > {code:java} > 99 protected Object newInstance(String className) throws Exception { > CID 17469 (#1 of 1): DP: Use doPrivileged (FB.DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED)1. defect: > org.jboss.wsf.stack.cxf.client.configuration.MapToBeanConverter.newInstance(String) > creates a org.jboss.ws.common.utils.DelegateClassLoader classloader, which should be performed within a doPrivileged block. > 100 ClassLoader loader = new DelegateClassLoader(ClassLoaderProvider.getDefaultProvider() > 101 .getServerIntegrationClassLoader(), SecurityActions.getContextClassLoader()); > 102 Class<?> clazz = SecurityActions.loadClass(loader, className); > 103 return clazz.newInstance(); > 104 } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3997) jbossws-common - usage of Exception.printStackTrace() instead of logging feature

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3997?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3997: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > jbossws-common - usage of Exception.printStackTrace() instead of logging feature > -------------------------------------------------------------------------------- > > Key: JBWS-3997 > URL: https://issues.jboss.org/browse/JBWS-3997 > Project: JBoss Web Services > Issue Type: Enhancement > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Priority: Minor > Fix For: jbossws-cxf-5.1.5.Final > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > 4x https://github.com/jbossws/jbossws-common/blob/master/src/main/java/org/j... > 4x https://github.com/jbossws/jbossws-common/blob/master/src/main/java/org/j... > 1x https://github.com/jbossws/jbossws-common-tools/blob/master/src/main/java... > 1x https://github.com/jbossws/jbossws-common-tools/blob/master/src/main/java... > In both there are checks on Log4JUtil.isLog4jConfigurationAvailable() in previous part of the code -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3995) Prevent Apache CXF from using ASM from user deployments

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3995?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3995: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.5.Final (was: jbossws-cxf-5.2.0.Final) > Prevent Apache CXF from using ASM from user deployments > ------------------------------------------------------- > > Key: JBWS-3995 > URL: https://issues.jboss.org/browse/JBWS-3995 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.1.5.Final > > > Apache CXF loads ASM using the thread context classloader. From a pure CXF point of view, that's not wrong, so we'd better set an explicit dependency to the ASM included in the container during deployments processing, to avoid ASM shipped in the user applications from being used (which is potentially troublesome in case of undeployment/deployment sequences). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3999) Testsuite failing on WFLY master because of duplicated https listener

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3999: ------------------------------------- Summary: Testsuite failing on WFLY master because of duplicated https listener Key: JBWS-3999 URL: https://issues.jboss.org/browse/JBWS-3999 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf, productization Reporter: Alessio Soldano Assignee: Alessio Soldano As a consequence of https://github.com/wildfly/wildfly/commit/8f66017f291c6e11bf1c4c9eb8a860d... , the jbossws-cxf testsuite is failing against wildfly master, because now it comes with a https listener configured by default. The jbossws-cxf test scripts needs to remove it before adding the jbossws-cxf test one in the container test configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 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 July 2016