----- Original Message ----- 
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: "Avalon framework users" <[EMAIL PROTECTED]>
Sent: Wednesday, October 29, 2003 2:26 PM
Subject: Re: [Fortress/Merlin] equivalent of EJBHome interface


> I think the agreeable bottom line is that it very much depends on your 
> requirements.
> 
> I have the feeling that you are fishing for something like;
> 
> "I want to use the components A, B and C that are already available, but I 
> can't provide the Configuration for each of these until some point later in 
> time."
> 
> Then your choice is very much falling towards nested Merlin instances.
> 
> If you don't have a bunch of components, then there are many ways to attack 
> the problem, and I am the first to acknowledge the KISS factor, and "Broker 
> Pattern" is one such simple way of doing things.
> 
> I think that if you provided a complete description of what you have in mind, 
> I think Stephen can provide you with a spot on way to do it.
> 
> 
> Hmmmm, Looking back at your original post, I suddenly got the eire feeling 
> that you somehow draw an equal sign between an EJB and a Avalon Component. 
> Tell me it wasn't so.
> Avalon Components are not data containers like EJBs, but more like functional 
> subsystems. An Avalon Component will typically consist of a whole bunch of 
> associated classes, some providing function, some data containment and some 
> both. J2EE doesn't have the notion of Components.

Ugh ... I'm not some top notch developer to understand everything you've written 
above, and my knowledge of EJB is rather small, but what I had in mind is -
I would like to have pooled component, or for sake of simplicity, let's say singleton 
component which uses .xconf configuration, depends on other components, implements 
standard lifecycle avalon methods, or in other words, uses all commodities of avalon 
container, BUT before being given to client code by ServiceManager.lookup(), it would 
need one additional argument configured during runtime. I never worked with nested 
containers or lifecycle extensions, but I guess that would be the way to go ...

- Vjeran


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to