[JBoss JIRA] Created: (JBWS-2203) Implement standard message context properties
by Thomas Diesler (JIRA)
Implement standard message context properties
---------------------------------------------
Key: JBWS-2203
URL: http://jira.jboss.com/jira/browse/JBWS-2203
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-native
Reporter: Thomas Diesler
Assigned To: Thomas Diesler
Fix For: jbossws-native-3.0.2
Implement properties
public static final String WSDL_DESCRIPTION = "javax.xml.ws.wsdl.description";
public static final String WSDL_SERVICE = "javax.xml.ws.wsdl.service";
public static final String WSDL_PORT = "javax.xml.ws.wsdl.port";
public static final String WSDL_INTERFACE = "javax.xml.ws.wsdl.interface";
public static final String WSDL_OPERATION = "javax.xml.ws.wsdl.operation";
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBWS-2382) Fix JBossWS deployers processing
by Richard Opalka (JIRA)
Fix JBossWS deployers processing
--------------------------------
Key: JBWS-2382
URL: https://jira.jboss.org/jira/browse/JBWS-2382
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native
Affects Versions: jbossws-cxf-3.0.4, jbossws-metro-3.0.4, jbossws-native-3.0.4, jbossws-cxf-3.0.3
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-3.0.5, jbossws-metro-3.0.5, jbossws-cxf-3.0.5
In general all your processing in the deployers should just be based on metadata
available to deployers or configuration on the deployers.
You shouldn't be looking at any services.
e.g. suppose the war had a dependency on an ejb from some other application
then its not going to be started until that ejb exists regardless of when jbossweb.sar
gets started.
--
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-2370) Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap
by Richard Opalka (JIRA)
Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap
------------------------------------------------------------------------------------------------------------
Key: JBWS-2370
URL: https://jira.jboss.org/jira/browse/JBWS-2370
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native
Affects Versions: jbossws-cxf-3.0.4, jbossws-metro-3.0.4, jbossws-native-3.0.4
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-3.0.5, jbossws-metro-3.0.5, jbossws-cxf-3.0.5
During deployment of the endpoints declared in my wars a call is made to AbstractServerConfig.getConnectorPort(). This fetches the WS Server MBean and tries to lookup objects of type "jboss.web:type=Connector,*". At the point where the lookup fails the jboss.web MBean has only one entry for the WebServer.
In the run that I managed to debug the type=Connector entries were added at a later point. So, some of the subsequent calls to getConnectorPort() succeeded and also the AS bootstrap did not hang. I was unable to debug a case where the bootstrap did hang.
--
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-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, 10 months