avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@managesoft.com>
Subject Re: [RT] Parameterized Lookups ?
Date Mon, 28 Jul 2003 10:54:45 GMT
Hi Leo,

Hope you enjoyed your holidays. :)

Thanks for taking the time to list some alternative approaches!

On Mon, Jul 28, 2003 at 10:49:20AM +0200, Leo Simons wrote:
> think of seperating various types of constructor arguments for your comp 
> into the comp configuration, the comp dependencies, etc etc. The URI is 
> logically part of the client component configuration, right? Jason van 
> Zyl did this in plexus with the Configurator pattern:
> interface ServiceBroker extends ServiceManager
> {
> 	Object lookup( String role, Configuration configuration );
> }

Interesting approach - I remember when Jason was talking about dynamic
reconfiguration of components. This must be how he achieved this.

> the easy way out is to not make everything into an avalon component, but 
> have an avalon component provide you with the worker class:
> interface MyComponentManager
> {
> 	String ROLE = MyComponentManager.class.getName();
> 	Component newInstance( String URI );
> }
> mcm = (MyComponentManager)m_sm.lookup( MyComponentManager.ROLE );
> component = mcm.newInstance( m_configuration
> 	.getchild( "component-uri" ).getValue() );

This probably suits my application the best - I should have realized this 
sooner as it's similar to the approach the SourceFactories use to create 
Source objects.

In my app though the URI is created dynamically - hence the need to set it
dynamically, but that could still work with the above of course.

> the clean way out is probably to use a lifecycle extension to decorate 
> your component with transaction support and make the client component 
> configuration part of the transaction state.

I think this is also what Leo Sutic was describing in another reply to my
email. It seems to be similar to the initial interface I had in that I have 
to set the URI via a set* method, but I like the use of ThreadLocals to 
essentially remove the need for Factory components - brilliant :)

If I used a lifecycle extension to set the transaction configuration though, 
do you think it would still be possible to set the configuration 
dynamically from data built at runtime?? 

Thanks again.



     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&

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

View raw message