Making the Skeleton extend the Impl is not a good idea. One of the reasons to use a skeleton is so you can plug in ANY implementation, not just the generated one. I would much rather the Skeleton implemented ServiceLifecycle directly, though I don't know the life cycle stuff well enough to know whether that's a good idea. (if you've got a few free cycles, you could give this a try and let us know the results)

Do you have a reason you MUST use the skeleton? You don't have to. You could use the impl directly (don't use the --skeletonDeploy flag on WSDL2Java).

Russell Butek
[EMAIL PROTECTED]

Please respond to [EMAIL PROTECTED]

To: axis <[EMAIL PROTECTED]>
cc:
Subject: Follow up on the Skeleton bug and ServiceLifecyle, axis beta 3



I found a solution fixing the generated skeletons:

Instead of proxying to the implementation (The SoapBindingImpl), why not just extending the SoapBindingImpl ?
I have done it and it works like a charm.

So you would have something like this:

public class MySoapBindingSkeleton extends MyServiceSoapBindingImpl implements MyService, org.apache.axis.wsdl.Skeleton

And of course:

public class MyServiceSoapBindingImpl implements ServiceLifecycle

And then remove the impl class variable and the proxuing code which is useless since it does not add any extra features than just proxying.
In the result, you will have something working and it will be slightly faster by bypassing the proxy design pattern.

Olivier

Reply via email to