You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Afkham Azeez <af...@gmail.com> on 2007/06/14 16:35:46 UTC
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting methods
Hi Glen,
Forcing people to implement an interface might not be liked by some people.
One thing ppl do not like about EJBs is that it forces you to implement
interfaces. In the simplest scenario, a user can have a POJO, drop this into
Axis2 and expose it as a service, also the same POJO may be dropped into a
different container without having to include the dependent Axis2 libraries.
Forcing the user to implement the interface will tie the POJO to Axis2. Is
there a significant performance gain if an interface is used? How often does
the init/destroy method get invoked?
-- Azeez
On 6/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi folks!
>
> We're trying to resolve https://issues.apache.org/jira/browse/AXIS2-2785
> here at the hackathon. (see conversation at
> http://www.nabble.com/java.lang.NoSuchMethodException-tf3886972.html if
> you're interested)
>
> What it comes down to is this. Currently DependencyManager (why the
> heck is this called "DependencyManager"? It doesn't manage anything,
> and-- ok, that's another issue :)) is introspecting the service class to
> find the init(ServiceContext) and destroy(ServiceContext) methods. It
> has been suggested that instead of introspecting, we could simply have
> the service author optionally implement ServiceLifecycle, an interface
> containing these two methods. Then all the introspection code would go
> away to be replaced with code like:
>
> if (serviceObject instanceof ServiceLifecycle) {
> ((ServiceLifecycle)serviceObject).init(serviceContext);
> }
>
> Advantages - faster. Simpler. Less error-prone for developers (IDEs
> will help you implement the interface).
>
> So my proposal is that we do the following:
>
> 1) Add ServiceLifcycle interface, and code like the above. Also leave
> the introspection code for now.
> 2) Put a BIG BOLD notice in the release notes that we are now using
> the interface and you should switch to that rather than relying on
> method introspection.
> 3) Remove introspection code in 1.X (where X=4 or 5)
>
> Here's my +1. Are people OK with moving forward with this solution?
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting methods
Posted by Afkham Azeez <af...@gmail.com>.
I see your point. Here is my +1.
-- Azeez
On 6/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Afkham Azeez wrote:
> > Forcing people to implement an interface might not be liked by some
> > people. One thing ppl do not like about EJBs is that it forces you to
> > implement interfaces. In the simplest scenario, a user can have a POJO,
> > drop this into Axis2 and expose it as a service, also the same POJO may
> > be dropped into a different container without having to include the
> > dependent Axis2 libraries. Forcing the user to implement the interface
> > will tie the POJO to Axis2. Is there a significant performance gain if
> > an interface is used? How often does the init/destroy method get
> invoked?
>
> Please explain the difference between "forcing" the user to implement an
> interface, and "forcing" the user to implement a method that uses Axis2
> specific classes as arguments? AFAICS there is none. The point is that
> you can't implement "void init(ServiceContext)" without ServiceContext
> anyway, so it's tied to Axis2 anyway.
>
> Note that we're NOT suggesting that you MUST implement ServiceLifecycle
> to be a service implementation, btw! If you *want* to, it's cleaner
> than implementing random methods which then get searched for with
> introspection.
>
> It's a cleanliness issue, but I'd like to see it fixed.
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [axis2] [RESULT][PROPOSAL] ServiceLifecycle interface vs.
introspecting methods
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Here's the tally of this vote after 6 days.
+1 Glen
+1 Azeez
+0 Deepal
+1 Dims
+1 Srinath
-1 Sanjiva
As such the proposal passed with a 4/1 majority. Resolved in
http://svn.apache.org/viewvc?view=rev&rev=549086, which closes out
https://issues.apache.org/jira/browse/AXIS2-2785.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting methods
Posted by Afkham Azeez <af...@gmail.com>.
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 <sa...@opensource.lk> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting
methods
Posted by Deepal Jayasinghe <de...@opensource.lk>.
I am 0+ on this ,
we had that interface and we removed , now we are trying to introduce it
again.
Thanks
Deepal
> 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.
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting
methods
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface
vs. introspecting methods
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hey Sanjiva:
Sanjiva Weerawarana wrote:
> Furthermore, its more towards duck typing .. why force people to say "I
> implement x" when they already did that by implementing the method?
It's the other way around, for most of the devs I hang with anyway. You
do "implements ServiceLifecycle" and *then* you hit a hotkey in your IDE
which automagically implements the interface methods for you (aahh
tools!). That way you're guaranteed to get it right.
>> Note that we're NOT suggesting that you MUST implement
>> ServiceLifecycle to be a service implementation, btw! If you *want*
>> to, it's cleaner than implementing random methods which then get
>> searched for with introspection.
>
> I understand this totally but we are trying to force them by marking it
> deprecated and planning to remove the old approach in v1.3+.
The people we're "forcing" in that case would be the early adopters who
are already doing this the old way, not anyone who's newly implementing
- but it's a fair point.
> So I'm -1 on it ..
Of course this is a VOTE not a code change so it's a non-veto -1. :)
Curious - would you acquiesce if the vote ends up in favor, or would you
actually veto a commit if one occurred?
>> It's a cleanliness issue, but I'd like to see it fixed.
>
> I'm fine with keeping this issue open for post-1.3 discussion; it doen't
> meet the 1.3 bar for me. Of course my feeling about it is stated above;
> no interface.
Roger that.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs. introspecting
methods
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
>
> Please explain the difference between "forcing" the user to implement an
> interface, and "forcing" the user to implement a method that uses Axis2
> specific classes as arguments? AFAICS there is none. The point is that
> you can't implement "void init(ServiceContext)" without ServiceContext
> anyway, so it's tied to Axis2 anyway.
Yes, but this is the fundamental diff between Spring and EJBs. I *know*
there's no difference, but the developer community seems to have a
preference for just having to implement a method rather than having to
implement a method *and* flag that by saying "implements x".
Furthermore, its more towards duck typing .. why force people to say "I
implement x" when they already did that by implementing the method?
> Note that we're NOT suggesting that you MUST implement ServiceLifecycle
> to be a service implementation, btw! If you *want* to, it's cleaner
> than implementing random methods which then get searched for with
> introspection.
I understand this totally but we are trying to force them by marking it
deprecated and planning to remove the old approach in v1.3+.
So I'm -1 on it ..
> It's a cleanliness issue, but I'd like to see it fixed.
I'm fine with keeping this issue open for post-1.3 discussion; it doen't
meet the 1.3 bar for me. Of course my feeling about it is stated above; no
interface.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [VOTE][PROPOSAL] ServiceLifecycle interface vs.
introspecting methods
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Afkham Azeez wrote:
> Forcing people to implement an interface might not be liked by some
> people. One thing ppl do not like about EJBs is that it forces you to
> implement interfaces. In the simplest scenario, a user can have a POJO,
> drop this into Axis2 and expose it as a service, also the same POJO may
> be dropped into a different container without having to include the
> dependent Axis2 libraries. Forcing the user to implement the interface
> will tie the POJO to Axis2. Is there a significant performance gain if
> an interface is used? How often does the init/destroy method get invoked?
Please explain the difference between "forcing" the user to implement an
interface, and "forcing" the user to implement a method that uses Axis2
specific classes as arguments? AFAICS there is none. The point is that
you can't implement "void init(ServiceContext)" without ServiceContext
anyway, so it's tied to Axis2 anyway.
Note that we're NOT suggesting that you MUST implement ServiceLifecycle
to be a service implementation, btw! If you *want* to, it's cleaner
than implementing random methods which then get searched for with
introspection.
It's a cleanliness issue, but I'd like to see it fixed.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org