Lasantha, 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. Regards, Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 Lasantha Ranaweera <[EMAIL PROTECTED]> 02/04/2007 11:13 PM Please respond to [email protected] To [email protected], [email protected] cc Subject Re: JAXWSMessageReciever Marshaller Problem Hi, 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? Thanks, Lasantha 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 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]
