Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Date: Mon, 28 Jul 2003 12:54:45 +0200
To: Avalon Developers Mailing List <dev@avalon.apache.org>
Subject: Re: [RT] Parameterized Lookups ?
Message-ID: <20030728105445.GC26319@managesoft.com>
References: <20030725145710.GC8451@managesoft.com>
 <3F21483A.6040709@apache.org> <20030725154041.GB9220@managesoft.com>
 <bg2o2d$qga$1@main.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bg2o2d$qga$1@main.gmane.org>
User-Agent: Mutt/1.5.4i
From: Marcus Crafter <crafterm@managesoft.com>

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.

Cheers,

Marcus

-- 
        .....
     ,,$$$$$$$$$,      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