Re: [RT:A5] What are the _real_ concern areas?
Berin Loritsch <[email protected]>
| Newsgroups | gmane.comp.jakarta.avalon.apps.devel |
|---|---|
| Message-ID | <[email protected]> |
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.
:P
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