Re: Follow up on the Skeleton bug and ServiceLifecyle, axis beta 3

[butek]

You've got a lot of questions here.  I'll try to answer them inline below between <rjb>...</rjb>

Russell Butek
[EMAIL PROTECTED]


Please respond to [EMAIL PROTECTED] 
To:	[EMAIL PROTECTED]
cc:	[EMAIL PROTECTED] 
Subject:	Re: Follow up on the Skeleton bug and ServiceLifecyle, axis beta 3




Russel,

Thanks for the hint. Nerverthelessthis behavior is not the expected oneas
you pointed out yourself.
Quick question related to the skeleton. Since you can pass another
implementation, how can you pass the implementation class to the skeleton ?
(the default being the generated impl).

<rjb>
This is a minor hole in our implementation.  The idea is that, if you want to use a special implementation, then you don't generate a skeleton.  There is no way, short of changing the skeleton, to get it to point to something other than the default impl.
</rjb>

I have not found anything in the documentation stating how to pass the impl
class within the wsdd descriptor (I assume this class can be configured
there).
Other question related to the skeleton, what is the role of:
getOperationDescs() ?

<rjb>
getOperationDescs returns meta-data about the operations.  If you have a skeleton, this meta data is on the skeleton.  If you do not have a skeleton, this meta data is in the deploy.wsdd.
</rjb>

Now, if the skeleton implements the ServiceLifecycle  interface, this class
should not get overridden when I apply the WSDL2java, the Impl not being
overridden,

<rjb>
I don't see the correlation.  Why should the skeleton NOT be overridden?  The Impl is designed to be added to (it's a template).  The skeleton should not be changed (it is NOT a template).
</rjb>

 it seemed to me a good idea to add the ServiceLifecycle stuff
there (The ServiceLifecycle exists to allocate/free resources. I forsee
different implementation have different need in term of resource: DB vs
File, .....)

<rjb>
Did you give it a try?  Did it work as you expected?
</rjb>

Maybe, a viable solution would be to add a public method in the skeleton
interface returning the impl, then the JavaProvider could test:

if (serviceObject != null)
{
serviceObject = (serviceObject instanceof
org.apache.axis.wsdl.Skeleton) ?((Skeleton)serviceObject.getImpl
()):serviceObject;


if(serviceObject instanceof ServiceLifecycle)
((ServiceLifecycle)serviceObject).init(null);


}

Russel, is it a viable solution or does it go against the skeleton concept
?

<rjb>
That's a possibility.  It doesn't disturb the skeleton model.  But like I said, I'm not a lifecycle expert.  I would hope one of the other AXIS developers might respond (but since we're all rather overloaded right now, I'm afraid it's unlikely).
</rjb>

Olivier










[EMAIL PROTECTED]
om                   To:     [EMAIL PROTECTED]
cc:
07/13/2002           Subject:     Re: Follow up on the Skeleton bug and ServiceLifecyle, axis beta 3
06:46 AM
Please respond
to axis-user












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