[JBoss JIRA] Created: (JBWS-2129) Wrapper class is not found
by Thomas Diesler (JIRA)
Wrapper class is not found
--------------------------
Key: JBWS-2129
URL: http://jira.jboss.com/jira/browse/JBWS-2129
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro
Affects Versions: jbossws-metro-1.0.1
Reporter: Thomas Diesler
[tdiesler@tdvaio trunk]$ ant -Dtest=jaxws/handlerscope test
Caused by: com.sun.xml.ws.model.RuntimeModelerException: runtime modeler error: Wrapper class org.jboss.test.ws.jaxws.handlerscope.jaxws.Echo is not found. Have you run APT to generate them?
at com.sun.xml.ws.model.RuntimeModeler.getClass(RuntimeModeler.java:287)
at com.sun.xml.ws.model.RuntimeModeler.processDocWrappedMethod(RuntimeModeler.java:596)
at com.sun.xml.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:543)
at com.sun.xml.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:371)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:258)
at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:322)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:188)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parseAdapters(DeploymentDescriptorParserExt.java:291)
--
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, 1 month
[JBoss JIRA] Created: (JBWS-2246) NPE deploying web services in service archive in CR1 release
by Andrew Dinn (JIRA)
NPE deploying web services in service archive in CR1 release
------------------------------------------------------------
Key: JBWS-2246
URL: http://jira.jboss.com/jira/browse/JBWS-2246
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-native-3.0.2
Environment: Vanilla JBossAS5.0.0.CR1 release on Fedora 9/Sun JDK 1.5.0_12-b0
Reporter: Andrew Dinn
I am trying to deploy a sar in AS5.0.0.CR1 which includes several war files. These wars include JaxWS SEI classes anotated with WebService annotations. The AS is using the bundled version of JBossWS Native.
The war file deployment breaks if the sar is deployed before starting JBoss AS. This is because the WS KernelLocator bean has not been intiialized. This is supposed to happen via bean injection according to the bean definition in jbossws-container-beans.xml located in server//deploy. However, the war file is processed (by an instance of JaxWSDeployerHookPreJSE) before the value is injected. The deployer tries to look up the wsf runtime via the kernel and receives a null pointer exception (stack trace as follows):
. . .
Caused by: java.lang.NullPointerException
at org.jboss.wsf.common.KernelAwareSPIFactory.getKernelProvidedSPI(KernelAwareSPIFactory.java:40)
at org.jboss.wsf.framework.DefaultWSFRuntimeLocator.locateRuntime(DefaultWSFRuntimeLocator.java:36)
at org.jboss.wsf.container.jboss50.deployer.AbstractDeployerHook.getWsfRuntime(AbstractDeployerHook.java:59)
at org.jboss.wsf.container.jboss50.deployer.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:86)
at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
... 18 more
--
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, 1 month
[JBoss JIRA] Created: (JBWS-2278) JBossWS is picking the wrong binding when both Soap1.1 and Soap1.2 bindings are provided for a port
by Andrew Dinn (JIRA)
JBossWS is picking the wrong binding when both Soap1.1 and Soap1.2 bindings are provided for a port
---------------------------------------------------------------------------------------------------
Key: JBWS-2278
URL: https://jira.jboss.org/jira/browse/JBWS-2278
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.2
Environment: AS 5.0.0.CR1
Reporter: Andrew Dinn
I am implementing an interop test using WSDL organized as follows:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc002"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://www.wstf.org/docs/scenarios/sc002">
<wsdl:types>
. . .
</wsdl:types>
<wsdl:message name="Begin">
<wsdl:part name="Begin" element="tns:Begin"/>
. . .
</wsdl:message>
<wsdl:portType name="sc002Port">
<wsdl:operation name="Begin">
. . .
</wsdl:portType>
<wsdl:binding name="sc002SOAP11Binding" type="tns:sc002Port">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="Begin">
. . .
</wsdl:binding>
<wsdl:binding name="sc002SOAP12Binding" type="tns:sc002Port">
<soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="Begin">
. . .
</wsdl:binding>
<wsdl:service name="sc002Service">
<wsdl:port name="soap11port" binding="tns:sc002SOAP11Binding">
<soap:address location="http://www.wstf.org/sc002/sc002SOAP11"/>
</wsdl:port>
<wsdl:port name="soap12port" binding="tns:sc002SOAP12Binding">
<soap12:address location="http://www.wstf.org/sc002/sc002SOAP12"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
In other words, there is one port, two bindings and one service exporting the two bindings.
I create a client proxy for the port named "soap11port" by invoking
new Sc002Service().getPort(new QName("http://www.wstf.org/docs/scenarios/sc002", "soap11port"), Sc002Port.class)
The returned port uses a SOAP12 binding even though the WSDL labels it clearly as a 1.1 port.
The problem arises because of an error in the construction of the ClientEndPointMetaData used as the endpointMetaData attached to the ClientProxy. This is constructed inside the ServiceDelegateImpl constructor by invoking JAXWSClientMetaDataBuilder.buildMetaData(). The error occurs in inherited method MetaDataBuilder.initEndpointBinding() when it tries to identify the binding associated with QName sc002:soap11port. The following 4 lines are where it goes wrong:
WSDLDefinitions wsdlDefinitions = wsdlEndpoint.getWsdlService().getWsdlDefinitions();
WSDLInterface wsdlInterface = wsdlEndpoint.getInterface();
WSDLBinding wsdlBinding = wsdlDefinitions.getBindingByInterfaceName(wsdlInterface.getName());
String bindingType = wsdlBinding.getType();
The first two lines locate the port sc002 associated with the binding identified by sc002:soap11port. The 3rd line then reverse searches from the port to find a binding which binds it. Of course there are two of these and, mirabile dictu, the code even prints a warning about this. It then ignores the correct and returns the soap12 binding.
Ironically before reaching this point the JAXWSClientMetaDataBuilder does this search correctly in method buildMetaDataInternal at lines 154/5 it executes this code
WSDLBinding wsdlBinding = wsdlEndpoint.getWsdlService().getWsdlDefinitions().getBinding(bindingName);
String bindingType = wsdlBinding.getType();
I assume the convoluted code in the inherited method is there for a reason but, then again, that's what overriding was invented for.
--
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
16 years, 2 months