You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Phillips, Chad" <Ch...@gdit.com> on 2009/08/18 23:25:50 UTC

Issue using JAXB generated classes in SCA remotable service

Hi All,

I'm using SCA Java 1.5 and I'm running into an issue when data is being returned from a service invocation for a Remotable service using the WS binding.  The service is returning instances of classes that were generated using JAXB from multiple XSDs.  These schemas include a number of abstract elements as well as substitution groups.  I'm not particularly proficient with XSD so my terminology may be off but, I believe that the problem is that since the concrete types for these various abstract elements are not in the same package as the base types, they don't get included the un/marshaller's context.  They are also not in the WSDL generated via the WS binding.  The stack trace I'm seeing is at the bottom of this e-mail.

So, based on the stack trace, does it look like some missing namespaces would cause this issue?  If so, is there a way to explicitly include additional namespaces such that they'll be properly included in the un/marshaller's context?  They would also need to be imported in the WSDL generated by the WS binding.  If at all possible I'd like to avoid having to manually create or modify the WSDL or any of generated classes (JAXB / JAXWS).

Here is the stack trace:

org.apache.axis2.AxisFault
        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
        at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
        at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
        at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
        at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
        at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
        at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.xml.stream.XMLStreamException
        at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
        at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
        at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
        at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
        at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
        at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
        ... 30 more

- Chad Phillips

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Hi All,

I'm not sure if this made it through last time so I'm sending it again. 

I'm using SCA Java 1.5 and I'm running into an issue when data is being returned from a service invocation for a Remotable service using the WS binding.  The service is returning instances of classes that were generated using JAXB from multiple XSDs.  These schemas include a number of abstract elements as well as substitution groups.  I'm not particularly proficient with XSD so my terminology may be off but, I believe that the problem is that since the concrete types for these various abstract elements are not in the same package as the base types, they don't get included the un/marshaller's context.  They are also not in the WSDL generated via the WS binding.  The stack trace I'm seeing is at the bottom of this e-mail.

So, based on the stack trace, does it look like some missing namespaces would cause this issue?  If so, is there a way to explicitly include additional namespaces such that they'll be properly included in the un/marshaller's context?  They would also need to be imported in the WSDL generated by the WS binding.  If at all possible I'd like to avoid having to manually create or modify the WSDL or any of generated classes (JAXB / JAXWS).

Here is the stack trace:

org.apache.axis2.AxisFault
        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
        at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
        at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
        at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
        at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
        at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
        at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.xml.stream.XMLStreamException
        at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
        at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
        at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
        at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
        at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
        at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
        at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
        ... 30 more

- Chad Phillips

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
I thought I saw something about the context but I must have been thinking about a different error.  For the elements using substitution groups, the "concrete" implementations do not inherit the abstract types.  I'm not sure if that's what's expected with JAXB but the objects do un/marshall successfully in other places in the application using a context w/ all of the package names (called explicitly by the app outside of an SCA binding).

It sounds like there are too many unknowns on my side so I'll create a test program and see if I can re-produce the problem w/ 1.5 and then test that against the 1.6 snapshot.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, August 18, 2009 14:38
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Do the generated subclasses extend from base classes? If so, I assume adding 
the subclass into the JAXBContext will automatically add the base classes.

It seems the stracktrace is missing the part that complains about the 
JAXBContext. Can you post it here?

We made some improvements in this area: 
http://svn.apache.org/viewvc?rev=795991&view=rev. Can you try if it helps?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, August 18, 2009 2:25 PM
To: <us...@tuscany.apache.org>
Subject: Issue using JAXB generated classes in SCA remotable service

> Hi All,
>
> I'm using SCA Java 1.5 and I'm running into an issue when data is being 
> returned from a service invocation for a Remotable service using the WS 
> binding.  The service is returning instances of classes that were 
> generated using JAXB from multiple XSDs.  These schemas include a number 
> of abstract elements as well as substitution groups.  I'm not particularly 
> proficient with XSD so my terminology may be off but, I believe that the 
> problem is that since the concrete types for these various abstract 
> elements are not in the same package as the base types, they don't get 
> included the un/marshaller's context.  They are also not in the WSDL 
> generated via the WS binding.  The stack trace I'm seeing is at the bottom 
> of this e-mail.
>
> So, based on the stack trace, does it look like some missing namespaces 
> would cause this issue?  If so, is there a way to explicitly include 
> additional namespaces such that they'll be properly included in the 
> un/marshaller's context?  They would also need to be imported in the WSDL 
> generated by the WS binding.  If at all possible I'd like to avoid having 
> to manually create or modify the WSDL or any of generated classes (JAXB / 
> JAXWS).
>
> Here is the stack trace:
>
> org.apache.axis2.AxisFault
>        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
>        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>        at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
>        at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>        at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>        at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
>        at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>        at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>        at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.xml.stream.XMLStreamException
>        at 
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
>        at 
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
>        ... 30 more
>
> - Chad Phillips

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
I'm pretty close to setting up the workaround you described but I can't seem to get step 5 to work.  Here is what my service definition looks like:

<service name="SomeService">
    <binding.ws uri="http://localhost:8080/App/SomeService" wsdlElement="http://namespace#wsdl.port(SomeServiceService/SomeServicePort)" />
</service>

When I grab the WSDL for this service I get a generated WSDL instead of my hand-modified WSDL (resulting in the same wsimport errors).  I believe the expected result is a WSDL that imports my hand-modified WSDL right?

I tried a few other variations as well (wsdl.binding, wsdl.service) but no joy.  What also seemed odd was that when I tried the setup below, the server started up find but the service was no longer available (404):

<service name="SomeService">
    <binding.ws wsdlElement="http://namespace#wsdl.port(SomeServiceService/SomeServicePort)" />
</service>

The good news is that in my client application I used same bindings that I used on the server side (generated from the hand-modified WSDL) and verified that I can get data from the service, which is great!

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, September 04, 2009 11:50
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Let us step back and try to understand what you want to achieve here. Here
is my understanding:

1) You have a few XSDs and want to generate JAXB classes to represent them
in Java
2) You use the generated JAXB classes for the your SCA java component and
expose the service using binding.ws
3) Tuscany generates a WSDL from your service interface which uses JAXB
classes
4) You have WS client that uses the WSDL to generate client code

Why don't we just simply do the following way?
1) Create a WSDL that uses the XSDs
2) Run wsimport to generate JAX-WS and JAXB classes
3) Use the generated JAX-WS service endpoint interface as the SCA interface
4) Implement your SCA component
5) Configure the SCA component service using binidng.ws with @wsdlElement
pointing to the WSDL service/port, binding or portType. This way, the WSDL
will be derived from your original WSDL.

Can you give a try while I'm further investigating the schema generation
issue?

Thanks,
Raymond
--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Friday, September 04, 2009 10:33 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> That schema that's using the xlink attributes is importing the xlink XSD.
> However, the xlink XSD only contains attributes and attributeGroups so XJC
> doesn't generate any classes from that schema (I assume that's expected).
> I attached an updated test program to TUSCANY-3238 which reproduces the
> problem; it includes the xlinks XSD used as well as a WSDL that generates
> the same errors.
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Friday, September 04, 2009 09:33
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> It seems that JAXB Java to XSD generation expands things such as
> attributeGroup or substitutionGroup. For example,
>
> <xs:attributeGroup ref="xlink:locatorLink"/>
>
> becomes:
>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>
> IMO, this is OK. The namespaces are correctly declared. Now it's a matter
> of
> how the xlink schema is referenced. Do you have xsd:import in your
> original
> schema to point to the xlink XSD? Do you have the generated JAXB classes
> for
> the xlink XSD?
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Thursday, September 03, 2009 6:14 PM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> Hi Raymond,
>>
>> I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch
>> (r810694) but, wsimport is bombing out on the generated WSDL for my
>> application's service.  I'm still trying to isolate the problem and add
>> it
>> to the test program but, for now, here is some info on the problem.
>>
>> The original schema has this type:
>>
>> <xs:complexType name="RType">
>> <xs:sequence>
>> <xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:complexContent>
>> <xs:extension base="SomeBaseType">
>> <xs:sequence>
>> <xs:element name="link" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:attributeGroup ref="xlink:locatorLink"/>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> <xs:attribute name="a" type="xs:anyURI" use="required" />
>> <!-- various attributes -->
>> </xs:complexType>
>>
>> In the generated WSDL, the type definition looks like this:
>>
>> <xs:complexType name="RType">
>>    <xs:sequence>
>>        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
>>            <xs:complexType>
>>                <xs:complexContent>
>>                    <xs:extension base="tns:SomeBaseType">
>>                        <xs:sequence>
>>                            <xs:element maxOccurs="unbounded" name="link">
>>                                <xs:complexType>
>>                                    <xs:sequence/>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>>                                </xs:complexType>
>>                            </xs:element>
>>                        </xs:sequence>
>>                    </xs:extension>
>>                </xs:complexContent>
>>            </xs:complexType>
>>        </xs:element>
>>    </xs:sequence>
>>    <xs:attribute ref="tns:a" use="required"/>
>>    <!-- various attributes-->
>> </xs:complexType>
>>
>> Here are the errors I'm getting:
>>
>> [ERROR] undefined attribute 'ns3:type'
>> [ERROR] undefined attribute 'ns4:href'
>> [ERROR] undefined attribute 'ns5:role'
>> [ERROR] undefined attribute 'ns6:title'
>> [ERROR] undefined attribute 'ns7:label'
>>
>> And there are some warnings for that type that may (or may not) be
>> related
>> to the issue:
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is
>> invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.
>>
>> [wsimport] [WARNING] src-resolve.4.2: Error resolving component
>> 'ns3:type'. It was detected that 'ns3:type' is in namespace
>> 'http://www.w3.org/1999/xlink', but components from this namespace are
>> not
>> referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If
>> this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs
>> to
>> be changed. If this is the correct namespace, then an appropriate
>> 'import'
>> tag should be added to 'file:/C:/test.wsdl#types?schema9'.
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of
>> '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid,
>> misplaced, or occurs too often.
>>
>> -----Original Message-----
>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>> Sent: Tuesday, September 01, 2009 16:36
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> Hi,
>>
>> Hmm, it seems to be an issue in JAXB. Now the only option is to add
>> @XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying
>> it
>> with the 2.x stream:
>>
>> @Remotable
>> @XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
>> public interface TestService {
>>
>>    public DataType getData();
>>
>> }
>>
>> After fixing the j2w codegen, it produces the following wsdl. Can you try
>> this WSDL to see if it works? Meanwhile, I'll try to port the fix into
>> 1.x
>> after more tests.
>>
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <wsdl:definitions name="TestServiceService"
>> targetNamespace="http://server.test/" xmlns:tns="http://server.test/"
>> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
>> xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
>>  <wsdl:types>
>>    <xs:schema elementFormDefault="qualified" targetNamespace="abs"
>> version="1.0" xmlns:ns1="conc" xmlns:tns="abs"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="conc"/>
>> <xs:element name="IdentifierAbstract" type="xs:anyType"/>
>> <xs:complexType name="DataType"><xs:choice><xs:element
>> ref="tns:IdentifierAbstract"/><xs:element
>> ref="ns1:Identifier"/></xs:choice></xs:complexType>
>> </xs:schema>
>>    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs"
>> xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="abs"/>
>> <xs:element name="Identifier" type="tns:StringType"/>
>> <xs:element name="TestData" type="ns1:DataType"/>
>> <xs:simpleType name="StringType"><xs:restriction
>> base="xs:string"/></xs:simpleType>
>> </xs:schema>
>>    <xs:schema attributeFormDefault="qualified"
>> elementFormDefault="unqualified" targetNamespace="http://server.test/"
>> xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import
>> namespace="abs"/><xs:element
>> name="getDataResponse"><xs:complexType><xs:sequence><xs:element
>> minOccurs="0" name="return" nillable="true"
>> type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element
>> name="getData"><xs:complexType/></xs:element></xs:schema>
>>  </wsdl:types>
>>  <wsdl:message name="getDataResponse">
>>    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:message name="getData">
>>    <wsdl:part name="getData" element="tns:getData">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:portType name="TestService">
>>    <wsdl:operation name="getData">
>>      <wsdl:input message="tns:getData">
>>    </wsdl:input>
>>      <wsdl:output message="tns:getDataResponse">
>>    </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:portType>
>>  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
>>    <SOAP:binding style="document"
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>>    <wsdl:operation name="getData">
>>      <SOAP:operation/>
>>      <wsdl:input>
>>        <SOAP:body use="literal"/>
>>      </wsdl:input>
>>      <wsdl:output>
>>        <SOAP:body use="literal"/>
>>      </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:binding>
>>  <wsdl:service name="TestServiceService">
>>    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
>>      <SOAP:address
>> location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
>>    </wsdl:port>
>>  </wsdl:service>
>> </wsdl:definitions>
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Phillips, Chad" <Ch...@gdit.com>
>> Sent: Tuesday, September 01, 2009 10:53 AM
>> To: <us...@tuscany.apache.org>
>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>
>>> Adding ObjectFactory to that annotation has the effect of creating a
>>> complex type objectFactory in the WSDL:
>>>
>>> <xs:schema targetNamespace="conc" version="1.0">
>>> <xs:complexType name="objectFactory">
>>> <xs:sequence/>
>>> </xs:complexType>
>>> </xs:schema>
>>>
>>> -----Original Message-----
>>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>>> Sent: Tuesday, September 01, 2009 10:18
>>> To: user@tuscany.apache.org
>>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>>
>>> Hi,
>>>
>>> I just came back from vacation to catch the discussion.
>>>
>>> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class
>>> instead
>>> of conc.StringType.class? It seems that there is information in the
>>> ObjectFactory.class to describe the element substitutionGroup.
>>>
>>> Thanks,
>>> Raymond
>>> --------------------------------------------------
>>> From: "Phillips, Chad" <Ch...@gdit.com>
>>> Sent: Tuesday, September 01, 2009 9:43 AM
>>> To: <us...@tuscany.apache.org>
>>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>>
>>>> The WSDL generated by Tuscany is missing the Identifier element that is
>>>> present in the XSD used on the server side.  Maybe I'm still missing an
>>>> annotation?  Here is the data on the server side before it's returned
>>>> to
>>>> the client:
>>>>
>>>> <DataType xmlns:ns2="conc" xmlns="abs">
>>>>    <ns2:Identifier>FOO</ns2:Identifier>
>>>> </DataType>
>>>>
>>>> And here is what the client receives:
>>>>
>>>> <DataType xmlns="abs">
>>>>    <IdentifierAbstract xsi:nil="true"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>>> </DataType>
>>>>
>>>> Some of the clients that will be using the WS are not under my control
>>>> so
>>>> they'll most likely not being using Tuscany to access the service (I
>>>> believe most are using JAX-WS or Axis2).
>>>>
>>>> -----Original Message-----
>>>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>>>> Sent: Tuesday, September 01, 2009 09:07
>>>> To: user@tuscany.apache.org
>>>> Subject: Re: Issue using JAXB generated classes in SCA remotable
>>>> service
>>>>
>>>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>>>> wrote:
>>>>> Anyone get a chance to look at this yet?  It's a pretty major issue
>>>>> for
>>>>> my project as we can't return data in the required format.
>>>>
>>>> Chad, I'm not sure I'm totally following every step here... not sure
>>>> what you mean by "...WSDL is not being generated correctly".  I
>>>> haven't actually run your app.
>>>>
>>>> But would you say that the service-side is sending back the correct
>>>> XML, and you are having some problem on the client side?
>>>>
>>>> If so, I wonder if it would be useful to try using a Tuscany client w/
>>>> a reference with <binding.ws>?
>>>>
>>>> Scott
>>>
>>

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Making our own WSDL is an option that I hadn't thought of.  I'll give that a try.  Thanks for the help.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, September 04, 2009 11:50
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Let us step back and try to understand what you want to achieve here. Here
is my understanding:

1) You have a few XSDs and want to generate JAXB classes to represent them
in Java
2) You use the generated JAXB classes for the your SCA java component and
expose the service using binding.ws
3) Tuscany generates a WSDL from your service interface which uses JAXB
classes
4) You have WS client that uses the WSDL to generate client code

Why don't we just simply do the following way?
1) Create a WSDL that uses the XSDs
2) Run wsimport to generate JAX-WS and JAXB classes
3) Use the generated JAX-WS service endpoint interface as the SCA interface
4) Implement your SCA component
5) Configure the SCA component service using binidng.ws with @wsdlElement
pointing to the WSDL service/port, binding or portType. This way, the WSDL
will be derived from your original WSDL.

Can you give a try while I'm further investigating the schema generation
issue?

Thanks,
Raymond
--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Friday, September 04, 2009 10:33 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> That schema that's using the xlink attributes is importing the xlink XSD.
> However, the xlink XSD only contains attributes and attributeGroups so XJC
> doesn't generate any classes from that schema (I assume that's expected).
> I attached an updated test program to TUSCANY-3238 which reproduces the
> problem; it includes the xlinks XSD used as well as a WSDL that generates
> the same errors.
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Friday, September 04, 2009 09:33
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> It seems that JAXB Java to XSD generation expands things such as
> attributeGroup or substitutionGroup. For example,
>
> <xs:attributeGroup ref="xlink:locatorLink"/>
>
> becomes:
>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>
> IMO, this is OK. The namespaces are correctly declared. Now it's a matter
> of
> how the xlink schema is referenced. Do you have xsd:import in your
> original
> schema to point to the xlink XSD? Do you have the generated JAXB classes
> for
> the xlink XSD?
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Thursday, September 03, 2009 6:14 PM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> Hi Raymond,
>>
>> I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch
>> (r810694) but, wsimport is bombing out on the generated WSDL for my
>> application's service.  I'm still trying to isolate the problem and add
>> it
>> to the test program but, for now, here is some info on the problem.
>>
>> The original schema has this type:
>>
>> <xs:complexType name="RType">
>> <xs:sequence>
>> <xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:complexContent>
>> <xs:extension base="SomeBaseType">
>> <xs:sequence>
>> <xs:element name="link" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:attributeGroup ref="xlink:locatorLink"/>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> <xs:attribute name="a" type="xs:anyURI" use="required" />
>> <!-- various attributes -->
>> </xs:complexType>
>>
>> In the generated WSDL, the type definition looks like this:
>>
>> <xs:complexType name="RType">
>>    <xs:sequence>
>>        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
>>            <xs:complexType>
>>                <xs:complexContent>
>>                    <xs:extension base="tns:SomeBaseType">
>>                        <xs:sequence>
>>                            <xs:element maxOccurs="unbounded" name="link">
>>                                <xs:complexType>
>>                                    <xs:sequence/>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>>                                </xs:complexType>
>>                            </xs:element>
>>                        </xs:sequence>
>>                    </xs:extension>
>>                </xs:complexContent>
>>            </xs:complexType>
>>        </xs:element>
>>    </xs:sequence>
>>    <xs:attribute ref="tns:a" use="required"/>
>>    <!-- various attributes-->
>> </xs:complexType>
>>
>> Here are the errors I'm getting:
>>
>> [ERROR] undefined attribute 'ns3:type'
>> [ERROR] undefined attribute 'ns4:href'
>> [ERROR] undefined attribute 'ns5:role'
>> [ERROR] undefined attribute 'ns6:title'
>> [ERROR] undefined attribute 'ns7:label'
>>
>> And there are some warnings for that type that may (or may not) be
>> related
>> to the issue:
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is
>> invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.
>>
>> [wsimport] [WARNING] src-resolve.4.2: Error resolving component
>> 'ns3:type'. It was detected that 'ns3:type' is in namespace
>> 'http://www.w3.org/1999/xlink', but components from this namespace are
>> not
>> referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If
>> this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs
>> to
>> be changed. If this is the correct namespace, then an appropriate
>> 'import'
>> tag should be added to 'file:/C:/test.wsdl#types?schema9'.
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of
>> '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid,
>> misplaced, or occurs too often.
>>
>> -----Original Message-----
>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>> Sent: Tuesday, September 01, 2009 16:36
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> Hi,
>>
>> Hmm, it seems to be an issue in JAXB. Now the only option is to add
>> @XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying
>> it
>> with the 2.x stream:
>>
>> @Remotable
>> @XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
>> public interface TestService {
>>
>>    public DataType getData();
>>
>> }
>>
>> After fixing the j2w codegen, it produces the following wsdl. Can you try
>> this WSDL to see if it works? Meanwhile, I'll try to port the fix into
>> 1.x
>> after more tests.
>>
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <wsdl:definitions name="TestServiceService"
>> targetNamespace="http://server.test/" xmlns:tns="http://server.test/"
>> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
>> xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
>>  <wsdl:types>
>>    <xs:schema elementFormDefault="qualified" targetNamespace="abs"
>> version="1.0" xmlns:ns1="conc" xmlns:tns="abs"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="conc"/>
>> <xs:element name="IdentifierAbstract" type="xs:anyType"/>
>> <xs:complexType name="DataType"><xs:choice><xs:element
>> ref="tns:IdentifierAbstract"/><xs:element
>> ref="ns1:Identifier"/></xs:choice></xs:complexType>
>> </xs:schema>
>>    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs"
>> xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="abs"/>
>> <xs:element name="Identifier" type="tns:StringType"/>
>> <xs:element name="TestData" type="ns1:DataType"/>
>> <xs:simpleType name="StringType"><xs:restriction
>> base="xs:string"/></xs:simpleType>
>> </xs:schema>
>>    <xs:schema attributeFormDefault="qualified"
>> elementFormDefault="unqualified" targetNamespace="http://server.test/"
>> xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import
>> namespace="abs"/><xs:element
>> name="getDataResponse"><xs:complexType><xs:sequence><xs:element
>> minOccurs="0" name="return" nillable="true"
>> type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element
>> name="getData"><xs:complexType/></xs:element></xs:schema>
>>  </wsdl:types>
>>  <wsdl:message name="getDataResponse">
>>    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:message name="getData">
>>    <wsdl:part name="getData" element="tns:getData">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:portType name="TestService">
>>    <wsdl:operation name="getData">
>>      <wsdl:input message="tns:getData">
>>    </wsdl:input>
>>      <wsdl:output message="tns:getDataResponse">
>>    </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:portType>
>>  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
>>    <SOAP:binding style="document"
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>>    <wsdl:operation name="getData">
>>      <SOAP:operation/>
>>      <wsdl:input>
>>        <SOAP:body use="literal"/>
>>      </wsdl:input>
>>      <wsdl:output>
>>        <SOAP:body use="literal"/>
>>      </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:binding>
>>  <wsdl:service name="TestServiceService">
>>    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
>>      <SOAP:address
>> location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
>>    </wsdl:port>
>>  </wsdl:service>
>> </wsdl:definitions>
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Phillips, Chad" <Ch...@gdit.com>
>> Sent: Tuesday, September 01, 2009 10:53 AM
>> To: <us...@tuscany.apache.org>
>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>
>>> Adding ObjectFactory to that annotation has the effect of creating a
>>> complex type objectFactory in the WSDL:
>>>
>>> <xs:schema targetNamespace="conc" version="1.0">
>>> <xs:complexType name="objectFactory">
>>> <xs:sequence/>
>>> </xs:complexType>
>>> </xs:schema>
>>>
>>> -----Original Message-----
>>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>>> Sent: Tuesday, September 01, 2009 10:18
>>> To: user@tuscany.apache.org
>>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>>
>>> Hi,
>>>
>>> I just came back from vacation to catch the discussion.
>>>
>>> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class
>>> instead
>>> of conc.StringType.class? It seems that there is information in the
>>> ObjectFactory.class to describe the element substitutionGroup.
>>>
>>> Thanks,
>>> Raymond
>>> --------------------------------------------------
>>> From: "Phillips, Chad" <Ch...@gdit.com>
>>> Sent: Tuesday, September 01, 2009 9:43 AM
>>> To: <us...@tuscany.apache.org>
>>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>>
>>>> The WSDL generated by Tuscany is missing the Identifier element that is
>>>> present in the XSD used on the server side.  Maybe I'm still missing an
>>>> annotation?  Here is the data on the server side before it's returned
>>>> to
>>>> the client:
>>>>
>>>> <DataType xmlns:ns2="conc" xmlns="abs">
>>>>    <ns2:Identifier>FOO</ns2:Identifier>
>>>> </DataType>
>>>>
>>>> And here is what the client receives:
>>>>
>>>> <DataType xmlns="abs">
>>>>    <IdentifierAbstract xsi:nil="true"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>>> </DataType>
>>>>
>>>> Some of the clients that will be using the WS are not under my control
>>>> so
>>>> they'll most likely not being using Tuscany to access the service (I
>>>> believe most are using JAX-WS or Axis2).
>>>>
>>>> -----Original Message-----
>>>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>>>> Sent: Tuesday, September 01, 2009 09:07
>>>> To: user@tuscany.apache.org
>>>> Subject: Re: Issue using JAXB generated classes in SCA remotable
>>>> service
>>>>
>>>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>>>> wrote:
>>>>> Anyone get a chance to look at this yet?  It's a pretty major issue
>>>>> for
>>>>> my project as we can't return data in the required format.
>>>>
>>>> Chad, I'm not sure I'm totally following every step here... not sure
>>>> what you mean by "...WSDL is not being generated correctly".  I
>>>> haven't actually run your app.
>>>>
>>>> But would you say that the service-side is sending back the correct
>>>> XML, and you are having some problem on the client side?
>>>>
>>>> If so, I wonder if it would be useful to try using a Tuscany client w/
>>>> a reference with <binding.ws>?
>>>>
>>>> Scott
>>>
>>

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Raymond Feng <en...@gmail.com>.
Let us step back and try to understand what you want to achieve here. Here 
is my understanding:

1) You have a few XSDs and want to generate JAXB classes to represent them 
in Java
2) You use the generated JAXB classes for the your SCA java component and 
expose the service using binding.ws
3) Tuscany generates a WSDL from your service interface which uses JAXB 
classes
4) You have WS client that uses the WSDL to generate client code

Why don't we just simply do the following way?
1) Create a WSDL that uses the XSDs
2) Run wsimport to generate JAX-WS and JAXB classes
3) Use the generated JAX-WS service endpoint interface as the SCA interface
4) Implement your SCA component
5) Configure the SCA component service using binidng.ws with @wsdlElement 
pointing to the WSDL service/port, binding or portType. This way, the WSDL 
will be derived from your original WSDL.

Can you give a try while I'm further investigating the schema generation 
issue?

Thanks,
Raymond
--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Friday, September 04, 2009 10:33 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> That schema that's using the xlink attributes is importing the xlink XSD. 
> However, the xlink XSD only contains attributes and attributeGroups so XJC 
> doesn't generate any classes from that schema (I assume that's expected). 
> I attached an updated test program to TUSCANY-3238 which reproduces the 
> problem; it includes the xlinks XSD used as well as a WSDL that generates 
> the same errors.
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Friday, September 04, 2009 09:33
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> It seems that JAXB Java to XSD generation expands things such as
> attributeGroup or substitutionGroup. For example,
>
> <xs:attributeGroup ref="xlink:locatorLink"/>
>
> becomes:
>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>
> IMO, this is OK. The namespaces are correctly declared. Now it's a matter 
> of
> how the xlink schema is referenced. Do you have xsd:import in your 
> original
> schema to point to the xlink XSD? Do you have the generated JAXB classes 
> for
> the xlink XSD?
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Thursday, September 03, 2009 6:14 PM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> Hi Raymond,
>>
>> I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch
>> (r810694) but, wsimport is bombing out on the generated WSDL for my
>> application's service.  I'm still trying to isolate the problem and add 
>> it
>> to the test program but, for now, here is some info on the problem.
>>
>> The original schema has this type:
>>
>> <xs:complexType name="RType">
>> <xs:sequence>
>> <xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:complexContent>
>> <xs:extension base="SomeBaseType">
>> <xs:sequence>
>> <xs:element name="link" maxOccurs="unbounded">
>> <xs:complexType>
>> <xs:attributeGroup ref="xlink:locatorLink"/>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> <xs:attribute name="a" type="xs:anyURI" use="required" />
>> <!-- various attributes -->
>> </xs:complexType>
>>
>> In the generated WSDL, the type definition looks like this:
>>
>> <xs:complexType name="RType">
>>    <xs:sequence>
>>        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
>>            <xs:complexType>
>>                <xs:complexContent>
>>                    <xs:extension base="tns:SomeBaseType">
>>                        <xs:sequence>
>>                            <xs:element maxOccurs="unbounded" name="link">
>>                                <xs:complexType>
>>                                    <xs:sequence/>
>>                                    <xs:attribute ref="ns3:type"
>> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns4:href"
>> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns5:role"
>> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns6:title"
>> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>>                                    <xs:attribute ref="ns7:label"
>> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>>                                </xs:complexType>
>>                            </xs:element>
>>                        </xs:sequence>
>>                    </xs:extension>
>>                </xs:complexContent>
>>            </xs:complexType>
>>        </xs:element>
>>    </xs:sequence>
>>    <xs:attribute ref="tns:a" use="required"/>
>>    <!-- various attributes-->
>> </xs:complexType>
>>
>> Here are the errors I'm getting:
>>
>> [ERROR] undefined attribute 'ns3:type'
>> [ERROR] undefined attribute 'ns4:href'
>> [ERROR] undefined attribute 'ns5:role'
>> [ERROR] undefined attribute 'ns6:title'
>> [ERROR] undefined attribute 'ns7:label'
>>
>> And there are some warnings for that type that may (or may not) be 
>> related
>> to the issue:
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is
>> invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.
>>
>> [wsimport] [WARNING] src-resolve.4.2: Error resolving component
>> 'ns3:type'. It was detected that 'ns3:type' is in namespace
>> 'http://www.w3.org/1999/xlink', but components from this namespace are 
>> not
>> referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If
>> this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs 
>> to
>> be changed. If this is the correct namespace, then an appropriate 
>> 'import'
>> tag should be added to 'file:/C:/test.wsdl#types?schema9'.
>>
>> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of
>> '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid,
>> misplaced, or occurs too often.
>>
>> -----Original Message-----
>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>> Sent: Tuesday, September 01, 2009 16:36
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> Hi,
>>
>> Hmm, it seems to be an issue in JAXB. Now the only option is to add
>> @XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying
>> it
>> with the 2.x stream:
>>
>> @Remotable
>> @XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
>> public interface TestService {
>>
>>    public DataType getData();
>>
>> }
>>
>> After fixing the j2w codegen, it produces the following wsdl. Can you try
>> this WSDL to see if it works? Meanwhile, I'll try to port the fix into 
>> 1.x
>> after more tests.
>>
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <wsdl:definitions name="TestServiceService"
>> targetNamespace="http://server.test/" xmlns:tns="http://server.test/"
>> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
>> xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
>>  <wsdl:types>
>>    <xs:schema elementFormDefault="qualified" targetNamespace="abs"
>> version="1.0" xmlns:ns1="conc" xmlns:tns="abs"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="conc"/>
>> <xs:element name="IdentifierAbstract" type="xs:anyType"/>
>> <xs:complexType name="DataType"><xs:choice><xs:element
>> ref="tns:IdentifierAbstract"/><xs:element
>> ref="ns1:Identifier"/></xs:choice></xs:complexType>
>> </xs:schema>
>>    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs"
>> xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
>> <xs:import namespace="abs"/>
>> <xs:element name="Identifier" type="tns:StringType"/>
>> <xs:element name="TestData" type="ns1:DataType"/>
>> <xs:simpleType name="StringType"><xs:restriction
>> base="xs:string"/></xs:simpleType>
>> </xs:schema>
>>    <xs:schema attributeFormDefault="qualified"
>> elementFormDefault="unqualified" targetNamespace="http://server.test/"
>> xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import
>> namespace="abs"/><xs:element
>> name="getDataResponse"><xs:complexType><xs:sequence><xs:element
>> minOccurs="0" name="return" nillable="true"
>> type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element
>> name="getData"><xs:complexType/></xs:element></xs:schema>
>>  </wsdl:types>
>>  <wsdl:message name="getDataResponse">
>>    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:message name="getData">
>>    <wsdl:part name="getData" element="tns:getData">
>>    </wsdl:part>
>>  </wsdl:message>
>>  <wsdl:portType name="TestService">
>>    <wsdl:operation name="getData">
>>      <wsdl:input message="tns:getData">
>>    </wsdl:input>
>>      <wsdl:output message="tns:getDataResponse">
>>    </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:portType>
>>  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
>>    <SOAP:binding style="document"
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>>    <wsdl:operation name="getData">
>>      <SOAP:operation/>
>>      <wsdl:input>
>>        <SOAP:body use="literal"/>
>>      </wsdl:input>
>>      <wsdl:output>
>>        <SOAP:body use="literal"/>
>>      </wsdl:output>
>>    </wsdl:operation>
>>  </wsdl:binding>
>>  <wsdl:service name="TestServiceService">
>>    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
>>      <SOAP:address
>> location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
>>    </wsdl:port>
>>  </wsdl:service>
>> </wsdl:definitions>
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Phillips, Chad" <Ch...@gdit.com>
>> Sent: Tuesday, September 01, 2009 10:53 AM
>> To: <us...@tuscany.apache.org>
>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>
>>> Adding ObjectFactory to that annotation has the effect of creating a
>>> complex type objectFactory in the WSDL:
>>>
>>> <xs:schema targetNamespace="conc" version="1.0">
>>> <xs:complexType name="objectFactory">
>>> <xs:sequence/>
>>> </xs:complexType>
>>> </xs:schema>
>>>
>>> -----Original Message-----
>>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>>> Sent: Tuesday, September 01, 2009 10:18
>>> To: user@tuscany.apache.org
>>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>>
>>> Hi,
>>>
>>> I just came back from vacation to catch the discussion.
>>>
>>> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class
>>> instead
>>> of conc.StringType.class? It seems that there is information in the
>>> ObjectFactory.class to describe the element substitutionGroup.
>>>
>>> Thanks,
>>> Raymond
>>> --------------------------------------------------
>>> From: "Phillips, Chad" <Ch...@gdit.com>
>>> Sent: Tuesday, September 01, 2009 9:43 AM
>>> To: <us...@tuscany.apache.org>
>>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>>
>>>> The WSDL generated by Tuscany is missing the Identifier element that is
>>>> present in the XSD used on the server side.  Maybe I'm still missing an
>>>> annotation?  Here is the data on the server side before it's returned 
>>>> to
>>>> the client:
>>>>
>>>> <DataType xmlns:ns2="conc" xmlns="abs">
>>>>    <ns2:Identifier>FOO</ns2:Identifier>
>>>> </DataType>
>>>>
>>>> And here is what the client receives:
>>>>
>>>> <DataType xmlns="abs">
>>>>    <IdentifierAbstract xsi:nil="true"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>>> </DataType>
>>>>
>>>> Some of the clients that will be using the WS are not under my control
>>>> so
>>>> they'll most likely not being using Tuscany to access the service (I
>>>> believe most are using JAX-WS or Axis2).
>>>>
>>>> -----Original Message-----
>>>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>>>> Sent: Tuesday, September 01, 2009 09:07
>>>> To: user@tuscany.apache.org
>>>> Subject: Re: Issue using JAXB generated classes in SCA remotable 
>>>> service
>>>>
>>>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>>>> wrote:
>>>>> Anyone get a chance to look at this yet?  It's a pretty major issue 
>>>>> for
>>>>> my project as we can't return data in the required format.
>>>>
>>>> Chad, I'm not sure I'm totally following every step here... not sure
>>>> what you mean by "...WSDL is not being generated correctly".  I
>>>> haven't actually run your app.
>>>>
>>>> But would you say that the service-side is sending back the correct
>>>> XML, and you are having some problem on the client side?
>>>>
>>>> If so, I wonder if it would be useful to try using a Tuscany client w/
>>>> a reference with <binding.ws>?
>>>>
>>>> Scott
>>>
>>

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
That schema that's using the xlink attributes is importing the xlink XSD.  However, the xlink XSD only contains attributes and attributeGroups so XJC doesn't generate any classes from that schema (I assume that's expected).  I attached an updated test program to TUSCANY-3238 which reproduces the problem; it includes the xlinks XSD used as well as a WSDL that generates the same errors.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Friday, September 04, 2009 09:33
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

It seems that JAXB Java to XSD generation expands things such as 
attributeGroup or substitutionGroup. For example,

<xs:attributeGroup ref="xlink:locatorLink"/>

becomes:

>                                    <xs:attribute ref="ns3:type" 
> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns4:href" 
> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns5:role" 
> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns6:title" 
> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns7:label" 
> xmlns:ns7="http://www.w3.org/1999/xlink"/>

IMO, this is OK. The namespaces are correctly declared. Now it's a matter of 
how the xlink schema is referenced. Do you have xsd:import in your original 
schema to point to the xlink XSD? Do you have the generated JAXB classes for 
the xlink XSD?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Thursday, September 03, 2009 6:14 PM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> Hi Raymond,
>
> I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch 
> (r810694) but, wsimport is bombing out on the generated WSDL for my 
> application's service.  I'm still trying to isolate the problem and add it 
> to the test program but, for now, here is some info on the problem.
>
> The original schema has this type:
>
> <xs:complexType name="RType">
> <xs:sequence>
> <xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="SomeBaseType">
> <xs:sequence>
> <xs:element name="link" maxOccurs="unbounded">
> <xs:complexType>
> <xs:attributeGroup ref="xlink:locatorLink"/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> <xs:attribute name="a" type="xs:anyURI" use="required" />
> <!-- various attributes -->
> </xs:complexType>
>
> In the generated WSDL, the type definition looks like this:
>
> <xs:complexType name="RType">
>    <xs:sequence>
>        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
>            <xs:complexType>
>                <xs:complexContent>
>                    <xs:extension base="tns:SomeBaseType">
>                        <xs:sequence>
>                            <xs:element maxOccurs="unbounded" name="link">
>                                <xs:complexType>
>                                    <xs:sequence/>
>                                    <xs:attribute ref="ns3:type" 
> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns4:href" 
> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns5:role" 
> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns6:title" 
> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns7:label" 
> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>                                </xs:complexType>
>                            </xs:element>
>                        </xs:sequence>
>                    </xs:extension>
>                </xs:complexContent>
>            </xs:complexType>
>        </xs:element>
>    </xs:sequence>
>    <xs:attribute ref="tns:a" use="required"/>
>    <!-- various attributes-->
> </xs:complexType>
>
> Here are the errors I'm getting:
>
> [ERROR] undefined attribute 'ns3:type'
> [ERROR] undefined attribute 'ns4:href'
> [ERROR] undefined attribute 'ns5:role'
> [ERROR] undefined attribute 'ns6:title'
> [ERROR] undefined attribute 'ns7:label'
>
> And there are some warnings for that type that may (or may not) be related 
> to the issue:
>
> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is 
> invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.
>
> [wsimport] [WARNING] src-resolve.4.2: Error resolving component 
> 'ns3:type'. It was detected that 'ns3:type' is in namespace 
> 'http://www.w3.org/1999/xlink', but components from this namespace are not 
> referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If 
> this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs to 
> be changed. If this is the correct namespace, then an appropriate 'import' 
> tag should be added to 'file:/C:/test.wsdl#types?schema9'.
>
> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 
> '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid, 
> misplaced, or occurs too often.
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Tuesday, September 01, 2009 16:36
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> Hi,
>
> Hmm, it seems to be an issue in JAXB. Now the only option is to add
> @XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying 
> it
> with the 2.x stream:
>
> @Remotable
> @XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
> public interface TestService {
>
>    public DataType getData();
>
> }
>
> After fixing the j2w codegen, it produces the following wsdl. Can you try
> this WSDL to see if it works? Meanwhile, I'll try to port the fix into 1.x
> after more tests.
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <wsdl:definitions name="TestServiceService"
> targetNamespace="http://server.test/" xmlns:tns="http://server.test/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
>  <wsdl:types>
>    <xs:schema elementFormDefault="qualified" targetNamespace="abs"
> version="1.0" xmlns:ns1="conc" xmlns:tns="abs"
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:import namespace="conc"/>
> <xs:element name="IdentifierAbstract" type="xs:anyType"/>
> <xs:complexType name="DataType"><xs:choice><xs:element
> ref="tns:IdentifierAbstract"/><xs:element
> ref="ns1:Identifier"/></xs:choice></xs:complexType>
> </xs:schema>
>    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs"
> xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:import namespace="abs"/>
> <xs:element name="Identifier" type="tns:StringType"/>
> <xs:element name="TestData" type="ns1:DataType"/>
> <xs:simpleType name="StringType"><xs:restriction
> base="xs:string"/></xs:simpleType>
> </xs:schema>
>    <xs:schema attributeFormDefault="qualified"
> elementFormDefault="unqualified" targetNamespace="http://server.test/"
> xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import
> namespace="abs"/><xs:element
> name="getDataResponse"><xs:complexType><xs:sequence><xs:element
> minOccurs="0" name="return" nillable="true"
> type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element
> name="getData"><xs:complexType/></xs:element></xs:schema>
>  </wsdl:types>
>  <wsdl:message name="getDataResponse">
>    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
>    </wsdl:part>
>  </wsdl:message>
>  <wsdl:message name="getData">
>    <wsdl:part name="getData" element="tns:getData">
>    </wsdl:part>
>  </wsdl:message>
>  <wsdl:portType name="TestService">
>    <wsdl:operation name="getData">
>      <wsdl:input message="tns:getData">
>    </wsdl:input>
>      <wsdl:output message="tns:getDataResponse">
>    </wsdl:output>
>    </wsdl:operation>
>  </wsdl:portType>
>  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
>    <SOAP:binding style="document"
> transport="http://schemas.xmlsoap.org/soap/http"/>
>    <wsdl:operation name="getData">
>      <SOAP:operation/>
>      <wsdl:input>
>        <SOAP:body use="literal"/>
>      </wsdl:input>
>      <wsdl:output>
>        <SOAP:body use="literal"/>
>      </wsdl:output>
>    </wsdl:operation>
>  </wsdl:binding>
>  <wsdl:service name="TestServiceService">
>    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
>      <SOAP:address
> location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
>    </wsdl:port>
>  </wsdl:service>
> </wsdl:definitions>
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Tuesday, September 01, 2009 10:53 AM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> Adding ObjectFactory to that annotation has the effect of creating a
>> complex type objectFactory in the WSDL:
>>
>> <xs:schema targetNamespace="conc" version="1.0">
>> <xs:complexType name="objectFactory">
>> <xs:sequence/>
>> </xs:complexType>
>> </xs:schema>
>>
>> -----Original Message-----
>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>> Sent: Tuesday, September 01, 2009 10:18
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> Hi,
>>
>> I just came back from vacation to catch the discussion.
>>
>> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class 
>> instead
>> of conc.StringType.class? It seems that there is information in the
>> ObjectFactory.class to describe the element substitutionGroup.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Phillips, Chad" <Ch...@gdit.com>
>> Sent: Tuesday, September 01, 2009 9:43 AM
>> To: <us...@tuscany.apache.org>
>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>
>>> The WSDL generated by Tuscany is missing the Identifier element that is
>>> present in the XSD used on the server side.  Maybe I'm still missing an
>>> annotation?  Here is the data on the server side before it's returned to
>>> the client:
>>>
>>> <DataType xmlns:ns2="conc" xmlns="abs">
>>>    <ns2:Identifier>FOO</ns2:Identifier>
>>> </DataType>
>>>
>>> And here is what the client receives:
>>>
>>> <DataType xmlns="abs">
>>>    <IdentifierAbstract xsi:nil="true"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>> </DataType>
>>>
>>> Some of the clients that will be using the WS are not under my control 
>>> so
>>> they'll most likely not being using Tuscany to access the service (I
>>> believe most are using JAX-WS or Axis2).
>>>
>>> -----Original Message-----
>>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>>> Sent: Tuesday, September 01, 2009 09:07
>>> To: user@tuscany.apache.org
>>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>>
>>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>>> wrote:
>>>> Anyone get a chance to look at this yet?  It's a pretty major issue for
>>>> my project as we can't return data in the required format.
>>>
>>> Chad, I'm not sure I'm totally following every step here... not sure
>>> what you mean by "...WSDL is not being generated correctly".  I
>>> haven't actually run your app.
>>>
>>> But would you say that the service-side is sending back the correct
>>> XML, and you are having some problem on the client side?
>>>
>>> If so, I wonder if it would be useful to try using a Tuscany client w/
>>> a reference with <binding.ws>?
>>>
>>> Scott
>>
>

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Raymond Feng <en...@gmail.com>.
It seems that JAXB Java to XSD generation expands things such as 
attributeGroup or substitutionGroup. For example,

<xs:attributeGroup ref="xlink:locatorLink"/>

becomes:

>                                    <xs:attribute ref="ns3:type" 
> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns4:href" 
> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns5:role" 
> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns6:title" 
> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns7:label" 
> xmlns:ns7="http://www.w3.org/1999/xlink"/>

IMO, this is OK. The namespaces are correctly declared. Now it's a matter of 
how the xlink schema is referenced. Do you have xsd:import in your original 
schema to point to the xlink XSD? Do you have the generated JAXB classes for 
the xlink XSD?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Thursday, September 03, 2009 6:14 PM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> Hi Raymond,
>
> I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch 
> (r810694) but, wsimport is bombing out on the generated WSDL for my 
> application's service.  I'm still trying to isolate the problem and add it 
> to the test program but, for now, here is some info on the problem.
>
> The original schema has this type:
>
> <xs:complexType name="RType">
> <xs:sequence>
> <xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="SomeBaseType">
> <xs:sequence>
> <xs:element name="link" maxOccurs="unbounded">
> <xs:complexType>
> <xs:attributeGroup ref="xlink:locatorLink"/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> <xs:attribute name="a" type="xs:anyURI" use="required" />
> <!-- various attributes -->
> </xs:complexType>
>
> In the generated WSDL, the type definition looks like this:
>
> <xs:complexType name="RType">
>    <xs:sequence>
>        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
>            <xs:complexType>
>                <xs:complexContent>
>                    <xs:extension base="tns:SomeBaseType">
>                        <xs:sequence>
>                            <xs:element maxOccurs="unbounded" name="link">
>                                <xs:complexType>
>                                    <xs:sequence/>
>                                    <xs:attribute ref="ns3:type" 
> xmlns:ns3="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns4:href" 
> use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns5:role" 
> xmlns:ns5="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns6:title" 
> xmlns:ns6="http://www.w3.org/1999/xlink"/>
>                                    <xs:attribute ref="ns7:label" 
> xmlns:ns7="http://www.w3.org/1999/xlink"/>
>                                </xs:complexType>
>                            </xs:element>
>                        </xs:sequence>
>                    </xs:extension>
>                </xs:complexContent>
>            </xs:complexType>
>        </xs:element>
>    </xs:sequence>
>    <xs:attribute ref="tns:a" use="required"/>
>    <!-- various attributes-->
> </xs:complexType>
>
> Here are the errors I'm getting:
>
> [ERROR] undefined attribute 'ns3:type'
> [ERROR] undefined attribute 'ns4:href'
> [ERROR] undefined attribute 'ns5:role'
> [ERROR] undefined attribute 'ns6:title'
> [ERROR] undefined attribute 'ns7:label'
>
> And there are some warnings for that type that may (or may not) be related 
> to the issue:
>
> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is 
> invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.
>
> [wsimport] [WARNING] src-resolve.4.2: Error resolving component 
> 'ns3:type'. It was detected that 'ns3:type' is in namespace 
> 'http://www.w3.org/1999/xlink', but components from this namespace are not 
> referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If 
> this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs to 
> be changed. If this is the correct namespace, then an appropriate 'import' 
> tag should be added to 'file:/C:/test.wsdl#types?schema9'.
>
> [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 
> '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid, 
> misplaced, or occurs too often.
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Tuesday, September 01, 2009 16:36
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> Hi,
>
> Hmm, it seems to be an issue in JAXB. Now the only option is to add
> @XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying 
> it
> with the 2.x stream:
>
> @Remotable
> @XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
> public interface TestService {
>
>    public DataType getData();
>
> }
>
> After fixing the j2w codegen, it produces the following wsdl. Can you try
> this WSDL to see if it works? Meanwhile, I'll try to port the fix into 1.x
> after more tests.
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <wsdl:definitions name="TestServiceService"
> targetNamespace="http://server.test/" xmlns:tns="http://server.test/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
>  <wsdl:types>
>    <xs:schema elementFormDefault="qualified" targetNamespace="abs"
> version="1.0" xmlns:ns1="conc" xmlns:tns="abs"
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:import namespace="conc"/>
> <xs:element name="IdentifierAbstract" type="xs:anyType"/>
> <xs:complexType name="DataType"><xs:choice><xs:element
> ref="tns:IdentifierAbstract"/><xs:element
> ref="ns1:Identifier"/></xs:choice></xs:complexType>
> </xs:schema>
>    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs"
> xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:import namespace="abs"/>
> <xs:element name="Identifier" type="tns:StringType"/>
> <xs:element name="TestData" type="ns1:DataType"/>
> <xs:simpleType name="StringType"><xs:restriction
> base="xs:string"/></xs:simpleType>
> </xs:schema>
>    <xs:schema attributeFormDefault="qualified"
> elementFormDefault="unqualified" targetNamespace="http://server.test/"
> xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import
> namespace="abs"/><xs:element
> name="getDataResponse"><xs:complexType><xs:sequence><xs:element
> minOccurs="0" name="return" nillable="true"
> type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element
> name="getData"><xs:complexType/></xs:element></xs:schema>
>  </wsdl:types>
>  <wsdl:message name="getDataResponse">
>    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
>    </wsdl:part>
>  </wsdl:message>
>  <wsdl:message name="getData">
>    <wsdl:part name="getData" element="tns:getData">
>    </wsdl:part>
>  </wsdl:message>
>  <wsdl:portType name="TestService">
>    <wsdl:operation name="getData">
>      <wsdl:input message="tns:getData">
>    </wsdl:input>
>      <wsdl:output message="tns:getDataResponse">
>    </wsdl:output>
>    </wsdl:operation>
>  </wsdl:portType>
>  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
>    <SOAP:binding style="document"
> transport="http://schemas.xmlsoap.org/soap/http"/>
>    <wsdl:operation name="getData">
>      <SOAP:operation/>
>      <wsdl:input>
>        <SOAP:body use="literal"/>
>      </wsdl:input>
>      <wsdl:output>
>        <SOAP:body use="literal"/>
>      </wsdl:output>
>    </wsdl:operation>
>  </wsdl:binding>
>  <wsdl:service name="TestServiceService">
>    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
>      <SOAP:address
> location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
>    </wsdl:port>
>  </wsdl:service>
> </wsdl:definitions>
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Tuesday, September 01, 2009 10:53 AM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> Adding ObjectFactory to that annotation has the effect of creating a
>> complex type objectFactory in the WSDL:
>>
>> <xs:schema targetNamespace="conc" version="1.0">
>> <xs:complexType name="objectFactory">
>> <xs:sequence/>
>> </xs:complexType>
>> </xs:schema>
>>
>> -----Original Message-----
>> From: Raymond Feng [mailto:enjoyjava@gmail.com]
>> Sent: Tuesday, September 01, 2009 10:18
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> Hi,
>>
>> I just came back from vacation to catch the discussion.
>>
>> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class 
>> instead
>> of conc.StringType.class? It seems that there is information in the
>> ObjectFactory.class to describe the element substitutionGroup.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Phillips, Chad" <Ch...@gdit.com>
>> Sent: Tuesday, September 01, 2009 9:43 AM
>> To: <us...@tuscany.apache.org>
>> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>>
>>> The WSDL generated by Tuscany is missing the Identifier element that is
>>> present in the XSD used on the server side.  Maybe I'm still missing an
>>> annotation?  Here is the data on the server side before it's returned to
>>> the client:
>>>
>>> <DataType xmlns:ns2="conc" xmlns="abs">
>>>    <ns2:Identifier>FOO</ns2:Identifier>
>>> </DataType>
>>>
>>> And here is what the client receives:
>>>
>>> <DataType xmlns="abs">
>>>    <IdentifierAbstract xsi:nil="true"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>> </DataType>
>>>
>>> Some of the clients that will be using the WS are not under my control 
>>> so
>>> they'll most likely not being using Tuscany to access the service (I
>>> believe most are using JAX-WS or Axis2).
>>>
>>> -----Original Message-----
>>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>>> Sent: Tuesday, September 01, 2009 09:07
>>> To: user@tuscany.apache.org
>>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>>
>>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>>> wrote:
>>>> Anyone get a chance to look at this yet?  It's a pretty major issue for
>>>> my project as we can't return data in the required format.
>>>
>>> Chad, I'm not sure I'm totally following every step here... not sure
>>> what you mean by "...WSDL is not being generated correctly".  I
>>> haven't actually run your app.
>>>
>>> But would you say that the service-side is sending back the correct
>>> XML, and you are having some problem on the client side?
>>>
>>> If so, I wonder if it would be useful to try using a Tuscany client w/
>>> a reference with <binding.ws>?
>>>
>>> Scott
>>
>

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Hi Raymond,

I'm working w/ the fix for TUSCANY-3238 that you put on the 1.5.1 branch (r810694) but, wsimport is bombing out on the generated WSDL for my application's service.  I'm still trying to isolate the problem and add it to the test program but, for now, here is some info on the problem.

The original schema has this type:

	<xs:complexType name="RType">
		<xs:sequence>
			<xs:element name="RR" minOccurs="0" maxOccurs="unbounded">
				<xs:complexType>
					<xs:complexContent>
						<xs:extension base="SomeBaseType">
							<xs:sequence>
								<xs:element name="link" maxOccurs="unbounded">
									<xs:complexType>
										<xs:attributeGroup ref="xlink:locatorLink"/>
									</xs:complexType>
								</xs:element>
							</xs:sequence>
						</xs:extension>
					</xs:complexContent>
				</xs:complexType>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="a" type="xs:anyURI" use="required" />
		<!-- various attributes -->
	</xs:complexType>

In the generated WSDL, the type definition looks like this:

<xs:complexType name="RType">
    <xs:sequence>
        <xs:element maxOccurs="unbounded" minOccurs="0" name="RR">
            <xs:complexType>
                <xs:complexContent>
                    <xs:extension base="tns:SomeBaseType">
                        <xs:sequence>
                            <xs:element maxOccurs="unbounded" name="link">
                                <xs:complexType>
                                    <xs:sequence/>
                                    <xs:attribute ref="ns3:type" xmlns:ns3="http://www.w3.org/1999/xlink"/>
                                    <xs:attribute ref="ns4:href" use="required" xmlns:ns4="http://www.w3.org/1999/xlink"/>
                                    <xs:attribute ref="ns5:role" xmlns:ns5="http://www.w3.org/1999/xlink"/>
                                    <xs:attribute ref="ns6:title" xmlns:ns6="http://www.w3.org/1999/xlink"/>
                                    <xs:attribute ref="ns7:label" xmlns:ns7="http://www.w3.org/1999/xlink"/>
                                </xs:complexType>
                            </xs:element>
                        </xs:sequence>
                    </xs:extension>
                </xs:complexContent>
            </xs:complexType>
        </xs:element>
    </xs:sequence>
    <xs:attribute ref="tns:a" use="required"/>
    <!-- various attributes-->
</xs:complexType>

Here are the errors I'm getting:

 [ERROR] undefined attribute 'ns3:type'
 [ERROR] undefined attribute 'ns4:href'
 [ERROR] undefined attribute 'ns5:role'
 [ERROR] undefined attribute 'ns6:title'
 [ERROR] undefined attribute 'ns7:label'

And there are some warnings for that type that may (or may not) be related to the issue:

 [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of 'RType' is invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.

 [wsimport] [WARNING] src-resolve.4.2: Error resolving component 'ns3:type'. It was detected that 'ns3:type' is in namespace 'http://www.w3.org/1999/xlink', but components from this namespace are not referenceable from schema document 'file:/C:/test.wsdl#types?schema9'. If this is the incorrect namespace, perhaps the prefix of 'ns3:type' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:/C:/test.wsdl#types?schema9'.

 [wsimport] [WARNING] s4s-elt-invalid-content.1: The content of '#AnonType_linkRRRType' is invalid.  Element 'attribute' is invalid, misplaced, or occurs too often.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, September 01, 2009 16:36
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Hi,

Hmm, it seems to be an issue in JAXB. Now the only option is to add 
@XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying it 
with the 2.x stream:

@Remotable
@XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
public interface TestService {

    public DataType getData();

}

After fixing the j2w codegen, it produces the following wsdl. Can you try 
this WSDL to see if it works? Meanwhile, I'll try to port the fix into 1.x 
after more tests.


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="TestServiceService" 
targetNamespace="http://server.test/" xmlns:tns="http://server.test/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
  <wsdl:types>
    <xs:schema elementFormDefault="qualified" targetNamespace="abs" 
version="1.0" xmlns:ns1="conc" xmlns:tns="abs" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="conc"/>
<xs:element name="IdentifierAbstract" type="xs:anyType"/>
<xs:complexType name="DataType"><xs:choice><xs:element 
ref="tns:IdentifierAbstract"/><xs:element 
ref="ns1:Identifier"/></xs:choice></xs:complexType>
</xs:schema>
    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs" 
xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="abs"/>
<xs:element name="Identifier" type="tns:StringType"/>
<xs:element name="TestData" type="ns1:DataType"/>
<xs:simpleType name="StringType"><xs:restriction 
base="xs:string"/></xs:simpleType>
</xs:schema>
    <xs:schema attributeFormDefault="qualified" 
elementFormDefault="unqualified" targetNamespace="http://server.test/" 
xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import 
namespace="abs"/><xs:element 
name="getDataResponse"><xs:complexType><xs:sequence><xs:element 
minOccurs="0" name="return" nillable="true" 
type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element 
name="getData"><xs:complexType/></xs:element></xs:schema>
  </wsdl:types>
  <wsdl:message name="getDataResponse">
    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
    </wsdl:part>
  </wsdl:message>
  <wsdl:message name="getData">
    <wsdl:part name="getData" element="tns:getData">
    </wsdl:part>
  </wsdl:message>
  <wsdl:portType name="TestService">
    <wsdl:operation name="getData">
      <wsdl:input message="tns:getData">
    </wsdl:input>
      <wsdl:output message="tns:getDataResponse">
    </wsdl:output>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
    <SOAP:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="getData">
      <SOAP:operation/>
      <wsdl:input>
        <SOAP:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <SOAP:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="TestServiceService">
    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
      <SOAP:address 
location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, September 01, 2009 10:53 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> Adding ObjectFactory to that annotation has the effect of creating a 
> complex type objectFactory in the WSDL:
>
> <xs:schema targetNamespace="conc" version="1.0">
> <xs:complexType name="objectFactory">
> <xs:sequence/>
> </xs:complexType>
> </xs:schema>
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Tuesday, September 01, 2009 10:18
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> Hi,
>
> I just came back from vacation to catch the discussion.
>
> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class instead
> of conc.StringType.class? It seems that there is information in the
> ObjectFactory.class to describe the element substitutionGroup.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Tuesday, September 01, 2009 9:43 AM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> The WSDL generated by Tuscany is missing the Identifier element that is
>> present in the XSD used on the server side.  Maybe I'm still missing an
>> annotation?  Here is the data on the server side before it's returned to
>> the client:
>>
>> <DataType xmlns:ns2="conc" xmlns="abs">
>>    <ns2:Identifier>FOO</ns2:Identifier>
>> </DataType>
>>
>> And here is what the client receives:
>>
>> <DataType xmlns="abs">
>>    <IdentifierAbstract xsi:nil="true"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>> </DataType>
>>
>> Some of the clients that will be using the WS are not under my control so
>> they'll most likely not being using Tuscany to access the service (I
>> believe most are using JAX-WS or Axis2).
>>
>> -----Original Message-----
>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>> Sent: Tuesday, September 01, 2009 09:07
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>> wrote:
>>> Anyone get a chance to look at this yet?  It's a pretty major issue for
>>> my project as we can't return data in the required format.
>>
>> Chad, I'm not sure I'm totally following every step here... not sure
>> what you mean by "...WSDL is not being generated correctly".  I
>> haven't actually run your app.
>>
>> But would you say that the service-side is sending back the correct
>> XML, and you are having some problem on the client side?
>>
>> If so, I wonder if it would be useful to try using a Tuscany client w/
>> a reference with <binding.ws>?
>>
>> Scott
>

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Using that WSDL I see the same data on the server and client sides.  Thanks for the all the help guys.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, September 01, 2009 16:36
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Hi,

Hmm, it seems to be an issue in JAXB. Now the only option is to add 
@XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying it 
with the 2.x stream:

@Remotable
@XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
public interface TestService {

    public DataType getData();

}

After fixing the j2w codegen, it produces the following wsdl. Can you try 
this WSDL to see if it works? Meanwhile, I'll try to port the fix into 1.x 
after more tests.


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="TestServiceService" 
targetNamespace="http://server.test/" xmlns:tns="http://server.test/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
  <wsdl:types>
    <xs:schema elementFormDefault="qualified" targetNamespace="abs" 
version="1.0" xmlns:ns1="conc" xmlns:tns="abs" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="conc"/>
<xs:element name="IdentifierAbstract" type="xs:anyType"/>
<xs:complexType name="DataType"><xs:choice><xs:element 
ref="tns:IdentifierAbstract"/><xs:element 
ref="ns1:Identifier"/></xs:choice></xs:complexType>
</xs:schema>
    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs" 
xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="abs"/>
<xs:element name="Identifier" type="tns:StringType"/>
<xs:element name="TestData" type="ns1:DataType"/>
<xs:simpleType name="StringType"><xs:restriction 
base="xs:string"/></xs:simpleType>
</xs:schema>
    <xs:schema attributeFormDefault="qualified" 
elementFormDefault="unqualified" targetNamespace="http://server.test/" 
xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import 
namespace="abs"/><xs:element 
name="getDataResponse"><xs:complexType><xs:sequence><xs:element 
minOccurs="0" name="return" nillable="true" 
type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element 
name="getData"><xs:complexType/></xs:element></xs:schema>
  </wsdl:types>
  <wsdl:message name="getDataResponse">
    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
    </wsdl:part>
  </wsdl:message>
  <wsdl:message name="getData">
    <wsdl:part name="getData" element="tns:getData">
    </wsdl:part>
  </wsdl:message>
  <wsdl:portType name="TestService">
    <wsdl:operation name="getData">
      <wsdl:input message="tns:getData">
    </wsdl:input>
      <wsdl:output message="tns:getDataResponse">
    </wsdl:output>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
    <SOAP:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="getData">
      <SOAP:operation/>
      <wsdl:input>
        <SOAP:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <SOAP:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="TestServiceService">
    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
      <SOAP:address 
location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, September 01, 2009 10:53 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> Adding ObjectFactory to that annotation has the effect of creating a 
> complex type objectFactory in the WSDL:
>
> <xs:schema targetNamespace="conc" version="1.0">
> <xs:complexType name="objectFactory">
> <xs:sequence/>
> </xs:complexType>
> </xs:schema>
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Tuesday, September 01, 2009 10:18
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> Hi,
>
> I just came back from vacation to catch the discussion.
>
> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class instead
> of conc.StringType.class? It seems that there is information in the
> ObjectFactory.class to describe the element substitutionGroup.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Tuesday, September 01, 2009 9:43 AM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> The WSDL generated by Tuscany is missing the Identifier element that is
>> present in the XSD used on the server side.  Maybe I'm still missing an
>> annotation?  Here is the data on the server side before it's returned to
>> the client:
>>
>> <DataType xmlns:ns2="conc" xmlns="abs">
>>    <ns2:Identifier>FOO</ns2:Identifier>
>> </DataType>
>>
>> And here is what the client receives:
>>
>> <DataType xmlns="abs">
>>    <IdentifierAbstract xsi:nil="true"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>> </DataType>
>>
>> Some of the clients that will be using the WS are not under my control so
>> they'll most likely not being using Tuscany to access the service (I
>> believe most are using JAX-WS or Axis2).
>>
>> -----Original Message-----
>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>> Sent: Tuesday, September 01, 2009 09:07
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>> wrote:
>>> Anyone get a chance to look at this yet?  It's a pretty major issue for
>>> my project as we can't return data in the required format.
>>
>> Chad, I'm not sure I'm totally following every step here... not sure
>> what you mean by "...WSDL is not being generated correctly".  I
>> haven't actually run your app.
>>
>> But would you say that the service-side is sending back the correct
>> XML, and you are having some problem on the client side?
>>
>> If so, I wonder if it would be useful to try using a Tuscany client w/
>> a reference with <binding.ws>?
>>
>> Scott
>

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Raymond Feng <en...@gmail.com>.
Hi,

Hmm, it seems to be an issue in JAXB. Now the only option is to add 
@XmlSeeAlso support for the interface as JAX-WS wsimport does. I'm trying it 
with the 2.x stream:

@Remotable
@XmlSeeAlso({abs.ObjectFactory.class, conc.ObjectFactory.class})
public interface TestService {

    public DataType getData();

}

After fixing the j2w codegen, it produces the following wsdl. Can you try 
this WSDL to see if it works? Meanwhile, I'll try to port the fix into 1.x 
after more tests.


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="TestServiceService" 
targetNamespace="http://server.test/" xmlns:tns="http://server.test/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
  <wsdl:types>
    <xs:schema elementFormDefault="qualified" targetNamespace="abs" 
version="1.0" xmlns:ns1="conc" xmlns:tns="abs" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="conc"/>
<xs:element name="IdentifierAbstract" type="xs:anyType"/>
<xs:complexType name="DataType"><xs:choice><xs:element 
ref="tns:IdentifierAbstract"/><xs:element 
ref="ns1:Identifier"/></xs:choice></xs:complexType>
</xs:schema>
    <xs:schema targetNamespace="conc" version="1.0" xmlns:ns1="abs" 
xmlns:tns="conc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="abs"/>
<xs:element name="Identifier" type="tns:StringType"/>
<xs:element name="TestData" type="ns1:DataType"/>
<xs:simpleType name="StringType"><xs:restriction 
base="xs:string"/></xs:simpleType>
</xs:schema>
    <xs:schema attributeFormDefault="qualified" 
elementFormDefault="unqualified" targetNamespace="http://server.test/" 
xmlns:ns0="abs" xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:import 
namespace="abs"/><xs:element 
name="getDataResponse"><xs:complexType><xs:sequence><xs:element 
minOccurs="0" name="return" nillable="true" 
type="ns0:DataType"/></xs:sequence></xs:complexType></xs:element><xs:element 
name="getData"><xs:complexType/></xs:element></xs:schema>
  </wsdl:types>
  <wsdl:message name="getDataResponse">
    <wsdl:part name="getDataResponse" element="tns:getDataResponse">
    </wsdl:part>
  </wsdl:message>
  <wsdl:message name="getData">
    <wsdl:part name="getData" element="tns:getData">
    </wsdl:part>
  </wsdl:message>
  <wsdl:portType name="TestService">
    <wsdl:operation name="getData">
      <wsdl:input message="tns:getData">
    </wsdl:input>
      <wsdl:output message="tns:getDataResponse">
    </wsdl:output>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="TestServiceBinding" type="tns:TestService">
    <SOAP:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="getData">
      <SOAP:operation/>
      <wsdl:input>
        <SOAP:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <SOAP:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="TestServiceService">
    <wsdl:port name="TestServicePort" binding="tns:TestServiceBinding">
      <SOAP:address 
location="http://192.168.1.102:8080/TestServiceComponent/TestService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, September 01, 2009 10:53 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> Adding ObjectFactory to that annotation has the effect of creating a 
> complex type objectFactory in the WSDL:
>
> <xs:schema targetNamespace="conc" version="1.0">
> <xs:complexType name="objectFactory">
> <xs:sequence/>
> </xs:complexType>
> </xs:schema>
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Tuesday, September 01, 2009 10:18
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> Hi,
>
> I just came back from vacation to catch the discussion.
>
> Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class instead
> of conc.StringType.class? It seems that there is information in the
> ObjectFactory.class to describe the element substitutionGroup.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Phillips, Chad" <Ch...@gdit.com>
> Sent: Tuesday, September 01, 2009 9:43 AM
> To: <us...@tuscany.apache.org>
> Subject: RE: Issue using JAXB generated classes in SCA remotable service
>
>> The WSDL generated by Tuscany is missing the Identifier element that is
>> present in the XSD used on the server side.  Maybe I'm still missing an
>> annotation?  Here is the data on the server side before it's returned to
>> the client:
>>
>> <DataType xmlns:ns2="conc" xmlns="abs">
>>    <ns2:Identifier>FOO</ns2:Identifier>
>> </DataType>
>>
>> And here is what the client receives:
>>
>> <DataType xmlns="abs">
>>    <IdentifierAbstract xsi:nil="true"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>> </DataType>
>>
>> Some of the clients that will be using the WS are not under my control so
>> they'll most likely not being using Tuscany to access the service (I
>> believe most are using JAX-WS or Axis2).
>>
>> -----Original Message-----
>> From: Scott Kurz [mailto:scottkurz@gmail.com]
>> Sent: Tuesday, September 01, 2009 09:07
>> To: user@tuscany.apache.org
>> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>>
>> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com>
>> wrote:
>>> Anyone get a chance to look at this yet?  It's a pretty major issue for
>>> my project as we can't return data in the required format.
>>
>> Chad, I'm not sure I'm totally following every step here... not sure
>> what you mean by "...WSDL is not being generated correctly".  I
>> haven't actually run your app.
>>
>> But would you say that the service-side is sending back the correct
>> XML, and you are having some problem on the client side?
>>
>> If so, I wonder if it would be useful to try using a Tuscany client w/
>> a reference with <binding.ws>?
>>
>> Scott
>

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Adding ObjectFactory to that annotation has the effect of creating a complex type objectFactory in the WSDL:

<xs:schema targetNamespace="conc" version="1.0">
	<xs:complexType name="objectFactory">
		<xs:sequence/>
	</xs:complexType>
</xs:schema>

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, September 01, 2009 10:18
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Hi,

I just came back from vacation to catch the discussion.

Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class instead 
of conc.StringType.class? It seems that there is information in the 
ObjectFactory.class to describe the element substitutionGroup.

Thanks,
Raymond
--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, September 01, 2009 9:43 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> The WSDL generated by Tuscany is missing the Identifier element that is 
> present in the XSD used on the server side.  Maybe I'm still missing an 
> annotation?  Here is the data on the server side before it's returned to 
> the client:
>
> <DataType xmlns:ns2="conc" xmlns="abs">
>    <ns2:Identifier>FOO</ns2:Identifier>
> </DataType>
>
> And here is what the client receives:
>
> <DataType xmlns="abs">
>    <IdentifierAbstract xsi:nil="true" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> </DataType>
>
> Some of the clients that will be using the WS are not under my control so 
> they'll most likely not being using Tuscany to access the service (I 
> believe most are using JAX-WS or Axis2).
>
> -----Original Message-----
> From: Scott Kurz [mailto:scottkurz@gmail.com]
> Sent: Tuesday, September 01, 2009 09:07
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com> 
> wrote:
>> Anyone get a chance to look at this yet?  It's a pretty major issue for 
>> my project as we can't return data in the required format.
>
> Chad, I'm not sure I'm totally following every step here... not sure
> what you mean by "...WSDL is not being generated correctly".  I
> haven't actually run your app.
>
> But would you say that the service-side is sending back the correct
> XML, and you are having some problem on the client side?
>
> If so, I wonder if it would be useful to try using a Tuscany client w/
> a reference with <binding.ws>?
>
> Scott

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Raymond Feng <en...@gmail.com>.
Hi,

I just came back from vacation to catch the discussion.

Can you try to use @XmlSeeAlso to add the conc.ObjectFactory.class instead 
of conc.StringType.class? It seems that there is information in the 
ObjectFactory.class to describe the element substitutionGroup.

Thanks,
Raymond
--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, September 01, 2009 9:43 AM
To: <us...@tuscany.apache.org>
Subject: RE: Issue using JAXB generated classes in SCA remotable service

> The WSDL generated by Tuscany is missing the Identifier element that is 
> present in the XSD used on the server side.  Maybe I'm still missing an 
> annotation?  Here is the data on the server side before it's returned to 
> the client:
>
> <DataType xmlns:ns2="conc" xmlns="abs">
>    <ns2:Identifier>FOO</ns2:Identifier>
> </DataType>
>
> And here is what the client receives:
>
> <DataType xmlns="abs">
>    <IdentifierAbstract xsi:nil="true" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> </DataType>
>
> Some of the clients that will be using the WS are not under my control so 
> they'll most likely not being using Tuscany to access the service (I 
> believe most are using JAX-WS or Axis2).
>
> -----Original Message-----
> From: Scott Kurz [mailto:scottkurz@gmail.com]
> Sent: Tuesday, September 01, 2009 09:07
> To: user@tuscany.apache.org
> Subject: Re: Issue using JAXB generated classes in SCA remotable service
>
> On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com> 
> wrote:
>> Anyone get a chance to look at this yet?  It's a pretty major issue for 
>> my project as we can't return data in the required format.
>
> Chad, I'm not sure I'm totally following every step here... not sure
> what you mean by "...WSDL is not being generated correctly".  I
> haven't actually run your app.
>
> But would you say that the service-side is sending back the correct
> XML, and you are having some problem on the client side?
>
> If so, I wonder if it would be useful to try using a Tuscany client w/
> a reference with <binding.ws>?
>
> Scott

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
The first is the data marshaled to XML in the TestServiceImpl on the server side.

The second is the data returned from the webservice invocation via the JAX-WS client (generated from the WSDL) marshaled to XML on the client side.

-----Original Message-----
From: Scott Kurz [mailto:scottkurz@gmail.com] 
Sent: Tuesday, September 01, 2009 09:51
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Chad,

I'm confused about your two checkpoints:

1) the data on the server side before it's returned to the client:

2) And here is what the client receives:

Could you be more precise about exactly where 1) and 2) are in the
flow?   Are you saying 1) is the printout you do in the service impl
and then 2) is the data on the http wire?   In that case, then 2) is
also the format of the data on the service side after it has been
serialized as a response to go back over binding.ws.

Or is it something else?

Thanks

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Scott Kurz <sc...@gmail.com>.
Chad,

I'm confused about your two checkpoints:

1) the data on the server side before it's returned to the client:

2) And here is what the client receives:

Could you be more precise about exactly where 1) and 2) are in the
flow?   Are you saying 1) is the printout you do in the service impl
and then 2) is the data on the http wire?   In that case, then 2) is
also the format of the data on the service side after it has been
serialized as a response to go back over binding.ws.

Or is it something else?

Thanks

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
The WSDL generated by Tuscany is missing the Identifier element that is present in the XSD used on the server side.  Maybe I'm still missing an annotation?  Here is the data on the server side before it's returned to the client:

<DataType xmlns:ns2="conc" xmlns="abs">
    <ns2:Identifier>FOO</ns2:Identifier>
</DataType>

And here is what the client receives:

<DataType xmlns="abs">
    <IdentifierAbstract xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</DataType>

Some of the clients that will be using the WS are not under my control so they'll most likely not being using Tuscany to access the service (I believe most are using JAX-WS or Axis2).

-----Original Message-----
From: Scott Kurz [mailto:scottkurz@gmail.com] 
Sent: Tuesday, September 01, 2009 09:07
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com> wrote:
> Anyone get a chance to look at this yet?  It's a pretty major issue for my project as we can't return data in the required format.

Chad, I'm not sure I'm totally following every step here... not sure
what you mean by "...WSDL is not being generated correctly".  I
haven't actually run your app.

But would you say that the service-side is sending back the correct
XML, and you are having some problem on the client side?

If so, I wonder if it would be useful to try using a Tuscany client w/
a reference with <binding.ws>?

Scott

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Scott Kurz <sc...@gmail.com>.
On Tue, Sep 1, 2009 at 11:33 AM, Phillips, Chad<Ch...@gdit.com> wrote:
> Anyone get a chance to look at this yet?  It's a pretty major issue for my project as we can't return data in the required format.

Chad, I'm not sure I'm totally following every step here... not sure
what you mean by "...WSDL is not being generated correctly".  I
haven't actually run your app.

But would you say that the service-side is sending back the correct
XML, and you are having some problem on the client side?

If so, I wonder if it would be useful to try using a Tuscany client w/
a reference with <binding.ws>?

Scott

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Anyone get a chance to look at this yet?  It's a pretty major issue for my project as we can't return data in the required format.

-----Original Message-----
From: Phillips, Chad 
Sent: Thursday, August 27, 2009 14:39
To: 'user@tuscany.apache.org'
Subject: RE: Issue using JAXB generated classes in SCA remotable service

Raymond (and anyone else familiar w/ the JAXB and WS bindings),

Can you take a look at the comment trail from Scott and me at [1] to see if there is something else that needs to be done?  We got past the exception but it seems that the WSDL is not being generated correctly or maybe I'm just not using wsimport correctly.

[1] https://issues.apache.org/jira/browse/TUSCANY-3238

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, August 18, 2009 14:38
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Do the generated subclasses extend from base classes? If so, I assume adding 
the subclass into the JAXBContext will automatically add the base classes.

It seems the stracktrace is missing the part that complains about the 
JAXBContext. Can you post it here?

We made some improvements in this area: 
http://svn.apache.org/viewvc?rev=795991&view=rev. Can you try if it helps?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, August 18, 2009 2:25 PM
To: <us...@tuscany.apache.org>
Subject: Issue using JAXB generated classes in SCA remotable service

> Hi All,
>
> I'm using SCA Java 1.5 and I'm running into an issue when data is being 
> returned from a service invocation for a Remotable service using the WS 
> binding.  The service is returning instances of classes that were 
> generated using JAXB from multiple XSDs.  These schemas include a number 
> of abstract elements as well as substitution groups.  I'm not particularly 
> proficient with XSD so my terminology may be off but, I believe that the 
> problem is that since the concrete types for these various abstract 
> elements are not in the same package as the base types, they don't get 
> included the un/marshaller's context.  They are also not in the WSDL 
> generated via the WS binding.  The stack trace I'm seeing is at the bottom 
> of this e-mail.
>
> So, based on the stack trace, does it look like some missing namespaces 
> would cause this issue?  If so, is there a way to explicitly include 
> additional namespaces such that they'll be properly included in the 
> un/marshaller's context?  They would also need to be imported in the WSDL 
> generated by the WS binding.  If at all possible I'd like to avoid having 
> to manually create or modify the WSDL or any of generated classes (JAXB / 
> JAXWS).
>
> Here is the stack trace:
>
> org.apache.axis2.AxisFault
>        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
>        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>        at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
>        at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>        at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>        at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
>        at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>        at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>        at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.xml.stream.XMLStreamException
>        at 
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
>        at 
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
>        ... 30 more
>
> - Chad Phillips

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Raymond (and anyone else familiar w/ the JAXB and WS bindings),

Can you take a look at the comment trail from Scott and me at [1] to see if there is something else that needs to be done?  We got past the exception but it seems that the WSDL is not being generated correctly or maybe I'm just not using wsimport correctly.

[1] https://issues.apache.org/jira/browse/TUSCANY-3238

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, August 18, 2009 14:38
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Do the generated subclasses extend from base classes? If so, I assume adding 
the subclass into the JAXBContext will automatically add the base classes.

It seems the stracktrace is missing the part that complains about the 
JAXBContext. Can you post it here?

We made some improvements in this area: 
http://svn.apache.org/viewvc?rev=795991&view=rev. Can you try if it helps?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, August 18, 2009 2:25 PM
To: <us...@tuscany.apache.org>
Subject: Issue using JAXB generated classes in SCA remotable service

> Hi All,
>
> I'm using SCA Java 1.5 and I'm running into an issue when data is being 
> returned from a service invocation for a Remotable service using the WS 
> binding.  The service is returning instances of classes that were 
> generated using JAXB from multiple XSDs.  These schemas include a number 
> of abstract elements as well as substitution groups.  I'm not particularly 
> proficient with XSD so my terminology may be off but, I believe that the 
> problem is that since the concrete types for these various abstract 
> elements are not in the same package as the base types, they don't get 
> included the un/marshaller's context.  They are also not in the WSDL 
> generated via the WS binding.  The stack trace I'm seeing is at the bottom 
> of this e-mail.
>
> So, based on the stack trace, does it look like some missing namespaces 
> would cause this issue?  If so, is there a way to explicitly include 
> additional namespaces such that they'll be properly included in the 
> un/marshaller's context?  They would also need to be imported in the WSDL 
> generated by the WS binding.  If at all possible I'd like to avoid having 
> to manually create or modify the WSDL or any of generated classes (JAXB / 
> JAXWS).
>
> Here is the stack trace:
>
> org.apache.axis2.AxisFault
>        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
>        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>        at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
>        at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>        at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>        at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
>        at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>        at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>        at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.xml.stream.XMLStreamException
>        at 
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
>        at 
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
>        ... 30 more
>
> - Chad Phillips

RE: Issue using JAXB generated classes in SCA remotable service

Posted by "Phillips, Chad" <Ch...@gdit.com>.
Hi Raymond,

I created a JIRA issue for this problem which includes a test program that can be used to reproduce the issue.  Here is the link: https://issues.apache.org/jira/browse/TUSCANY-3238 

I tried this with both Apache Tuscany SCA Java 1.5 and 1.6 SNAPSHOT (r805992) and the result was the same.

-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com] 
Sent: Tuesday, August 18, 2009 14:38
To: user@tuscany.apache.org
Subject: Re: Issue using JAXB generated classes in SCA remotable service

Do the generated subclasses extend from base classes? If so, I assume adding 
the subclass into the JAXBContext will automatically add the base classes.

It seems the stracktrace is missing the part that complains about the 
JAXBContext. Can you post it here?

We made some improvements in this area: 
http://svn.apache.org/viewvc?rev=795991&view=rev. Can you try if it helps?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, August 18, 2009 2:25 PM
To: <us...@tuscany.apache.org>
Subject: Issue using JAXB generated classes in SCA remotable service

> Hi All,
>
> I'm using SCA Java 1.5 and I'm running into an issue when data is being 
> returned from a service invocation for a Remotable service using the WS 
> binding.  The service is returning instances of classes that were 
> generated using JAXB from multiple XSDs.  These schemas include a number 
> of abstract elements as well as substitution groups.  I'm not particularly 
> proficient with XSD so my terminology may be off but, I believe that the 
> problem is that since the concrete types for these various abstract 
> elements are not in the same package as the base types, they don't get 
> included the un/marshaller's context.  They are also not in the WSDL 
> generated via the WS binding.  The stack trace I'm seeing is at the bottom 
> of this e-mail.
>
> So, based on the stack trace, does it look like some missing namespaces 
> would cause this issue?  If so, is there a way to explicitly include 
> additional namespaces such that they'll be properly included in the 
> un/marshaller's context?  They would also need to be imported in the WSDL 
> generated by the WS binding.  If at all possible I'd like to avoid having 
> to manually create or modify the WSDL or any of generated classes (JAXB / 
> JAXWS).
>
> Here is the stack trace:
>
> org.apache.axis2.AxisFault
>        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
>        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>        at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
>        at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>        at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>        at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
>        at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>        at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>        at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.xml.stream.XMLStreamException
>        at 
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
>        at 
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
>        ... 30 more
>
> - Chad Phillips

Re: Issue using JAXB generated classes in SCA remotable service

Posted by Raymond Feng <en...@gmail.com>.
Do the generated subclasses extend from base classes? If so, I assume adding 
the subclass into the JAXBContext will automatically add the base classes.

It seems the stracktrace is missing the part that complains about the 
JAXBContext. Can you post it here?

We made some improvements in this area: 
http://svn.apache.org/viewvc?rev=795991&view=rev. Can you try if it helps?

Thanks,
Raymond

--------------------------------------------------
From: "Phillips, Chad" <Ch...@gdit.com>
Sent: Tuesday, August 18, 2009 2:25 PM
To: <us...@tuscany.apache.org>
Subject: Issue using JAXB generated classes in SCA remotable service

> Hi All,
>
> I'm using SCA Java 1.5 and I'm running into an issue when data is being 
> returned from a service invocation for a Remotable service using the WS 
> binding.  The service is returning instances of classes that were 
> generated using JAXB from multiple XSDs.  These schemas include a number 
> of abstract elements as well as substitution groups.  I'm not particularly 
> proficient with XSD so my terminology may be off but, I believe that the 
> problem is that since the concrete types for these various abstract 
> elements are not in the same package as the base types, they don't get 
> included the un/marshaller's context.  They are also not in the WSDL 
> generated via the WS binding.  The stack trace I'm seeing is at the bottom 
> of this e-mail.
>
> So, based on the stack trace, does it look like some missing namespaces 
> would cause this issue?  If so, is there a way to explicitly include 
> additional namespaces such that they'll be properly included in the 
> un/marshaller's context?  They would also need to be imported in the WSDL 
> generated by the WS binding.  If at all possible I'd like to avoid having 
> to manually create or modify the WSDL or any of generated classes (JAXB / 
> JAXWS).
>
> Here is the stack trace:
>
> org.apache.axis2.AxisFault
>        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:83)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:337)
>        at 
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:214)
>        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>        at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
>        at 
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>        at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>        at 
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:107)
>        at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.doFilter(TuscanyServletFilter.java:93)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>        at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>        at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>        at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>        at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>        at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.xml.stream.XMLStreamException
>        at 
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.serialize(JAXBDataSource.java:123)
>        at 
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
>        at 
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
>        at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
>        at 
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
>        at 
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:79)
>        ... 30 more
>
> - Chad Phillips