Yeah we are using the same test and have same questions.:-) Thanks again Nick for your help!
Lin -----Original Message----- From: Lasantha Ranaweera [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 10:54 AM To: axis-dev@ws.apache.org 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 > 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 >> axis-dev@ws.apache.org >> 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] > > >
<?xml version="1.0" encoding="UTF-8"?> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <wsdl:definitions xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:tns="http://apache.org/greeter_control"; xmlns:x1="http://apache.org/greeter_control/types"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://apache.org/greeter_control"; name="HelloWorld"> <wsdl:types> <schema targetNamespace="http://apache.org/greeter_control/types"; xmlns="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"> <element name="sayHi"> <complexType/> </element> <element name="sayHiResponse"> <complexType> <sequence> <element name="responseType" type="xsd:string"/> </sequence> </complexType> </element> <element name="greetMe"> <complexType> <sequence> <element name="requestType" type="xsd:string"/> </sequence> </complexType> </element> <element name="greetMeResponse"> <complexType> <sequence> <element name="responseType" type="xsd:string"/> </sequence> </complexType> </element> <element name="greetMeOneWay"> <complexType> <sequence> <element name="requestType" type="xsd:string"/> </sequence> </complexType> </element> <element name="pingMe"> <complexType/> </element> <element name="pingMeResponse"> <complexType/> </element> <element name="faultDetail"> <complexType> <sequence> <element name="minor" type="xsd:short"/> <element name="major" type="xsd:short"/> </sequence> </complexType> </element> </schema> </wsdl:types> <wsdl:message name="sayHiRequest"> <wsdl:part element="x1:sayHi" name="in"/> </wsdl:message> <wsdl:message name="sayHiResponse"> <wsdl:part element="x1:sayHiResponse" name="out"/> </wsdl:message> <wsdl:message name="greetMeRequest"> <wsdl:part element="x1:greetMe" name="in"/> </wsdl:message> <wsdl:message name="greetMeResponse"> <wsdl:part element="x1:greetMeResponse" name="out"/> </wsdl:message> <wsdl:message name="greetMeOneWayRequest"> <wsdl:part element="x1:greetMeOneWay" name="in"/> </wsdl:message> <wsdl:message name="pingMeRequest"> <wsdl:part name="in" element="x1:pingMe"/> </wsdl:message> <wsdl:message name="pingMeResponse"> <wsdl:part name="out" element="x1:pingMeResponse"/> </wsdl:message> <wsdl:message name="pingMeFault"> <wsdl:part name="faultDetail" element="x1:faultDetail"/> </wsdl:message> <wsdl:portType name="Greeter"> <wsdl:operation name="sayHi"> <wsdl:input message="tns:sayHiRequest" name="sayHiRequest"/> <wsdl:output message="tns:sayHiResponse" name="sayHiResponse"/> </wsdl:operation> <wsdl:operation name="greetMe"> <wsdl:input message="tns:greetMeRequest" name="greetMeRequest"/> <wsdl:output message="tns:greetMeResponse" name="greetMeResponse"/> </wsdl:operation> <wsdl:operation name="greetMeOneWay"> <wsdl:input message="tns:greetMeOneWayRequest" name="greetMeOneWayRequest"/> </wsdl:operation> <wsdl:operation name="pingMe"> <wsdl:input name="pingMeRequest" message="tns:pingMeRequest"/> <wsdl:output name="pingMeResponse" message="tns:pingMeResponse"/> <wsdl:fault name="pingMeFault" message="tns:pingMeFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="GreeterSOAPBinding" type="tns:Greeter"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="sayHi"> <soap:operation soapAction="" style="document"/> <wsdl:input name="sayHiRequest"> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="sayHiResponse"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="greetMe"> <soap:operation soapAction="" style="document"/> <wsdl:input name="greetMeRequest"> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="greetMeResponse"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="greetMeOneWay"> <soap:operation soapAction="" style="document"/> <wsdl:input name="greetMeOneWayRequest"> <soap:body use="literal"/> </wsdl:input> </wsdl:operation> <wsdl:operation name="pingMe"> <soap:operation style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <wsdl:fault name="pingMeFault"> <soap:fault name="pingMeFault" use="literal"/> </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="GreeterService"> <wsdl:port binding="tns:GreeterSOAPBinding" name="GreeterPort"> <soap:address location="http://localhost:8080/SoapContext/GreeterPort"/> <wswa:UsingAddressing xmlns:wswa="http://www.w3.org/2005/08/addressing/wsdl"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
Greeter.java
Description: Binary data
GreeterImpl.java
Description: Binary data
--------------------------------------------------------------------- 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]
