The DocLitWrapperMethodMarshaller is in the jaxws module.
The EndpoointDescription is in the metadata module.
It sounds like you have some stale jars. This will result in the
NoSuchMethodError below.
Make sure to rebuild all of axis2...not just axis2/modules/jaxws
Rich Scheuerle
IBM Web Services
Apache Axis2 ([EMAIL PROTECTED])
512-838-5115 (IBM TL 678-5115)
Lin Sun <[EMAIL PROTECTED]> wrote on 02/09/2007 02:40:24 PM:
> Hi Nich, thanks again for your help! See below for the most recent
error.
>
> Dims, I've followed your proposed step here. I had some hard time to
> it running from maven 1 script (axis2\modules\jaxws) to maven 2 script
> (geronimo\...\jax-ws\) but I did manage to generate the java files I
> need using the JAXB generation tool. It turned out that I don't need to
> copy the xsd from the wsdl file and I can just run the tool with the
> '-wsdl' option.
>
> I asked the generated code to be created in the same dir as the other
> two java files (src\org\apache\hello_world_soap_http\).
>
> so I got everything I need for the war file however I hit this same
> error as I hit yesterday. Doesn't seem the generated code made any
> difference!
>
> java.lang.NoSuchMethodError:
> org.apache.axis2.jaxws.description.EndpointDescript
> ion.getPackages()Ljava/util/Set;
> at
> org.apache.axis2.jaxws.marshaller.impl.alt.DocLitWrappedMethodMarshal
> ler.demarshalRequest(DocLitWrappedMethodMarshaller.java:196)
> at
> org.apache.axis2.jaxws.server.dispatcher.JavaBeanDispatcher.invoke(Ja
> vaBeanDispatcher.java:69)
> at
> org.apache.axis2.jaxws.server.EndpointController.invoke(EndpointContr
> oller.java:79)
> at
> org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessa
> geReceiver.java:101)
> at
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:177)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
> uest(HTTPTransportUtils.java:275)
>
> Noticed that the above error happened a few lines before
> message.getBodyBlock(0, blockContext,factory) which is what I hit on
> 02/04. My guess is that the difference is caused by some changes in
> axis-trunk very recently.
>
> Any help is appreciated! I'll continue investigating but thought I'd
> send this first in case Nich or Dims or others has some insight into it.
>
> Lin
>
>
>
> Davanum Srinivas wrote:
> > 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]
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
