[JBoss JIRA] Created: (JBWS-1800) Trying to monitor the JVM using -Dcom.sun.management.jmxremote prevents the jbossws 2.0.1 from coming up
by Raju Koganty (JIRA)
Trying to monitor the JVM using -Dcom.sun.management.jmxremote prevents the jbossws 2.0.1 from coming up
--------------------------------------------------------------------------------------------------------
Key: JBWS-1800
URL: http://jira.jboss.com/jira/browse/JBWS-1800
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-2.0.1
Environment: JBossWS 2.0.1 on JBoss 4.0.5 with JDK 1.6
Reporter: Raju Koganty
Having -Dcom.sun.management.jmxremote in the startup args to monitor the JVM causes this exception during startup and jbossws 2.0.1 doesn't come up :
And here is the exception :
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.jboss40.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss40.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 $Proxy29.start(Unknown Source)
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.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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: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:597)
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.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:302)
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:597)
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:490)
at java.lang.Thread.run(Thread.java:619)
--
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
15 years
[JBoss JIRA] Created: (JBWS-2717) Send XML declarations with WSDL
by Lukas Petrovicky (JIRA)
Send XML declarations with WSDL
-------------------------------
Key: JBWS-2717
URL: https://jira.jboss.org/jira/browse/JBWS-2717
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jbossws-2.0.1.SP2
Reporter: Lukas Petrovicky
Priority: Minor
When testing JBoss SOA-P for WS-I compliance, we found an interesting bug. Contrary to what XML says, the WS-I Test Tools consider the WSDL to be in UTF-8 if and only if it has an XML declaration that states so.
This technically isn't an issue on our part, as the WSDL clearly is UTF-8 and is well-formed, but the only way the WS-I Test Tools will ever know is when we actually include the XML declaration at the beginning of WSDL document. So this is a feature request asking for just that.
Specifying the content type in a HTTP header doesn't work as WS-I Test Tools only look at the declaration (and the lack thereof).
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBWS-2674) Implement javax.xml.ws.Endpoint
by Richard Opalka (JIRA)
Implement javax.xml.ws.Endpoint
-------------------------------
Key: JBWS-2674
URL: https://jira.jboss.org/jira/browse/JBWS-2674
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-3.2.1
We do have implementation of this Endpoint API, but it is fundamentally wrong.
I'd say the Endpoint as specified in the JAX-WS spec was
misunderstood by the author of current Endpoint implementation.
The Endpoint static methods are intended to be used
on client side and have nothing to do with the server side
(this is our current implementation).
Adrian is right about it too. We shouldn't use main deployer in
jbossws AS IL, see: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4059193#4059205
We're using it because of our current Endpoint impl.
But Endpoint impl as specified in JAX-WS spec has nothing
to do with endpoint publishing in server runtime.
Thus current Endpoint implementation needs
complete rewrite to be usable on client side only
in single JVM without Server incorporated.
I'm removing the old endpoint implementation from server integration layer for
now. This removal represents no problem for us at the moment, because endpoint
publish() method sets are now excluded in TCK5 and it passes even without that Endpoint impl.
However this needs to be fixed in the future, because JAX-WS spec requires it
(although this is not tested in the TCK now).
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBWS-2777) Schema imports and includes not correctly processed by WSDL11Reader if same xsd previously processed.
by Darran Lofthouse (JIRA)
Schema imports and includes not correctly processed by WSDL11Reader if same xsd previously processed.
-----------------------------------------------------------------------------------------------------
Key: JBWS-2777
URL: https://jira.jboss.org/jira/browse/JBWS-2777
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.2.0
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jbossws-native-3.2.1
This is a continuation of JBWS-2411 where an optimisation was put in place to prevent an OutOfMemoryError caused by circular schema includes.
The change introduced a side effect and if subsequent imports or includes are found for the same schema as the processing is skipped because it has been performed once before the update of the schema location is also skipped.
At the same time schemas with no target namespace are also silently dropped so if these are required by the referenced schemas further parsing will result in numerous errors being reported.
--
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
15 years, 1 month