axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas L Gallardo <>
Subject Re: JAXWSMessageReciever Marshaller Problem
Date Mon, 05 Feb 2007 14:35:10 GMT

I don't quite understand the question.  "wsgen" is a tool that, given a 
service implementation, will generate the necessary wrapper classes and a 
WSDL document if so desired. 

As for how JAXB works with JAX-WS, some of the info in my response to Lin 
should provide some starting points.


Nicholas Gallardo
WebSphere  -  WebServices Development
Phone: 512-838-1182
Building: 901 / 5G-016

Lasantha Ranaweera <> 
02/04/2007 11:13 PM
Please respond to


Re: JAXWSMessageReciever Marshaller Problem


I heard "wsgen" tool will do the same kind of work annotated classes. Do 
we need to implement this kind of work in the Geronimo side too for the 
Axis2 :-( .

May be somebody who knows JAXB binding of the CFX will explain us how 
does it works with JAXWS?

Lin Sun wrote:
> 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 
> doesn't have any jaxb generated classes in the war file.  Axis2 did 
> to use DocLitWrappedMethodMarshaller to do the marshaller work and the
> following exception was thrown when message.getBodyBlock(0, 
> factory) is called.
> javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element
> (uri:"", local:"greetMe"). 
> 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 
> of the ObjectFactory Class and package-info Class (part of jaxb 
> classes) in the test application?
> This same jax-ws test works with CXF integration into Geronimo so I 
> 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 [] 
> Sent: Wednesday, January 31, 2007 1:33 AM
> To:
> 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
>> Phone: 512-838-1182
>> Building: 901 / 5G-016
>> *"Lasantha Ranaweera" <>*
>> 01/26/2007 11:09 PM
>> Please respond to
>> To
>> cc
>> 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 
>> 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 
>> a DocLiteralMarashaller and tries to unmarshall my RPC based request 
>> get failed with UnmarshallException :(. When I change the default
>> SOAPBinding style in EndpointInterfaceDescriptionImpl to RPC it works 
>> (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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message