[JBoss JIRA] Created: (JBWS-1943) NPE when com.sun.management.jmxremote.port is changed, preventing correct publication of WSDL
by Chris Laprun (JIRA)
NPE when com.sun.management.jmxremote.port is changed, preventing correct publication of WSDL
---------------------------------------------------------------------------------------------
Key: JBWS-1943
URL: http://jira.jboss.com/jira/browse/JBWS-1943
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-2.0.1.SP2
Reporter: Chris Laprun
Changing the com.sun.management.jmxremote.port value results in WSDLFilePublisher not being to publish the WSDL file:
java.lang.NullPointerException
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.getPublishLocation(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:103)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90)
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 $Proxy158.start(Unknown Source)
Looks like the root of the error is an issue with AbstractServerConfig.getConnectorPort failing from called from getWebServicePort. A warning is issued on the console: "Unable to calculate 'WebServicePort', using default '8080'".
--
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
16 years, 3 months
[JBoss JIRA] Created: (JBWS-1945) Empty webServiceHost to use requests hostname in <soap:address> gives "Null value metadata"
by Marius Kotsbak (JIRA)
Empty webServiceHost to use requests hostname in <soap:address> gives "Null value metadata"
--------------------------------------------------------------------------------------------
Key: JBWS-1945
URL: http://jira.jboss.com/jira/browse/JBWS-1945
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-2.0.2
Environment: JBoss 4.0.5
Reporter: Marius Kotsbak
In
jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml, if you specyfy one of
<property name="webServiceHost"></property>
<property name="webServiceHost"> </property>
<property name="webServiceHost"><![CDATA[ ]]></property>
as I out of the documentation and source code assume that you should do to use requests hostname in the soap address gives:
*** DEPLOYMENTS IN ERROR:
WSServerConfig -> java.lang.IllegalArgumentException: Null value metadata
)
at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
at org.jboss.kernel.deployment.jboss.JBossBeanDeployment.startService(JBossBeanDeployment.java:86)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor135.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.GeneratedMethodAccessor15.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 $Proxy16.start(Unknown Source)
at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor25.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 $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: java.lang.IllegalStateException: Incompletely deployed:
*** DEPLOYMENTS IN ERROR:
WSServerConfig -> java.lang.IllegalArgumentException: Null value metadata
--
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
16 years, 3 months
[JBoss JIRA] Created: (JBWS-1924) Verify installation script for jboss-4.2.1.GA
by Alessio Soldano (JIRA)
Verify installation script for jboss-4.2.1.GA
---------------------------------------------
Key: JBWS-1924
URL: http://jira.jboss.com/jira/browse/JBWS-1924
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-2.0.2
Reporter: Alessio Soldano
Installing JBossWS 2.0.2.GA on JBoss 4.2.1.GA without having a JBossWS 2.0.1.GA installed result in a broken installation due to jbossws-jboss42.jar/jbossws-jboss421.jar missing in client libs.
The 2.0.2 installation script does not remove that lib, thus installing 2.0.1 and then 2.0.2 seems to be a workaround. This has to be verified as well as the 2.0.2 installation script / hudson conf for the 4.2.1.
--
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
16 years, 3 months
[JBoss JIRA] Created: (JBWS-1816) JAXWS SOAPFault inheritance
by Thomas Diesler (JIRA)
JAXWS SOAPFault inheritance
---------------------------
Key: JBWS-1816
URL: http://jira.jboss.com/jira/browse/JBWS-1816
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: jbossws-2.0.2
I'm using wsprovide (an ant task in maven on windows) to generate my wsdl and then wsconsume to generate my client classes. My web service method throws multiple exceptions, some of which extend from each other.
Unfortunately that inheritance relationship is lost in the generated wsdl (no < extension base...) and of course in the client classes.
Is there some way to get the wsprovide task to do what I'm asking for? Maybe with an annotation or something specific passed in when I call the task?
Thanks in advance.
BTW - there are multiple JIRA items (like: http://jira.jboss.com/jira/browse/JBWS-251) that refer to this issue issue. However it doesn't appear that it ever valid or addressed. So I'm wondering if there's something basic that I should be doing? Like digging into the documentation on javaToWSDL which I believe is being used by wsprovide.
--
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
16 years, 3 months
[JBoss JIRA] Commented: (JBWS-1178) Multiple virtual host and soap:address problem
by Marius Kotsbak (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1178?page=comments#action_12393615 ]
Marius Kotsbak commented on JBWS-1178:
--------------------------------------
Found source in:
http://anonsvn.jboss.org/repos/jbossws/legacy/tags/jbossws-1.0.3.SP1 (SP1 version in jboss 4.0.5).
> Multiple virtual host and soap:address problem
> ----------------------------------------------
>
> Key: JBWS-1178
> URL: http://jira.jboss.com/jira/browse/JBWS-1178
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jbossws-jaxws
> Affects Versions: jbossws-1.0.3
> Environment: jboss 4.0.4 jbossws 1.03
> Reporter: Stefano Maestri
> Assigned To: Thomas Diesler
> Fix For: jbossws-1.0.4
>
> Attachments: jbws103.patch
>
>
> The WSDL, that is a required deployment artifact for an endpoint, has a soap:address element which points to the location of the endpoint. JBoss supports rewriting of that SOAP address.
> When a server answers to different virtual addresses, the location of the endpoint (soap:address) declared in the wsdl and obtained from the contextServlet could be either the address setted on the wsdl at deploy time or the address setted in properties of the file jbossws.beans/META-INF/jboss-beans.xml (webServiceHost, webServicePort, alwaysModifySOAPAddress).
> Both addresses are staticaly mapped (in the wsdl or on the server configuration file) and this is the problem in our environment (but would be a problem also on more trivial environment with one multiheaded machine). Note that this issue concerns the wsdl generation phase only; of course webservice calls work perfectly with all virtual addresses. In fact the problem is present also on the ContextServlet (is the servlet called when you ask for the list of deployed services), but it's a minor trouble.
> Our patch adds a configuration parameter in jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml named rewriteSOAPAddressWithCalledHost (true/false). If this parameter is set to true soap:address is rewrited using the host and port used by the client to get the wsdl, and also the ContextServlet does the same. Of course it solves the problem because soap:address and url in ContextServlet depend on the Virtual host used while asking them.
> Without this patch, the only solution for us was to provide our customers with personalized static wsdl having soap:address modified to match the correct virtual address. Of course it was time wasting and made change management very very hard.
> For a complete description of the problem in a real word environment refer to my blog: http://www.javalinux.it/blogs/index.php?title=multiple_virtual_host_and_s...
--
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
16 years, 3 months