Hi Sebastian

pls see my in line comments

Sebastian J. Schultheiss wrote:

>Hi Deepal,
>
>  
>
>>yes , its better if you can close the JIRA , btw what is the JIRA number.
>>    
>>
>this is the JIRA index: AXIS2-494
>http://issues.apache.org/jira/browse/AXIS2-494
>Could you close it?
>
>  
>
yes I will.

>>As you said RawXMLINOutMessageReceiver is only support OM only case ,
>>and if you want to have other data types then you have either use
>>RPCMessageReciver or you have to write your own mesagereciver. But if
>>you are starting from a WSDL then when you code gen it will generate
>>MessageReceiver for you.
>>    
>>
>
>We would like to have a service that has a function like this:
>
>public String epipredRP(String sequence, String allele) throws 
>XMLStreamException;
>
>We are not starting from WSDL, but if that is the better way, we could first
>write a WSDL for our service and try to create the code from it. We already
>played around with the WSDL2Java 0.94 tool, but the code it created was 
>enormous
>considering the easy example we wanted to use it for. So we're trying from
>scratch now.
>  
>
Starting from the WSDL is the best approach , but I also like to start
from Java class and convert that to a service :)

>Is there a tutorial or example for RPCMessageReceiver, how to actually use
>MessageContext etc.? If we include the service as mentioned above, and put
>RPCMessageReceiver in the services.xml, we only get a
>  
>
unfortunately we dont have tutorial on that area :(   , anyway the
simple steps are as follows;
   1. In the services.xml you have to put messageReciver as
RPCMessageReceiver
   2. If you dont exclude operations all of the methods public methods
in the service impl class will be exposed.
   5. If you like to expose all the public methods then you dont need to
add any operations in the services.xml

so your services.xml will look like follows (if you publish all the
public methods)

 <service name="MyService">
        <messageReceivers>
            <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only";
                            
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
            <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out";
                            
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
        </messageReceivers>
        <parameter name="ServiceClass">MySerice</parameter>
    </service>

 

>java.lang.NullPointerException:
>       
> org.apache.axis2.engine.AxisEngine.createFaultMessageContext(AxisEngine.java:191)
>       
> org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:191)
>       org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:125)
>       javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>       javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>
>The reason we are doing this is that we want the WSDL to automatically list the
>correct types, child elements etc. required for the service. If you tell us the
>only way to get there is by writing the WSDL by hand, we can do that too :)
>  
>
nope , Axis2 will automatically generate WSDL for you , if you did not
put a wsdl file inside service archive file. You dont need to hand write
wsdl :)

>Thanks for your help,
>
>-- Sebi
>
>Deepal Jayasinghe wrote:
>  
>
>>Sebastian J. Schultheiss wrote:
>>
>>    
>>
>>>Hello,
>>>
>>>we have just migrated to the new 0.95 version of Axis2 and are glad to 
>>>discover
>>>that the WSDL that is generated from the .aar is now valid. Do you want us to
>>>close our JIRA bug listing ourselves?
>>>
>>>Last time someone suggested we use xs:integer etc. instead of xs:anytype. We
>>>would be glad to do so, however right now the RawXMLINOutMessageReceiver 
>>>claims
>>>to only work with functions (server side) of the form
>>>
>>>public OMElement fctname(OMElement oe) {}
>>>
>>>What do we have to do to make it work with a function that has a different
>>>parameter type, or even return type? Do we have to use a RPC message receiver
>>>instead?
>>>
>>>Thanks a lot for your time.
>>>
>>>-- Sebastian
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>

-- 
Thanks,
Deepal
................................................................
~Future is Open~ 


Reply via email to