February 2008 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBWS-1559) WSDL To Java - Elements with name class cause method getClass to be generated which conflicts with same method in Object.

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1559?page=all ] Thomas Diesler updated JBWS-1559: --------------------------------- Assignee: (was: Darran Lofthouse) > WSDL To Java - Elements with name class cause method getClass to be generated which conflicts with same method in Object. > ------------------------------------------------------------------------------------------------------------------------- > > Key: JBWS-1559 > URL: http://jira.jboss.com/jira/browse/JBWS-1559 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tools-jaxrpc > Reporter: Darran Lofthouse > Fix For: community contributions > > > WSDL To Java - Elements with name class cause method getClass to be generated which conflicts with same method in Object. > JBWS-1534 addresses issues withe element names being reserved keywords but elements named 'class' are a special case as it causes a getClass method to be generated with a return type incompatible with the getClass method of Object. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1432) WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning.

by Darran Lofthouse (JIRA)

WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning. --------------------------------------------------------------------------------------- Key: JBWS-1432 URL: http://jira.jboss.com/jira/browse/JBWS-1432 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: wstools Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: jbossws-1.2.0.CR1 WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning. At the moment unless the parameters for all operations can be unwrapped we throw an exception and stop processing the WSDL. If instead we unwrap what we can it will make it a lot easier to configure WSDL to Java and users will not need to worry about setting the parameter-style unless they want to force bare style. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBWS-1524) WSTools does not handle more than 2 levels of Class Hierarchy properly

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1524?page=all ] Thomas Diesler updated JBWS-1524: --------------------------------- Assignee: (was: Darran Lofthouse) > WSTools does not handle more than 2 levels of Class Hierarchy properly > ---------------------------------------------------------------------- > > Key: JBWS-1524 > URL: http://jira.jboss.com/jira/browse/JBWS-1524 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tools-jaxrpc > Environment: JBoss4.0.5GA WSTools > Reporter: Magesh Kumar B > Fix For: community contributions > > Attachments: AdminResponseDataWS.java, ResponseDataWS.java, SessionDataWS.java, SessionResponseDataWS.java, StartSessionResponseDataWS.java > > > Consider the following SEI > package com.intuit.fibcm.service; > import com.intuit.fibcm.fibcmwsobjects.*; > import java.rmi.Remote; > import java.rmi.RemoteException; > public interface WSTestServiceSEI extends Remote > { > public StartSessionResponseDataWS startSession (String input) throws RemoteException; > } > Using the following config.xml > <?xml version="1.0" encoding="UTF-8"?> >  > <configuration> > <java-wsdl> > <service name="SampleService" parameter-style="bare" endpoint="com.intuit.fibcm.service.WSTestServiceSEI" /> > <namespaces target-namespace="http://com.ball.wstest" > type-namespace="http://com.ball.wstest/types"/> > <mapping file="jaxrpc-mapping.xml"/> > <webservices servlet-link="WSTestEndpoint"/> > </java-wsdl> > </configuration> > along with the attached Class files defining the hierarchy > ResponseDataWS --> AdminResponseDataWS --> SessionResponseDataWS --> StartSessionResponseDataWS > the following wsdl is generated which is wrong: > <complexType name='AdminResponseDataWS'> > <complexContent> > <extension base='tns:ResponseDataWS'> > <sequence/> > </extension> > </complexContent> > </complexType> > <complexType name='ResponseDataWS'> > <sequence> > <element name='sessionData' nillable='true' type='tns:SessionDataWS'/> > </sequence> > </complexType> > <complexType name='SessionDataWS'> > <sequence/> > </complexType> > <complexType name='SessionResponseDataWS'> > <complexContent> > <extension base='tns:AdminResponseDataWS'> > <sequence> > <element name='sessionData' nillable='true' type='tns:SessionDataWS'/> > </sequence> > </extension> > </complexContent> > </complexType> > </schema> > <schema targetNamespace='http://com.ball.wstest/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:ns1='http://fibcmwsobjects.fibcm.intuit.com/jaws' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://com.ball.wstest/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'> > <import namespace='http://fibcmwsobjects.fibcm.intuit.com/jaws'/> > <complexType name='StartSessionResponseDataWS'> > <complexContent> > <extension base='ns1:SessionResponseDataWS'> > <sequence> > <element name='sessionData' nillable='true' type='ns1:SessionDataWS'/> > <element name='sessionData' nillable='true' type='ns1:SessionDataWS'/> > </sequence> > </extension> > </complexContent> > </complexType> > At the 3rd level of the hierarchy the sessionData is added once, and at the 4th level it is added twice. But the 2nd level is generated correctly without any member elements. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-1530) wstools miss arrays of type long

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1530?page=all ] Thomas Diesler updated JBWS-1530: --------------------------------- Assignee: (was: Darran Lofthouse) > wstools miss arrays of type long > -------------------------------- > > Key: JBWS-1530 > URL: http://jira.jboss.com/jira/browse/JBWS-1530 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tools-jaxrpc > Environment: JBoss 4.0.5 resp. JEMS 1.2.0, JBossWS 1.2.0CR3, JDK 1.5.0_11, WinXP > Reporter: Juergen Zimmermann > Fix For: community contributions > > > When a web service operation returns a long array then at runtime a WSDL is generated as follows: > <definitions name='...' ... xmlns:ns1='http://jaxb.dev.java.net/array' ... > ... > <message name='MySEI_myMethodResponse'> > <part name='result' type='ns1:longArray'/> > </message> > However, wstools just omit xmlns:ns1='http://jaxb.dev.java.net/array' . Additionaly the type generation differs: > Runtime: > <xs:schema targetNamespace='http://jaxb.dev.java.net/array' version='1.0' xmlns:xs='http://www.w3.org/2001/XMLSchema'> > <xs:complexType final='#all' name='longArray'> > <xs:sequence> > <xs:element maxOccurs='unbounded' minOccurs='0' name='item' nillable='true' type='xs:long'/> > </xs:sequence> > </xs:complexType> > </xs:schema> > wstools: > <complexType name='Long.Array'> > <sequence> > <element maxOccurs='unbounded' minOccurs='0' name='value' nillable='true' type='long'/> > </sequence> > </complexType> -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1459) Java to WSDL - Incorrect handling of arrays with bare parameter style

by Darran Lofthouse (JIRA)

Java to WSDL - Incorrect handling of arrays with bare parameter style --------------------------------------------------------------------- Key: JBWS-1459 URL: http://jira.jboss.com/jira/browse/JBWS-1459 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: wstools Affects Versions: jbossws-1.2.0.CR2 Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: jbossws-1.2.1 Java to WSDL - Incorrect handling of arrays with bare parameter style The following method on a SEI: - public String[] lookup(final String[] person) throws RemoteException; The following type is generated in the WSDL: - <complexType name='String.Array'> <sequence> <element maxOccurs='unbounded' minOccurs='0' name='value' nillable='true' type='string'/> </sequence> </complexType> This type is not mapped in the generated JAX-RPC mapping so the following error is reported on deployment: - Caused by: org.jboss.ws.WSException: Cannot obtain java type mapping for: {http://www.jboss.org/support/phonebook/types}String.Array at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.processDocElement(JAXRPCMetaDataBuilder.java:613) at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildParameterMetaDataDoc(JAXRPCMetaDataBuilder.java:865) at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.setupOperationsFromWSDL(JAXRPCMetaDataBuilder.java:214) at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCServerMetaDataBuilder.buildMetaData(JAXRPCServerMetaDataBuilder.java:219) at org.jboss.ws.core.server.ServiceEndpointDeployer.create(ServiceEndpointDeployer.java:81) at org.jboss.ws.integration.jboss42.DeployerInterceptor.createServiceEndpoint(DeployerInterceptor.java:127) at org.jboss.ws.integration.jboss42.DeployerInterceptorJSE.createServiceEndpoint(DeployerInterceptorJSE.java:130) at org.jboss.ws.integration.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:78) -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBWS-299) Tools: "NoDataBinding" option for doc/literal Web Services

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-299?page=all ] Thomas Diesler updated JBWS-299: -------------------------------- Assignee: (was: Darran Lofthouse) > Tools: "NoDataBinding" option for doc/literal Web Services > ---------------------------------------------------------- > > Key: JBWS-299 > URL: http://jira.jboss.com/jira/browse/JBWS-299 > Project: JBoss Web Services > Issue Type: Feature Request > Components: tools-jaxrpc > Reporter: Anil Saldhana > Priority: Optional > Fix For: community contributions > > > wscompile has an option "-f:nodatabinding" that turns off data binding in the input parameters and return types for doc/lit web services. More information is available in the feature matrix. That info is copy/pasted here: > > wscompile uses this option to turn off data binding for literal encoding. This is a very important option when dealing with doc/literal wsdl files. Let us take an example of a web service that returns employee data. > > The SEI generated by wscompile will look as follows: > public interface EmployeeQuery extends Remote { > public double getSalary() throws RemoteException; > public String getManagerName(int level) throws RemoteException; > } > Now if the -f:nodatabinding option is used, the generated SEI will not have any typed arguments or return types, but they will all be mapped to javax.xml.soap.SOAPElement (xsd:any equivalent). > public interface EmployeeQuery extends Remote { > public javax.xml.soap.SOAPElement getSalary() throws RemoteException; > public javax.xml.soap.SOAPElement getManagerName(javax.xml.soap.SOAPElement level) throws RemoteException; > } > Supported by jbossws with the "nodatabinding" attribute in the <wsdltojava> element. > A point to be noted is the user will have to use SAAJ to construc messages to invoke the webservice and has to decode the return message (if any) using SAAJ. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-1078) WSDL11ToJavaTestCase - Should verify the SEIs that are generated.

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBWS-1078?page=all ] Thomas Diesler updated JBWS-1078: --------------------------------- Assignee: (was: Darran Lofthouse) > WSDL11ToJavaTestCase - Should verify the SEIs that are generated. > ----------------------------------------------------------------- > > Key: JBWS-1078 > URL: http://jira.jboss.com/jira/browse/JBWS-1078 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tools-jaxrpc > Affects Versions: jbossws-1.0.1 > Reporter: Darran Lofthouse > Fix For: community contributions > > > WSDL11ToJavaTestCase - Should verify the SEIs that are generated. > Also this test case should be expanded to incude all of the available WSDLs under 'src\test\resources\wsdlfixture'. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1709) Context servlet for XFire

by Thomas Diesler (JIRA)

Context servlet for XFire ------------------------- Key: JBWS-1709 URL: http://jira.jboss.com/jira/browse/JBWS-1709 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: integration-sunri Reporter: Thomas Diesler Assigned To: Thomas Diesler Fix For: jbossws-2.1.0 -- 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, 2 months

1
5
0 / 0

[JBoss JIRA] Created: (JBWS-1978) Evaluate (and remove) JBPM dependency from component info

by Heiko Braun (JIRA)

Evaluate (and remove) JBPM dependency from component info --------------------------------------------------------- Key: JBWS-1978 URL: http://jira.jboss.com/jira/browse/JBWS-1978 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: jbossws-native-2.0.4 It causes EAP headache, because it pulls in to many dependencies and doesn't seem to be required. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1982) Simplify deploy/undeploy cycles for different stacks

by Heiko Braun (JIRA)

Simplify deploy/undeploy cycles for different stacks ---------------------------------------------------- Key: JBWS-1982 URL: http://jira.jboss.com/jira/browse/JBWS-1982 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Heiko Braun Whenever you want to install one of the three options you need to properly uninstall ('ant undeploy-jbossXYZ') the existing stack. However this currently requires you to download the corresponding binary, which IMO is not an option. Each of the deliverables should contain am ant macro to undeploy the two opponents. -- 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, 2 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues February 2008