You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Abdullah Kauchali <ab...@isanusi.com> on 2005/07/14 13:52:10 UTC

Generation of properly completed WSDL2Java Skeletons????

Is there any way to generate /properly completed/ skeleton java classes 
when using
the WSDL2Java tool when exposing the Java web service with Axis?
(ver 1.2.1)

We have about 200 classes - each with about 6 methods - sitting in a jar 
file that we
want to expose via  Axis web services.  If we were to do this manually, 
it would take
us an eternity viz. completing the implementation skeleton classes so 
that the
parameters are "forwarded" properly to the correct classes, and then testing
our work thereafter!

We've managed to use the Java2WSDL tool successfully and Axis has 
created our
doc/literal WSDL files.  Great stuff.  However, the next step is to 
create skeleton
classes using the WSDL2Java tool and it is here we found out that Axis 
simply creates
"empty" classes often with it's own interpretation of what is to be 
eventually called by the
skeleton class and what's to returned by the web service.   Many 
documents suggest
we ought to change the skeleton (implementation) classes /manually/ so 
that the correct
Java classes are referenced and called!!!

Is there any option for the WSDL2Java to actually read the contents of 
the /original/
Java classes which were used by the Java2WSDL tool to create the WSDL
file and then simply call or reference those classes from the skeleton 
classes - avoiding
any manual intervention?

Any ideas greatly appreciated,

Kind regards

Abdullah

Re: Generation of properly completed WSDL2Java Skeletons????

Posted by Anne Thomas Manes <at...@gmail.com>.
Abdullah,

If any of your existing classes expose collection types, you'll
experience interoperability issues if you try to expose them directly.
In general, it's risky to try to directly expose Java classes as web
services. Web services should expose only simply types, structures of
simple types, and arrays of simple types/structures.

Anne

On 7/14/05, Abdullah Kauchali <ab...@isanusi.com> wrote:
> Davanum Srinivas wrote:
> 
> >look at helpergen option on wsdl2java.
> >
> 
> Hi Davanum!
> 
> Thanks for that information.  However, I couldn't glean any further use
> or meaning out of the
> docs on how to use the HelperGen function?  How do I use it?
> 
> I have found the following though:
> 
> 1.  Instead of rewriting the "caller" functions from the xxxBindingImpl
> class, I can simply
> modify the generated class to inherit it from the original
> implementation.  (Of course
> deleting the contents of the extending class.  This seems to work.
> 
> 2.  This approach seems like a less risky one compared to  manually
> writing "wrapper"
> calls to the original class from within the generate xxxBindingImpl
> class.  I am wondering
> why many articles and tutorials encourage you to do the wrapper approach
> instead?
> Is there anything wrong with simply inheriting from the original class?
> 
> My only objective is to avoid tinkering with the generated classes.   I
> really hope I
> am not asking too much from Axis!  :)
> 
> Any comments welcome.
> 
> Kind regards
> 
> Abdullah
>

Re: Generation of properly completed WSDL2Java Skeletons????

Posted by Abdullah Kauchali <ab...@isanusi.com>.
Davanum Srinivas wrote:

>look at helpergen option on wsdl2java.
>

Hi Davanum!

Thanks for that information.  However, I couldn't glean any further use 
or meaning out of the
docs on how to use the HelperGen function?  How do I use it?

I have found the following though:

1.  Instead of rewriting the "caller" functions from the xxxBindingImpl 
class, I can simply
modify the generated class to inherit it from the original 
implementation.  (Of course
deleting the contents of the extending class.  This seems to work.

2.  This approach seems like a less risky one compared to  manually 
writing "wrapper"
calls to the original class from within the generate xxxBindingImpl 
class.  I am wondering
why many articles and tutorials encourage you to do the wrapper approach 
instead? 
Is there anything wrong with simply inheriting from the original class?

My only objective is to avoid tinkering with the generated classes.   I 
really hope I
am not asking too much from Axis!  :)

Any comments welcome.

Kind regards

Abdullah

Re: Generation of properly completed WSDL2Java Skeletons????

Posted by Davanum Srinivas <da...@gmail.com>.
look at helpergen option on wsdl2java.

-- dims

On 7/14/05, Abdullah Kauchali <ab...@isanusi.com> wrote:
> Is there any way to generate /properly completed/ skeleton java classes
> when using
> the WSDL2Java tool when exposing the Java web service with Axis?
> (ver 1.2.1)
> 
> We have about 200 classes - each with about 6 methods - sitting in a jar
> file that we
> want to expose via  Axis web services.  If we were to do this manually,
> it would take
> us an eternity viz. completing the implementation skeleton classes so
> that the
> parameters are "forwarded" properly to the correct classes, and then testing
> our work thereafter!
> 
> We've managed to use the Java2WSDL tool successfully and Axis has
> created our
> doc/literal WSDL files.  Great stuff.  However, the next step is to
> create skeleton
> classes using the WSDL2Java tool and it is here we found out that Axis
> simply creates
> "empty" classes often with it's own interpretation of what is to be
> eventually called by the
> skeleton class and what's to returned by the web service.   Many
> documents suggest
> we ought to change the skeleton (implementation) classes /manually/ so
> that the correct
> Java classes are referenced and called!!!
> 
> Is there any option for the WSDL2Java to actually read the contents of
> the /original/
> Java classes which were used by the Java2WSDL tool to create the WSDL
> file and then simply call or reference those classes from the skeleton
> classes - avoiding
> any manual intervention?
> 
> Any ideas greatly appreciated,
> 
> Kind regards
> 
> Abdullah
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/