avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Sutic <leo.su...@inspireinfrastructure.com>
Subject Re: organisation of avalon subprojects
Date Sun, 30 Jun 2002 22:24:23 GMT
Stephen McConnell wrote:
 > Go back to MicroContainer and rip out the lifecycle processing
 > code - put in place something from a common codebase - reduce
 > the duplication.

Agreed - if containerkit becomes the common ground for all containers then 
this should be done. The reason it hasn't been done yet is because I wanted 
to avoid dependencies as far as possible - you should only need the 
MicroContainer JAR. Stupid reason? Maybe. If so, I will correct this.

 > MicroContainer has nothing to support components with formal
 > dependencies.

I do not understand what you say here. It is true that MicroContainer does 
not provide any kind of functionality to intelligently wire together 
components based on metainfo associated with the components. All that is 
done programmatically. But I see no problem with actually running the 
component. As you have investigated this - could you say what in the 
environment set up by MicroContainer for the component it is that causes 
the component to fail?

If there are components that simply can not run inside MicroContainer I 
need to understand what MicroContainer can not handle. The idea is that 
while all components should work in Phoenix, not all need to work in 
Fortress, and not all in MicroContainer. Just that all that work in Micro 
works in Fortress, all that work in Fortress work in Phoenix and so on. Is 
it the ability to extends the lifecycle that you lack?


1) I'm stupid. Can you be more precise about what you mean by "formal 
dependencies and services"?

Anyway, from what I guess formal dependencies and services are:
True. It is utterly clueless when it comes to this, and that was done on 
purpose. The purpose of MicroContainer was to provide a very 
low-committment alternative for Avalon. In particular, it should be 
possible to create components via static factory methods, much like one 
creates SAX parsers in JAXP. All to make it as similar to standard Java as 
possible, and have as utterly minimal impact on the architecture of the 
system it is used in as possible.

I remember in Avalon-Users that one person had given up on Fortress and 
hacked *Tweety* to solve his problem. This would indicate that formal 
dependencies and services aren't vital, or else my understanding of 
Tweety's level of sophistication is grossly wrong.

 > What about Merlin? - Shouldn't it be included with the three
 > musketeers - or I should I head over to the axis-of-evil?

Depends on whether you want to include SOAP processing in Merlin, I guess...

 > I do want a common container solution

Me too, but I do not see how that can be done. What you describe has a very 
high committment threshold. Basically: Create your entire app the Avalon 
way, or forget it. This was the root of the three-container approach: Since 
Avalon comes with so many strings attached, provide different containers, 
where at least one came with little or no strings attached. That one was/is 

 > Can you provide a summary of the different "components" that exist in 

  + Cache - a caching framework, interface and impl.
  + DataSource - a DB connection pool.
  + SourceResolver - a unified way to access data via URIs.

 > Very limited validation - no enforcement of a formal compoenent
 > defintion - usefull for lifecycle handling.


 > This has to be solved - existance of different semantic approaches
 > to component management mean that components are designed
 > and implememtated today relative to a target container family. We
 > have two semantic models - the ECM/Fortress/MicroContainer model
 > and the containerkit/Phoenix/Merlin. Either of these two approaches
 > must die or we must make a formal distrinction between them and live
 > with the consequences.

Is this the component-as-service difference? I.e. in 
contaierkit/Phoenix/Merlin all components are what the ECM world calls 

Finally, as you say MicroContainer must sometime be rewritten and reworked. 
That is not something I didn't already know. But could you tell me in what way?


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