avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Phoenixs Deprecated features
Date Sat, 11 May 2002 10:36:29 GMT
> > I would like to see addition of support for CascadingConfigurations
> > together with the addition of extensions to the .xinfo file to contain a
> > default confituation declararation (which would bring Phoenix and Merlin
> > almost totally in sync). Any thoughts about how this can be achieved?
> A few. Currently I am working on trying to get decent interoperability between 
> Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has 
> slightly different needs there is also a bunch of common ground. Currently 
> the main things I am interested is getting together a single representation 
> of component meta data.

Funny. I was thinking about the same thing last weekend =)

> The types of component meta data I am thinking of is mainly;
> * lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is 
> singlethreaded etc
> * context: 
>    - Context Class
>    - Entrys in Context (both name of entry and type of entry)
> * service:
>    - services required by component 
> * configuration/parameters:
>    - schema+validaiton of Configuration/Parameters
> In each different container the info is represented differently. However what 
> I was thinking of was developing a set of standard javadoc tags and 
> processing the sourcefile using the XDoclet tool available at;
> http://sourceforge.net/projects/xdoclet
> This tool would generate the manifest files, blockinfos, possibly default 
> configurations and so forth in context of Phoenix/Merlin. 

This is a really neat solution. I was thinking about formalising
lifestyle interfaces, and giving them methods that throw
"OperationNotSupportedExceptions" etc.

Maybe a combination of the two is a good idea (where you lose the
metadata-related methods). I was thinking about writing some docs about
"lifestyle" anyway, as most of us grasp the concept but it is not
defined as such in the docs.

Thinking even further....we could also do with @contract for our
interfaces in general...I can see quite a few uses...

> With a different template you could use XDoclet to generate the descriptor 
> files for Fortress/ECM/Myrmidon.

If this is possible, it seems more logical that instead the descriptor
files should be more similar...just thoughts.

> >  Inital ideas are either (a) implict addition of default configuration
> > handling within Phoenix, or (b) the ability to declare an
> > alternative/pluggable configuration resolver.
> Technically is possible now. I could even add in plugin points to the deployer 
> if you really want this right away (And you could just create a custom 
> MerlinDeployer that uses CascadingConfiguration). 
> I was going to try address it in a global manner first but if you want me to 
> make it possible for you to overide default behaviour with 
> CascadingConfigurerr then it should be relatively easy. Just say the word.

well, there you go. Phoenix getting there, Merlin almost there, I'm
guessing Myrmidon as well as it is also your work...seems like I have
less to think about again.

BTW, crossposting to avalon-dev as this concerns excalibur & stuff as


- Leo

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message