avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 13:16:54 GMT
> From: Peter Donald [mailto:peter@realityforge.org]
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some 
> more work ahead of
> > us, as neither Context nor ServiceManager reflect this.
> Both are beneficial. Useful elements from context;
> data: 
>  - names (including component, partition and application)
>  - classloader(s)
>  - base deployment directory (potentially work directory aswell)

Keep in mind that a work directory can be a temporary directory
that is completely separate.

> services: 
>  - access to input streams of resources stored in deployment package.

I consider this data.

>  - access to proxying/interceptor chains for current block and ability
>    to construct new chains for objects you want to pass around

:/  Just make it a decent library.

>  - access to "manager" element for current application or 
> parts of current
>    application 

I have never yielded on this one point: A component should never, ever
be able to tell a container what to do.  Period.

The fact that the BlockContext has the "requestShutDown()" method is
a testimony to the disservice that having Phoenix-Dev separate from
the rest of Avalon-Dev.

The process of shutting down a container should be done by a management
system exposed to the administrator, but not from any child component.
I don't know if any of you have kids, but imagine one of them defiantly
telling you where to go....  It doesn't fly, and it doesn't work.  If
you allow your natural kids to run your lives your house would be in
chaos.  How can that work for components--esp. when some might be truly
evil or poorly written.

If there was a way to override System.exit(), I would do that to fully
prevent any component from forcing a shutdown.

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