avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Draft implementation: Custom Marker Proposal
Date Fri, 14 Jun 2002 06:01:52 GMT

Peter Donald wrote:
> Howdy ho,
> At 06:01 PM 6/13/2002 +0200, you wrote:
>>         Or, are you saying we should make the startup phase immutable and
>>         not extendable, but allow for access level extensions ?
> +1
> I spent ages trying to get this work. We went through several iterations 
> of Phoenix trying to enable this but it was an absolute PITA and massive 
> headache to maintain. The way I would recomend you implement container 
> specific behaviour (like Instrumentation etc) is via a 
> Container-specific context.
> ie Phoenix has a BlockContext via which it exports extra information to 
> blocks (if they want it) and also will support extra functionality in 
> the future.
> Note that I haven't read your proposal yet but my guess would be 
> something like the following would work
> interface CocoonContext extend Context
> {
>   InstrumentPoint getPoint(String name);
>   CocoonSession getSession();
>   File getWorkDirectory();
>   ///insert whatever actual parameters you need
> }
> Then your instrumentable component just does something like
> abstract class AbstractCocoonInstrumentable
>   implements Intrumentable, COntextualizable
> void context( Context c )
> {
>   CocoonContext cc = (CocoonContext)c;
>   setPoints( cc.getPoints() ); //Or however instrumnentable works
> }
> I have used the same pattern over and over again and it works well. What 
> do you think ? Does it work for you?

Not for me :-(

We have at least 2 types of interfaces:
- command interfaces
- service provider interfaces

The first type are Initializable, Startable, Disposable, etc.., and no 
Context-ComponentManager can supplant them.

The second type are supplantable by context-ComponentManager.

In my app, I extended the lifecycle to add a Saveable (ie save()),
which cannot be switched with a Context.

I think we need to address the need for an easy system to enhance the 
In James we will possibly need the Mailet interface in the lifecycle.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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