avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: a view of the Avalon Container
Date Tue, 20 Aug 2002 02:24:58 GMT


Marcus Crafter wrote:

>>I have taken a look at Merlin (these classes:
>>http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/assembly/src/
>>java/org/apache/excalibur/container/lifecycle/ )
>>and as far as I can see, the pluggable pipeline stages (or phases, or 
>>whatever), are limited to act on (1) the component/object and (2) the 
>>Context.
>>    
>>
>
>		Yes, the initial idea was that the pluggable lifecycle stages
>		would operate on the component, using whatever objects they required
>		from the Context object if any.
>
>  
>
>>So... not only will the component have a type specifier that explains 
>>what context entries it requires and what special lifecycle handlers 
>>it requires - those handlers will also have a context requirements.
>>    
>>
>
>        Yes, this is true as well. The Fortress implementation doesn't
>		check any context entries, however IIUC the Merlin implementation
>		treats the handlers as regular Components with validation, dependancy
>		resolution, etc.
>
>  
>
>>So if you have a SpiffyLifeCycleStage that makes components all spiffy 
>>as they come through it, how is that SpiffyLifeCycleStage going to do 
>>it without support from the container to put a Spifficator (the means 
>>to make a component spiffy) in the context?
>>    
>>
>
>        My original idea was that the context be filled with these objects
>		(the Spifficator for example) before the application starts
>		operating - as is done in Cocoon - I know it's not the most optimal
>		solution but something I could work with at the time.
>
>		I brought this up on the list several weeks back and Berin came up
>		with the Session idea which is an alternative solution for storing
>		such transient objects (more info under
>		http://marc.theaimsgroup.com/?l=avalon-dev&m=102742811501755&w=2).
>
>  
>
>>If you have a PersistentLifeCycleStage, how are you going to obtain 
>>the persistence mechanism if the container doesn't give it to you via
>>the context?
>>    
>>
>
>        If not via the Context, via the CM in Merlin (and I presume in fortress
>		too in time) or the Session object described above, or some non-OO
>        way (ie. static method, singleton getInstance(), etc)
>
>  
>
>>The problem with populating the context with any non-constant entries 
>>(such as a Spifficator) has already been discussed and found to have 
>>no solution short of mind-reading the programmer and sprouting new code 
>>on startup/linking.
>>    
>>
>
>	    I think this must have been before my time here, is there a reference
>		you can send me so I can read up on what was discussed ?
>

I was, but not so long ago.
A couple of prominent peope here said is was impossible - however, even 
before those statements solutions already existed (and remain) in a 
class under the excalibur/configuration package - ContextFactory.  Form 
there, the Merlin implemetation leveraged the meta-info costraints 
together with a new meta-data context declaration model to deliver 
something even simpler for the end user. Contary to popular belief, 
context is managable.  Unfortunately Merlin is the only Avalon container 
to address this.

>
>  
>
>>At the moment, the lifecycle extensions appear to be shiny new features
>>that while nice in theory are useless in practice. I'm afraid that any
>>container trying to implement them in a useful way will (1) never be
>>completed and (2) implode under its own weight. It's just too much "do 
>>everything", too much genericism, in it.
>>
>>Miscellaneous issues:
>>
>>  + Will the lifecycle handler need a component/service manager?
>>    How will a DB-persistence handler work? Will it use the Excalibur 
>>    Datasource component? How will it access it?
>>    
>>
>
>	    Initially lifecycle handlers were just classes, after looking at
>		Stephen's component-oriented approach in Merlin I think there's
>		advantages having the handlers be components. A handler that is
>		a component would be able to access your DB-persistence component
>		described above.
>

And as a side-effect - masively simplifying the container implementation.

>>  + If the handler requires another component, has a context and surely
>>    will need a configuration, what is the difference between it and
>>    a component?
>>    
>>
>
>	    If the handler requires all that's listed above, then nothing - but
>		remember lifecycle extensions are trying to let you reuse code across
>		*multiple* perhaps unrelated components, like the standard ones do.
>
>		If you only needed the handler 'component' once, you wouldn't worry
>		about defining a new lifecycle stage for it. But imagine the case
>		when you have many components that you want to add such
>		'component decorating' functionality to.
>
>		It's possible to add the functionality by looking up a depdendent
>		component, or call a static method or access the context, etc, in all
>		of the component implementations - and this works if the components are
>		related via base classes, etc, but if the classes aren't related
>		then you end up duplicating code.
>
>		eg. imagine if LogEnabled didn't exist and each component had to 
>		access some 'Manager' class to get a Logger object. It's manageable if they all
>		extend some base class that does the work, but if not, the code accessing
>		the 'Manager' class needs to be copied all over the place. It's much nicer
>		if the CM passes the Logger to the Component, plus follows SoC and is one
>		of the excellent advantages when one uses Avalon.
>
>		This was what I wanted to solve for domain specific components that
>		had requirements like the need for LogEnabled across many unrelated
>		components, following the SoC/IoC model we already advocate.
>
>		Each domain has its own requirements, and can implement their own
>		interfaces applicable to their needs.
>
>		In our project for example, we have many classes that perform database
>		access. The decision as to which database you use depends on who you
>		are, where you are geographically located, and some other factors that
>		make accessing your database a little complicated.
>
>		I wrote the code to select the applicable database for the current
>		thread, but had no easy way to share this code amongst other unrelated
>		classes.
>
>		Now I've defined a Queryable interface with an extension class that calls
>		upon the interface at access time to set the correct database for the
>		current thread,	and the code which does the database selection is now
>		completely localised to one method on the extension class. For this,
>		extensions were very useful in helping me reuse that code.
>
>		I'm sure TIMTOWTDI, but I wanted to follow what we already advocate (ie.
>		the SoC approach). That way, developers in our project already familiar
>		with the Avalon concepts can easily grasp how to use the new extensions
>		when writing our components.
>
>		In particular its useful when using tools like Cocoon where you don't
>		have as much control over what base classes are being extended.
>  
>

An excellent summary.

Cheers, Steve.

>  
>
>>  + Go back to the final proposal for A5. Doesn't it solve everything
>>    by allowing/requiring you to specify handlers/factories for
>>components?
>>    
>>
>
>        Almost, I looked at handler/factory specification as a possible solution,
>		but it required IMO too much subclassing to handle extending the 4 phases of
>		a components life (ie. access release create destroy).
>
>		Most handlers use the same factory - allowing you to create a custom
>		factory that handles create & destroy extensions, but the operations of
>		accessing & releasing a component are done by the component handler
>		(PoolableComponentHandler, PerThreadComponentHandler, etc) which means
>		a new subclass for each set of extensions for each handler.
>
>		Hope that helps mate ? :)
>
>		Cheers,
>
>		Marcus
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message