avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT:A5] What are the _real_ concern areas?
Date Wed, 18 Dec 2002 03:46:39 GMT
Peter Donald wrote:
> On Wed, 18 Dec 2002 14:18, Berin Loritsch wrote:
>>interface ServiceManager
>>      Object lookup( String urn ) throws NoSuchValueException;
>>      void bind( String urn, Object value )
>>              throws AlreadyBoundException;
>>Any thoughts or inputs?
> JNDI does it better and is a standard so if you want that sort of interface 
> then JNDI should be the way to go. In which case JNDIKit is already 
> implemented so may aswell use that ;) If you were to go this way then you may 
> aswell just have one lifecycle interface

:)  Don't forget all the other patterns in Sun's BluePrints, et. al.
that actually hide the context from the component view...

> interface Component
> {
>   void init( Context c ) throws Exception;
>   void destroy();
> }
> And standardize on naming of entries in context. However as J2EE patterns 
> document already defines a namespace then that should be used as 
> recomendation.

That is a possibility.  It brings me back to our discussions a couple
years ago.  The J2EE/JNDI specs are not practical for what Avalon
solves IMO.

> If that route is taken - is it really Avalon anymore?

It depends.  The thing is that I would like something that scales from
J2ME to J2EE--which kind of precludes the JNDI monolith.

It can't be EJB because Avalon components solve a need that sits
somewhere in between EJB and Servlets.  I.e. they are fine-grained
components like EJBs, but they have a fairly liberal environment
like Servlets.

> Things you put in "Active Use" are only relevent to request based 
> architectures where the container demarcs the request boundardaries. Where 
> this is not true then you have just unecessarily limited the types of 
> containers.


A component can still be in "Active Use" without implementing any of
those interfaces.  Those are there to assist a component that is managed
in that way.  From what I understand, Merlin already supports the
Suspendable interface (but not the Re* interfaces).  I have always had
the intention of supporting the Suspendable interface in Fortress, but
never really got there.  What a difference it makes when a company funds
your development time....

Anyway, I think the Listener approach works best for replacing the need
for the Re* interfaces.  Whether you are request based or not, a
component can make use of the notification.

Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message