How about this.

We preserve the service impl class as it is, and allow ppl to associate the
a ServiceLifecycle implementation with a particular service using a service
level parameter in the services.xml file;

i.e. <parameter name="service.lifecycle.class">
com.xyz.service.MyServiceLifecycle</parameter>

Now the POJOness of the service impl class is preserved, and we could also
handle lifecycle related Axis2 specific implementations outside the actual
POJO which will contain only the relevant biz logic.

Thoughts?

-- Azeez

On 6/15/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:

Glen Daniels wrote:
>
>> So I'm -1 on it ..
>
> Of course this is a VOTE not a code change so it's a non-veto -1. :)

Absolutely :).

> Curious - would you acquiesce if the vote ends up in favor, or would you
> actually veto a commit if one occurred?

No way; but I assume that your commit would be a function of this VOTE ..
and since this is an API change consensus is needed to go forward IMO.

So far we have 3 people's opinions. I'd like to see many more thoughts
before we decide one way or the other.

Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Thanks
Afkham Azeez

http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760

Reply via email to