axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lasantha Ranaweera <lasan...@opensource.lk>
Subject Re: [Axis2] JAXWSMessageReciever Marshaller Problem
Date Mon, 12 Feb 2007 05:50:31 GMT
Hi Lin,

Now there is a Maven2  script to Axis2 (which is considerably faster 
than previous script) and it works fine for me. It will get rid of lot 
of pain from our side in this kind of work & my hats off to the Axis2 
guys for considering the Maven2 option as well ;-) .

The problem you have given is due to a mis configuration (missing 
parameter names) in the Geronimo side & it comes at the very high level 
of the source code.

We might have to update Axis2 source code from time to time since we are 
still depending on the 'SNAPSHOT' version of the Axis2. I noticed 
sometimes our changes are not valid after 2 days time even. So keep 
updating source code for both Geronimo & Axis2  :-) .

Thanks,
Lasantha

Lin Sun wrote:
> 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 <nlgallar@us.ibm.com> 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
>>>  nlgallar@us.ibm.com
>>>  Phone: 512-838-1182
>>>  Building: 901 / 5G-016
>>>
>>>
>>>
>>>  "Lasantha Ranaweera" <lasantha@opensource.lk>
>>>
>>> 02/05/2007 09:54 AM
>>>
>>>
>>> Please respond to
>>>  axis-dev@ws.apache.org
>>>
>>>
>>> To axis-dev@ws.apache.org
>>>
>>> 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
>>>  > nlgallar@us.ibm.com
>>>  > Phone: 512-838-1182
>>>  > Building: 901 / 5G-016
>>>  >
>>>  >
>>>  >
>>>  > "Lin Sun" <linsun.unc@gmail.com>
>>>  > 02/04/2007 09:50 PM
>>>  > Please respond to
>>>  > axis-dev@ws.apache.org
>>>  >
>>>  >
>>>  > To
>>>  > <axis-dev@ws.apache.org>
>>>  > 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:lasantha@opensource.lk]
>>>  > Sent: Wednesday, January 31, 2007 1:33 AM
>>>  > To: axis-dev@ws.apache.org
>>>  > 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
>>>  >> nlgallar@us.ibm.com
>>>  >> Phone: 512-838-1182
>>>  >> Building: 901 / 5G-016
>>>  >>
>>>  >>
>>>  >> *"Lasantha Ranaweera" <lasantha@opensource.lk>*
>>>  >>
>>>  >> 01/26/2007 11:09 PM
>>>  >> Please respond to
>>>  >> axis-dev@ws.apache.org
>>>  >>
>>>  >>
>>>  >>
>>>  >> To
>>>  >>                axis-dev@ws.apache.org
>>>  >> cc
>>>  >>                dims@wso2.com
>>>  >> 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: axis-dev-unsubscribe@ws.apache.org
>>>  >> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>  >>
>>>  >>
>>>  >
>>>  >
>>>  >
>>>  > 
>>> ---------------------------------------------------------------------
>>>  > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>>  > For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>  >
>>>  >
>>>  > 
>>> ---------------------------------------------------------------------
>>>  > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>>  > For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>  >
>>>  >
>>>  >
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>>  For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>  --=_alternative 005A88328625727D_=--
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message