[JBoss JIRA] Created: (JBWS-2521) Refactor / rewrite ServiceObjectFactory
by Alessio Soldano (JIRA)
Refactor / rewrite ServiceObjectFactory
---------------------------------------
Key: JBWS-2521
URL: https://jira.jboss.org/jira/browse/JBWS-2521
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Fix For: jbossws-cxf-3.1.1
The jbossws-cxf ServiceObjectFactory needs to be cleaned:
- Bus retrieval: this is currently performed through reflection on the Service class and following cast to cxf ServiceImpl; leveraging the BusFactory should be enough to get the default bus that is used by the cxf ProviderImpl for every Service creation
- ServiceRef stub properties setup: this is currently performed through reflection on Service class to get the ServiceDelegate and then chaning the ServiceDelegate instance at runtime with a custom onesetting the properties. Instead of doing this hack, we should evaluate leveraging the CXF configuration for runtime constructed objects (http://cwiki.apache.org/CXF20DOC/configuration-of-runtime-constructed-obj...). IOW cxf ServiceImpl looks for a bean named portName.toString() + ".jaxws-client.proxyFactory" to configure the JaxWsProxyFactoryBean used to build the port and that factory bean allows for setting the stub properties. We might be able to generate on the fly and supply a bean configuration to the cxf bus for having our stub properties automatically configured by the already existing cxf configuration system.
- perhaps even the handler chain configuration can be achieved in a way similar to the described in the previous point.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2346) Issue with SAAJ API: SOAPBody.getElementsByTagNameNS() appears non-recursive
by David Boeren (JIRA)
Issue with SAAJ API: SOAPBody.getElementsByTagNameNS() appears non-recursive
----------------------------------------------------------------------------
Key: JBWS-2346
URL: https://jira.jboss.org/jira/browse/JBWS-2346
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.3
Reporter: David Boeren
We are trying to migrate our application into JBOSS 4.3EAP, perviously my webservice application was using Sun's saaj api. During the migration, we have been decided to use JBoss SAAJ api and we are seeing some weird problem with an API in SOAPBody class.
Here is the sample code:
NodeList list = soapMessage.getSOAPBody().getElementsByTagNameNS("urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0", "AdhocQueryResponse");
System.out.println(list.getLength());
list = soapMessage.getSOAPBody().getElementsByTagNameNS("urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0", "ExtrinsicObject");
System.out.println(list.getLength());
The first call to getElementsByTagNameNS() was returning the element list, but the subsequent call was returning an empty nodelist. I am attaching a sample java project created to reproduce the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2527) BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
by Alessio Soldano (JIRA)
BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
----------------------------------------------------------------------------------------------------------------
Key: JBWS-2527
URL: https://jira.jboss.org/jira/browse/JBWS-2527
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Fix For: jbossws-cxf-3.1.0
02-11-2009 11:10:32: SVR-ERROR: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:121)
at org.springframework.context.support.AbstractApplicationContext.containsBean(AbstractApplicationContext.java:765)
at org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:118)
at org.apache.cxf.jaxws.ServiceImpl.configureObject(ServiceImpl.java:513)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:429)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:292)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:287)
at org.jboss.wsf.stack.cxf.client.ServiceRefStubPropertyServiceDelegate.getPort(ServiceRefStubPropertyServiceDelegate.java:172)
at javax.xml.ws.Service.getPort(Service.java:44)
at com.sun.ts.tests.jaxws.api.javax_xml_ws.Endpoint.Client.getPortJavaEE(Client.java:111)
at com.sun.ts.tests.jaxws.api.javax_xml_ws.Endpoint.Client.setup(Client.java:189)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2284) Using WSConsume on JBOSS 4.2.3.GA and JDK 1.6.0_07 leads to java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
by Hemant Satam (JIRA)
Using WSConsume on JBOSS 4.2.3.GA and JDK 1.6.0_07 leads to java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
-----------------------------------------------------------------------------------------------------------------------------------
Key: JBWS-2284
URL: https://jira.jboss.org/jira/browse/JBWS-2284
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBOSS 4.2.3.GA
JDK 1.6.0_07
Windows
Reporter: Hemant Satam
I have all the required files in jboss-4.2.3.GA\lib\endorsed. The classpath also ensures that jboss libraries are before jdk1.6 lib file. However on access of wsconsume the error produced is;
JBossWS-Native stack deployed
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
at org.jboss.ws.tools.jaxws.impl.SunRIConsumerFactoryImpl.createConsumer(SunRIConsumerFact
oryImpl.java:36)
at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(WSContractConsumer.java:73)
at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(WSContractConsumer.java:56)
at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:195)
at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:81)
Caused by: java.lang.ClassNotFoundException: com.sun.tools.ws.wscompile.WsimportTool
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 5 more
Is this a bug or something wrong that I am doing?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBWS-2413) WSDLPublisher fails when trying to publish include schemas that contain relative paths
by Alvaro (JIRA)
WSDLPublisher fails when trying to publish include schemas that contain relative paths
--------------------------------------------------------------------------------------
Key: JBWS-2413
URL: https://jira.jboss.org/jira/browse/JBWS-2413
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.4
Environment: OS: Windows Vista Business SP1
Java: 1.5 build 16
JBossWS: 3.0.4
JBossAS: 4.2.3
Reporter: Alvaro
When trying to deploy an EJB3 with a WebService endpoint and the property wsdlLocation set, the WSDLPublisher fails to publish schema imports if they contain relative paths.
For example, in the method "publishSchemaImports", if the variable "resourcePath" used in the statement "URL resourceURL = dep.getMetaDataFileURL(resourcePath);" resolves to "META-INF/wsdl/schemas/NE2006/multicacheschemas/../coreschemas/infrastructureRoot.xsd", there will be a java.io.FileNotFoundExeception is thrown:
org.jboss.ws.WSException: Cannot publish wsdl to: G:\Servidores\jboss-4.2.3.GA\server\default\data\wsdl\hl7-service-patient-administration-0.0.1-SNAPSHOT.jar\PRPA_AR101001UV01
.wsdl
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:149)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.start(PublishContractDeploymentAspect.java:51)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.start(DeploymentAspectManagerImpl.java:144)
at org.jboss.wsf.container.jboss42.LazyAssemblyWSFRuntime.start(LazyAssemblyWSFRuntime.java:66)
at org.jboss.wsf.container.jboss42.AbstractDeployerHookEJB.deploy(AbstractDeployerHookEJB.java:50)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:88)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy34.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Cannot get URL for: META-INF/wsdl/schemas/NE2006/multicacheschemas/../coreschemas/infrastructureRoot.xsd
at org.jboss.wsf.common.URLLoaderAdapter.findChild(URLLoaderAdapter.java:103)
at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:97)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:274)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:297)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:136)
... 79 more
If we replace the "resourcePath" with the canonical form, this error disappears.
As a solution, I've replaced the following code:
private void publishSchemaImports(URL parentURL, Element element, List<String> published) throws Exception
{
....
while (it.hasNext())
{
....
URL xsdURL = new URL(baseURI.substring(0, baseURI.lastIndexOf("/") + 1) + schemaLocation);
File targetFile = new File(xsdURL.getPath());
targetFile.getParentFile().mkdirs();
String deploymentName = dep.getCanonicalName();
// get the resource path including the separator
int index = baseURI.indexOf(deploymentName) + 1;
String resourcePath = baseURI.substring(index + deploymentName.length());
//check for sub-directories
resourcePath = resourcePath.substring(0, resourcePath.lastIndexOf("/") + 1);
resourcePath = expLocation + resourcePath + schemaLocation;
while (resourcePath.indexOf("//") != -1)
{
resourcePath = resourcePath.replace("//", "/");
}
URL resourceURL = dep.getMetaDataFileURL(resourcePath);
.....
}
....
}
with this one:
private void publishSchemaImports(URL parentURL, Element element, List<String> published) throws Exception
{
....
while (it.hasNext())
{
....
URL xsdURL = new URL(baseURI.substring(0, baseURI.lastIndexOf("/") + 1) + schemaLocation);
File targetFile = new File(xsdURL.getPath());
targetFile.getParentFile().mkdirs();
String deploymentName = dep.getCanonicalName();
// get the resource path including the separator
int index = baseURI.indexOf(deploymentName) + 1;
String resourcePath = baseURI.substring(index + deploymentName.length());
//check for sub-directories
resourcePath = resourcePath.substring(0, resourcePath.lastIndexOf("/") + 1);
resourcePath = expLocation + resourcePath + schemaLocation;
URI resourceURI = new URI(resourcePath);
URI resourceURI2 = resourceURI.resolve("");
resourcePath = resourceURI2.toString()+resourceURI2.relativize(resourceURI).toString();
URL resourceURL = dep.getMetaDataFileURL(resourcePath);
...
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months