August 2016 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-4014) Clean-up test deployment dependencies

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4014: ---------------------------------------- Summary: Clean-up test deployment dependencies Key: JBWS-4014 URL: https://issues.jboss.org/browse/JBWS-4014 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf Reporter: Bartosz Baranowski Assignee: Alessio Soldano Fix For: jbossws-cxf-5.1.4.Final In the cxf-specific testsuite, we have some test deployments specifying dependencies to module org.apache.cxf.impl, which is private and should hence not be used unless there's a real reason for doing that. With the upgrade to Apache CXF 3 series, the org.apache.cxf module now contains cxf-rt-core.jar instead of cxf-api.jar, so the public org.apache.cxf module can be used instead of the org.apache.cxf.impl one in some scenarios (where cxf core classes usage where the reason for setting the dependency). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4013) CXFHandlerResolverImpl not threadsafe

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4013: ---------------------------------------- Summary: CXFHandlerResolverImpl not threadsafe Key: JBWS-4013 URL: https://issues.jboss.org/browse/JBWS-4013 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf Affects Versions: jbossws-cxf-5.0.0.Final Reporter: Bartosz Baranowski Assignee: Alessio Soldano Fix For: jbossws-cxf-5.1.4.Final When the concurrency of handler-chain parsing increases , the following error shows up in the logs: Caused by: org.xml.sax.SAXException: FWK005 parse may not be called while parsing. at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:260) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at org.jboss.wsf.stack.cxf.client.serviceref.CXFHandlerResolverImpl.createHandlerChain(CXFHandlerResolverImpl.java:161) ... 132 more One case where I have seen this is when an EJB/MDB uses @WebServiceRef and @HandlerChain to get a reference to a webservice. When multiple instances of the EJB/MDB are created at the same time to handle a lot of messages this happens. It is the @HandlerChain that triggers the xml parsing and gives the error. The Xerces DocumentBuilder is not threadsafe and thus requires code to synchronize it correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4012) Improve isolation between integration code and user code

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4012: ---------------------------------------- Summary: Improve isolation between integration code and user code Key: JBWS-4012 URL: https://issues.jboss.org/browse/JBWS-4012 Project: JBoss Web Services Issue Type: Enhancement Components: jbossws-cxf, jbossws-integration Reporter: Bartosz Baranowski Assignee: Alessio Soldano Fix For: jbossws-cxf-5.1.4.Final It is currently possible for user code to "see" some JBossWS integration classes & dependencies during the execution of static blocks of user handlers declared through webservices.xml descriptors or management model. That happens because such code is executed at deployment time when the JBossWS integration classloader is set as thread context classloader. We should prevent this from happening. This is not a problem, of course, at runtime, when the deployment is completely isolated from the integration classloader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4011) Loosen BusTestCase::testReuse() checks

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4011: ---------------------------------------- Summary: Loosen BusTestCase::testReuse() checks Key: JBWS-4011 URL: https://issues.jboss.org/browse/JBWS-4011 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf Reporter: Bartosz Baranowski Assignee: Alessio Soldano Fix For: jbossws-cxf-5.1.4.Final The org.jboss.test.ws.jaxws.cxf.bus.BusTestCase::testReuse() test is too strict and basically assumes that GC is not performed during its run. As a consequence of CXF-6632 having been fixed, we need to loosen the test checks to only assert what we are interested in and is going to be always reproducible. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4010) Ignore IDEA files

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4010: ---------------------------------------- Summary: Ignore IDEA files Key: JBWS-4010 URL: https://issues.jboss.org/browse/JBWS-4010 Project: JBoss Web Services Issue Type: Task Reporter: Bartosz Baranowski Assignee: Rostislav Svoboda Fix For: jbossws-cxf-5.1.4.Final Ignore IDEA files using .gitignore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4009: ---------------------------------------- Summary: Make removing console log handler during prepare phase of testsuite optional Key: JBWS-4009 URL: https://issues.jboss.org/browse/JBWS-4009 Project: JBoss Web Services Issue Type: Enhancement Components: jbossws-cxf Affects Versions: jbossws-cxf-5.1.3.Final Reporter: Bartosz Baranowski 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, 9 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4008: ---------------------------------------- Summary: Coverity reports possible need to use doPrivileged block for MapToBeanConverter Key: JBWS-4008 URL: https://issues.jboss.org/browse/JBWS-4008 Project: JBoss Web Services Issue Type: Bug Reporter: Bartosz Baranowski 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, 9 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4007: ---------------------------------------- Summary: Add support for cxf-rt-features-clustering in jbossws-cxf Key: JBWS-4007 URL: https://issues.jboss.org/browse/JBWS-4007 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf Reporter: Bartosz Baranowski 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, 9 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4006: ---------------------------------------- Summary: wsdl diretory is not cleaned on application deploy/undeploy thereby leaving an empty folder under "/wsdl/data" directory Key: JBWS-4006 URL: https://issues.jboss.org/browse/JBWS-4006 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf Affects Versions: jbossws-cxf-4.3, jbossws-cxf-4.3.2 Reporter: Bartosz Baranowski Assignee: Jim Ma Fix For: jbossws-cxf-5.1.5.Final 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, 9 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBWS-4005: ---------------------------------------- Summary: Prevent Apache CXF from using ASM from user deployments Key: JBWS-4005 URL: https://issues.jboss.org/browse/JBWS-4005 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf, jbossws-integration Reporter: Bartosz Baranowski 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, 9 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 August 2016