Hi Nicholas, Thanks so much for your reply! :-)
You are right - the service is wrapped. And it does have an @RequestWrapper and @ResponseWrapper annotation on the operation. Please find the attached zip file of the simple test. (will be emailed as a private note.) In greeter.java, it specifies: @ResponseWrapper(targetNamespace = "http://apache.org/hello_world_soap_http/types";, className = "org.apache.hello_world_soap_http.types.GreetMeResponse", localName = "greetMeResponse") @RequestWrapper(targetNamespace = "http://apache.org/hello_world_soap_http/types";, className = "org.apache.hello_world_soap_http.types.GreetMe", localName = "greetMe") I just noticed that we don't have these two classes yet. I didn't pay attention to this before as we don't seem to need them for cxf. Thanks again for your help! Lin ________________________________________ From: Nicholas L Gallardo [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 9:29 AM To: axis-dev@ws.apache.org Subject: RE: JAXWSMessageReciever Marshaller Problem 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 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:[EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > Phone: 512-838-1182 > Building: 901 / 5G-016 > > > *"Lasantha Ranaweera" <[EMAIL PROTECTED]>* > > 01/26/2007 11:09 PM > Please respond to > axis-dev@ws.apache.org > > > > 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]
