Dims,
By "the other SOAP engine", I'm assuming that's CXF?
Our usage of JAXB right now is dependent upon root elements. By that,
I mean that the wrapper bean that's defined as the root element in the
schema. These generated classes carry some additional annotations
that allow us to unmarshall them easily with JAXB.
I discussed this with Rich and he had some ideas about ways we could
possibly get around this. It will have to be a lower severity item
though as we're working through some functional scenarios. I've
opened a JIRA issue to track this.
https://issues.apache.org/jira/browse/AXIS2-2155
Regards,
Nicholas Gallardo
WebSphere - WebServices Development
[EMAIL PROTECTED]
Phone: 512-838-1182
Building: 901 / 5G-016
*"Davanum Srinivas" <[EMAIL PROTECTED]>*
02/09/2007 10:54 AM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: JAXWSMessageReciever Marshaller Problem
Nick,
The other soap engine inside Geronimo seems to work w/o needing the
wrapper classes. Anything we can do to get ours working too? w/o
having to run the xjc command with "-wsdl"? Is this planned, or out of
scope?
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]
