Lin,
How about this angle of attack?
1) copy the xsd from the wsdl If it is not available already
2) copy the snippet that runs JAXB's XJC from axis2\modules\pom.xml
and get it working inside the jaxws-war (basically it should generate
code from the xsd)
3) modify the snippet to add "-wsdl"
4) get this code working as-is
5) then get it working with Axis2
thanks,
dims
On 2/9/07, Nicholas L Gallardo <[EMAIL PROTECTED]> wrote:
Hi Lasantha,
Sorry for the late response here. You have correctly identified the missing piece
though. For services that are considered doc/lit wrapped (the default for JAX-WS), it is
required that the wrapper beans be generated. You can get these by running the JAXB
generation tool with the "-wsdl" flag I believe. The JAX-WS runtime in Axis2
will not generate these on the fly, but needs these classes to be able to
marshall/unmarshall the messages.
Beyond that though, you don't need to include the @RequestWrapper or
@ResponseWrapper annotations if the generated class names follow the defaults:
- package name is the same as the SEI
- class names are OperationName and OperationNameResponse with the
appropriate camel casing.
Hope that helps...
Regards,
Nicholas Gallardo
WebSphere - WebServices Development
[EMAIL PROTECTED]
Phone: 512-838-1182
Building: 901 / 5G-016
"Lasantha Ranaweera" <[EMAIL PROTECTED]>
02/05/2007 09:54 AM
Please respond to
[email protected]
To [email protected]
cc
Subject RE: JAXWSMessageReciever Marshaller Problem
Hi Nick,
Thank you very much for the giving some insight.
Say for example if are having Doc/Lit service with @ResponsWrapper &
@RequestWrapper annotations, will the Axis2 generate intermediate classes
for the JAXB binding automatically? Otherwise do we need to some how
generate it & add it in to the archive?
First we are working on an example which has a WSDL and creating
annotations by hand using it's relevant composites.
Please find the attached WSDL, endpoint & endpoint impl class.
Any help would be greately appriciated.
Thanks,
Lasantha Ranaweera
> Lin,
>
> JAXB objects are not always required. You could be using simple types
> that map base Java types like String, int, boolean, etc. But, in all
> cases, we will use JAX-WS as a means to marshall/unmarshall data types.
>
> The exception you're seeing usually happens when the JAXBContext that is
> used to unmarshall the message is not configured correctly. The two
> messages that you see from JAXBUtils could be an indication of the problem
> depending on what pattern your service is following (wrapped vs. bare).
> I'm guessing wrapped since it went down into the
> DocLitWrappedMethodMarshaller.
>
> Overall, we need one of two things to be able to configure the JAXBContext
> correctly and unmarshall the incoming request.
>
> a) If it's wrapped, then you need to have an @RequestWrapper and
> @ResponseWrapper annotation on your operation. That can be used by JAXB
> to pick-up the wrapper classes that are defined for that operation.
>
> b) If it's not wrapped, then you will need to have an ObjectFactory. The
> ObjectFactory can be used by the JAXBContext under the covers to figure
> out how to unmarshall elements that don't have custom types defined.
> Without this though, the unmarhaller wont' work.
>
> Can you post an example of the endpoint that you're trying to deploy and
> what annotations it has on it? Is this endpoint being deployed with or
> without a WSDL?
>
> Regards,
>
> Nicholas Gallardo
> WebSphere - WebServices Development
> [EMAIL PROTECTED]
> Phone: 512-838-1182
> Building: 901 / 5G-016
>
>
>
> "Lin Sun" <[EMAIL PROTECTED]>
> 02/04/2007 09:50 PM
> Please respond to
> [email protected]
>
>
> To
> <[email protected]>
> cc
>
> Subject
> RE: JAXWSMessageReciever Marshaller Problem
>
>
>
>
>
>
> Hi there,
>
> A basic question, are jaxb objects required in a simple hello jax-ws
> application? I think I am running the same test as Lasantha and this
> test
> doesn't have any jaxb generated classes in the war file. Axis2 did choose
> to use DocLitWrappedMethodMarshaller to do the marshaller work and the
> following exception was thrown when message.getBodyBlock(0, blockContext,
> factory) is called.
>
> javax.xml.bind.UnmarshalException
> - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://apache.org/hello_world_soap_http";, local:"greetMe"). Expected
> elements are (none)]
>
> I also saw
>
> 21:50:34,781 INFO [JAXBUtils] ObjectFactory Class Not Found
> 21:50:34,828 INFO [JAXBUtils] package-info Class Not Found
>
> in my console log, which seems to indicate that axis2 requires the
> existence
> of the ObjectFactory Class and package-info Class (part of jaxb generated
> classes) in the test application?
>
> This same jax-ws test works with CXF integration into Geronimo so I
> thought
> it would be okay to not have jaxb objects in the application archive.
> However, missing it seems to cause the UnmarshalException.
>
> Any help is appreciated.
>
> Lin
>
> -----Original Message-----
> From: Lasantha Ranaweera [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 31, 2007 1:33 AM
> To: [email protected]
> Subject: Re: JAXWSMessageReciever Marshaller Problem
>
> Hi Nich,
>
> Thank you very much for the information. I have uploaded latest patch
> (number 2) to the Geronimo list under GERONIMO-2776.
>
> I am basically trying to read a WSDL and create JAXWS service by hand
> filling necessary composites for situations where class level
> annotations are not provided.
>
> After some debugging sessions understand this is due to the missing JAXB
> objects in my application archive. It would be ideal if you can explain
> me how the JAXB bindings work for the JAXWS in the Axis2 side. :-)
>
> Also is there any publicly available articles to refer JAXWS stuff on
> the Axis2?
>
> Thanks Again,
> Lasantha
>
> Nicholas L Gallardo wrote:
>>
>> Hi Lasantha,
>>
>> Sorry for the delayed response here.
>>
>> I think I need to understand how you're deploying/configuring the
>> endpoint before I can provide guidance on what's going on here. I
>> know we've already started the Geronimo integration, but I think some
>> of that is going to (or should probably) rely on similar work that
>> needs to be done in Axis2. Do you have some information or
>> architecture that you can share for how this is being done?
>>
>> As far as this situation, the unmarshalling is going to be predicated
>> on what style of WSDL you have. If you've just annotated a POJO and
>> then deployed that, the default WSDL mapping is to a Document/Literal
>> Wrapped style WSDL. You can use the SOAPBinding annotation as you've
>> already seen to toggle between a Document and RPC style. Only
>> "literal" use is supported. JAX-WS does not support RPC/Encoded style
>> WSDLs.
>>
>> At a high level what will happen is, after the request comes in to the
>> JAXWSMessageReceiver, a decision will be made as to what
>> MethodMarshaller needs to be loaded. This decision is based on the
>> information in the EndpointDescription/OperationDescription. Each of
>> those objects is a view of the WSDL and annotation information
>> available for an endpoint/operation. If those are not configured
>> correctly, then you won't have the right MethodMarshaller.
>>
>> Is the scenario that you have intended to truly be based on an "RPC"
>> style WSDL (as opposed to a "Document" style)? I'm assuming that the
>> RPC in the RPCMessageReceiver is referring more to the fact that it's
>> for services that are based on an interaction that people would
>> consider RPC over a messaging style interaction. Is that correct?
>>
>> Regards,
>>
>> Nicholas Gallardo
>> WebSphere - WebServices Development
>> [EMAIL PROTECTED]
>> Phone: 512-838-1182
>> Building: 901 / 5G-016
>>
>>
>> *"Lasantha Ranaweera" <[EMAIL PROTECTED]>*
>>
>> 01/26/2007 11:09 PM
>> Please respond to
>> [email protected]
>>
>>
>>
>> To
>> [email protected]
>> cc
>> [EMAIL PROTECTED]
>> Subject
>> JAXWSMessageReciever Marshaller Problem
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> This is a problem arised in the Geronimo Axis2 integration with
>> JAXWSMessageReciever.
>>
>> I created an AxisService with a JAXWSMessageReciever as it's message
>> reciever and trying to invoke the service using
>> HTTPTransportUtils.processHTTPPostRequest() method. We are sending a RPC
>> based SOAPRequest to the service invocation.
>>
>> The JAXWSMessageReciever then creates Marshaller for the unmarshall
>> requests. This marshaller creation is entirely depends on the
>> EndpointInterfaceDescriptionImpl SOAPBinding style. By default it
> creates
>> a DocLiteralMarashaller and tries to unmarshall my RPC based request and
>> get failed with UnmarshallException :(. When I change the default
>> SOAPBinding style in EndpointInterfaceDescriptionImpl to RPC it works
> fine
>> (sure it's not the way to do it). Is this is the correct behaviour of
>> Marshal creation of JAXWSMessageReciever? Shouldn't it be depends on
>> SOAPMessage messaging mode too?
>>
>> BTW I have created a JIRA (AXIS2-2044) patch to remove some of the
>> misleading information gives in the Axis2 integrating it with Geronimo.
>>
>> Thanks,
>> Lasantha Ranaweera
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--=_alternative 005A88328625727D_=--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
