On Thu, 19 Dec 2002 13:21, Adam Murdoch wrote:
> On Wed, 18 Dec 2002 01:45 pm, 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
> >
> > interface Component
> > {
> > void init( Context c ) throws Exception;
>
> Context here is a JNDI Context, yes?
yep.
> > void destroy();
> > }
>
> Where would start(), stop(), suspend(), resume() and re*() fit into this?
start() collapses into init()
stop() collapses into destroy()
suspend/resume + re* continue to be academic discussion points that have yet
to be well implemented.
> How about lifecycle extensions?
What about them?
> I'm not sure that collapsing information delivery into a single lifecycle
> method, means we have to throw away all the remaining lifecycle methods.
> Maybe we should. Maybe we shouldn't.
The most important thing about a framework is consistency. If we are going to
remove SOC from lifecyle then we should do it consistently and remove it from
all lifecycle. A splissplodge framework is much worse than no framework.
It basically comes down to whether you want fine grain components or
monolithic components. Avalon/Framework does fine grained and thus allows a
lot broader range of applications and more intelligent containers. However
monolithic containers are much easier to program to.
ie The container can detect if object is configurable and if it has a Relax
schema defined. If it does not then I can warn the user that they should
define one. This ability is lost under the monolithic approach. Some
component types also explicitly allow some lifecycle stages (ie Loggable) but
disallow others (ie Serviceable/Composable or Configurable/Parameterizable).
This would not really be doable under the monolithic system except by return
null.
> > If that route is taken - is it really Avalon anymore?
>
> Does it matter?
yep. Other frameworks are valid but they aren't Avalon.
> > 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.
>
> Can you explain this a little more? How does it limit the types of
> containers?
For ages we have talked about the idea of "Transactions" though used in
various different terminology.
Essentially the container makes a request to a component and may start a
Component Transaction (CT) when the request completes the CT is closed and
all resources associated with CT are released. Resources get associated with
CT if they are aquired/using in the context of CT. In a pure CT container
scenario (such as Cocoon) then this would mean that components would not have
to jump through the hoops they have to do now to ensure efficient usage of
resources. For systems that can have long running CTs there needs to be some
way for component writers to manage nested CTs. There is various ways of
doing this. From manually doing it now ala Cocoon which leads to much
increased complexity to transparent declarative mechanisms where container
intercepts all inter component comms.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
