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

[olivier brand]

Russel, see my <response> tags. Thanks for the "answers" anyway.

[EMAIL PROTECTED] wrote:

[EMAIL PROTECTED]"> 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>

<response>
If there is no way to express the implementation other than the default, then the skeleton class is useless.
In order to be useful, there should be a wsdd entry for the impl class.
For our own purpose, we are using the Impl class as a proxy class, we are picking up the "real"impl class using the init() method and then retrieving the class names through the ServletContext, it seems to be the most standard approach in a J2EE fashion.
</response>

[EMAIL PROTECTED]">

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>

<response>
I do not see the point there, other than saving extra data in the wsdd file.
</response>

[EMAIL PROTECTED]">

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>

<response>
Sorry for the unclarity of my question. I meant that if you add the ServiceLifecycle code in the skeleton, this class should not be overridden by the generator.
</response>

[EMAIL PROTECTED]">

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>

<reponse>
I removed the -S flag in the WSDL2Java and it works now. The init method is being called.
Without changing the code in the JavaProvider (see bellow), or any other Axis code, using the skeleton with a ServiceLifecycle is impossible.
</response>

[EMAIL PROTECTED]">

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>

<response>
Just trying to be as compliant with the specification as possible. I recommend you reading the JSR 109 from IBM: Web Services for J2EE, very good concepts around the JAX-RPC specification.
</response>

[EMAIL PROTECTED]">
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