avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Implementing custom marker interfaces
Date Tue, 04 Jun 2002 11:22:26 GMT
Marcus Crafter wrote:
> 
> Hi All,
> 
> 	Hope all is well.
> 	
> 	In our project I recently delved into the world of creating custom
> 	markers specific for our particular application domain. I'd
> 	thought that IoC/SoC was an excellent programming paradigm, 
> and could
> 	be applied to our application in a greater context, not just within
> 	the standard avalon interfaces.
> 	
> 	It turned out to be easy to begin with but difficult to finish, and
> 	there seem to be lots of issues, at least to me :)
> 	
> 	What I wanted to do was define a custom marker interface 
> that would be
> 	checked for each time a component was accessed (ie. during 
> lookup()),
> 	and have a method defined in that particular interface called each
> 	time, appropriately.
> 	
+10, this is really a very usefull feature!

> 	The solution was to extend ECM's lookup() method in a subclass,
> 	however the first problem I found was that most application code
> 	specifies 'new ExcaliburComponentManager()' directly and needs to be
> 	changed	to use a derived class or made configurable to accept an
> 	arbitrary component manager class, sometimes in several places
> 	(eg. Cocoon, with my patch #8614 in bugzilla).
> 	
Yes, subclassing the ECM has another drawback if you have a CM hierarchy
(as Cocoon has :( ): if you simply override lookup() in your own CM you
delegate the lookup to the real CM which is either the parent class or
a parent CM in the hierarchy. But when you do a simple super.lookup()
you don't know who created the component.
If it is a parent CM, this component is completly initialized, if it
was the parent class, then we can apply our own marker interfaces.
This took me some time to get it working...

> 	The other issue I realized later is ECS, select() also needs to be
> 	extended, however this class incurs the same problem as ECM but more
> 	often as selectors are specified in roles files and java code. It's 
> 	also more of an issue if a custom selector has already been written
> 	(eg. Cocoon, with it's ExtendedComponentSelector).
> 	
> 	So, subclassing doesn't seem to be the solution.
> 
Yupp.

> 	Another issue is that it seems to be quite difficult to insert a
> 	custom marker mid-way into a component's startup/destruction phase.
> 	I know this one won't come up as often as the others above, 
> but as an
> 	example Lief had this problem supporting the Instrumentable
> 	marker interface.
> 
> 	I think we still need a way to ensure the defined order of the
> 	standard avalon startup/destruction interfaces, but it could be 
> 	useful to include the ability to insert custom ones during
> 	component startup (or should we consider the startup/destruction
> 	process to be immutable ?).
> 	
> 	I've taken a look at both the ECM/ECS and Fortress code, but both
> 	don't seem to cover this space just yet (?). I'm looking for ideas
> 	about how to add such functionality to our existing classes that
> 	doesn't require excessive subclassing of handlers or component
> 	managers.
> 	
+5

Carsten

> 	Any ideas ? thoughts ?
> 	
> 	I'm currently mulling over the thought of a potential solution that
> 	involves modifying component handler/factories so that they 
> can accept
> 	a configurable startup/destruction sequence, but since I'm still an
> 	avalon novice it would be great to hear comments/thoughts ? :)
> 	


--
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