axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [axis2] Improvements to Service life cycle in handling
Date Mon, 18 Sep 2006 02:13:26 GMT
No I don't think that's a good approach: That basically says we couldn't
agree so we did both. Defining the interface and not using it doesn't
make sense; what I'm suggesting is to inject the extra info to the app,
which is of course very popular as the way to get data into an app.

Sanjiva.

On Sat, 2006-09-16 at 14:57 -0400, Davanum Srinivas wrote:
> Sanjiva,
> 
> How about this? We define the interface, If people want to use it,
> they can. But our code will be smart enough to reflectively look for
> the method+parameters and call it even if the class does not implement
> the interface. An interface is good for documenting the capabilities
> in a easy to understand form for our users.
> 
> -- dims
> 
> On 9/16/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> > (Deepal you forgot the [axis2] on the subject! For others who missed the
> > rest of the thread; please go look in your axis-dev folder.)
> >
> > I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
> > for the features it has- it should be ServiceSessionLifecycle: what its
> > doing is allowing you to be notified when the session is inited and
> > destroyed and also when an operation context is created within that
> > session (which happens multiple times within a service session). So its
> > even more than ServiceSessionLifecycle- its that plus operation context
> > notification.
> >
> > I'm very uncomfortable with calling the other interface Service. What
> > its really doing is notifying the service impl logic when the service is
> > inited/destroyed. So its really ServiceLifecycle.
> >
> > How about this- rather than putting these methods into an interface and
> > asking people to implement them, let's have these methods documented and
> > then reflectively call them if they're there. The advantage of this
> > approach is that it can work even for non-Java services. Suppose a
> > service is implemented in JavaScript or Groovy- we can let that message
> > receiver do whatever it needs to do the right thing. Having a Java
> > interface name is Java-specific.
> >
> > Performance-wise, the startup(AxisService,ConfigurationContext (I
> > presume)) and shutdown() are only called on loading/shutdown, the
> > init(ServiceContext)/destroy(ServiceContext) is only called once per
> > session. and setOperationContext is the only one that's costly because
> > we'd have to reflect to check whether the method is there and only call
> > if its there. (Catching the exception is more costly!)
> >
> > So, my proposal would be to document these methods and invoke them at
> > the right time if they're there. No interfaces.
> >
> > Sanjiva.
> >
> > On Fri, 2006-09-15 at 09:29 -0400, Tony Dean wrote:
> > > Can we fully document the logical semantics behind each method?
> > >
> > > init(ServiceContext) - To me this use to mean application init.  Now it means
session init.  However, when running scope="Application", it is analogous to application init
since you will only have one session;  but, still probably not appropriate to think in those
terms.
> > >
> > > How should an application use this method?  A session use-case would be nice.
> > >
> > > destroy(ServiceContext) - inverse of init()
> > > Use-case?
> > >
> > > setOperationContext(OperationContext) - per call.  The messageContext can be
obtained to gain per call instance information.
> > >
> > > StartUp() - one time initialization... DB connections etc...
> > > Shutdown() - inverse of StartUp()
> > >
> > > Any more insight or corrections to pattern usage would be grateful...
> > >
> > > Thanks.
> > >
> > > -----Original Message-----
> > > From: robert lazarski [mailto:robertlazarski@gmail.com]
> > > Sent: Friday, September 15, 2006 8:49 AM
> > > To: axis-dev@ws.apache.org
> > > Subject: Re: Improvements to Service life cycle in handling
> > >
> > > That makes sense to me. I've been using startUp() and it doesn't really fit
with the other methods of the interface in its current form. +1 for 1.1 since its interface
changes and it'd be better to do it now.
> > >
> > > One question: Currently you need this in services.xml to get startUp() to invoke:
> > >
> > > <parameter name="load-on-startup" locked="false">true</parameter>
> > >
> > > I plan on testing this when its ready ... since the spring tutorial depends
on it ... so I thought I'd ask if the services.xml param will remain the same.
> > >
> > > Thanks,
> > > Robert
> > >
> > > On 9/14/06, Deepal Jayasinghe <deepal@opensource.lk> wrote:
> > > > Hi All;
> > > >
> > > > Currently we have an interface called Service and which has few
> > > > methods that are used to manage session (or else user can add those
> > > > method into service impl class w.o implementing the interface). And
> > > > that interface has the following methods ;
> > > >
> > > > - startUp
> > > > - init
> > > > - setOperationContext
> > > > - destroy
> > > >
> > > > Three of them are for managing service life cycle ;
> > > > - init - will be called when the session start
> > > > - setOperationContext - immediately before calling actual java method
> > > > - destroy - will be call when the session finishes
> > > >
> > > > Remember all those method work if and only if you use Axis2 default
> > > > message receiver or you code gen.
> > > >
> > > > The method startUp is not session related method , which is useful
> > > > when you want to initialize database connections , create thread etc
> > > > ... at the time when you deploy the service. In the mean time
> > > > interface name Service is bit confusing to me AFAIK it should be
> > > > ServiceLifeCycle. And having method like startUp in that interface confuses
the users.
> > > >
> > > > So how about the following changes ;
> > > > - Rename Service interface into ServiceLifeCycle
> > > > - Then remove startUp method from that interface.
> > > >
> > > > There should be a some other interface (like Module interface) and
> > > > which should be optional as well , to have the method startUp. If
> > > > someone want to open DB connection or anything at the time of service
> > > > deploying , then he need to implement that interface (and for me which
> > > > is identical to Module interface). So with this change service element
> > > > inside the services.xml will be change to following
> > > >
> > > > <service name="foo" *class="implementation class of the interface "*>
> > > > <parameter name="ServiceClass">ServiceClass</parameter>
> > > > </service>
> > > >
> > > > Here the class attribute is optional , so if someone want to have
> > > > loadonStartup feature then he need to implement the Service interface
> > > > (new one) and put the impl name as the class attribute. This is very
> > > > useful if your service implementation class is not java (if you are
> > > > writing a groovy serice).
> > > >
> > > > So new Service interface will be look like follows; public interface
> > > > Service{ //will be called when service is deployed public void
> > > > startUp(ConfigurationContext configctx, AxisService service); //will
> > > > be called when Axis2 server showdown or when service removed from the
> > > > system public void shutDown(ConfigurationContext configctx,
> > > > AxisService service); }
> > > >
> > > > And ServiceLifeCycle interface will look like below;
> > > >
> > > > public interface ServiceLifeCycle {
> > > > public void init(ServiceContext sc);
> > > > public void setOperationContext(OperationContext operationContext);
> > > > void destroy(ServiceContext sc); }
> > > >
> > > >
> > > > I am +1 on doing this for Axis2 1.1 :)
> > > >
> > > > Suggestions ........
> > > >
> > > > Thanks
> > > > Deepal
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message