avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [PROPOSAL] lifecycle release
Date Sat, 15 Mar 2003 10:24:42 GMT
Noel J. Bergman wrote:
>>Pete definately has a point wrt interceptor architecture (it really
>>is the "next big thing", except it is become the "current big thing"
>>fast).
> 
> Would you comment on your view of the relative technical merits of the two
> proposals that are on the table, the interceptor architecture and the
> lifecycle proposal?

That question is too difficult to answer. There is one working tested 
implementation with a setup similar to the one avalon uses for the 
lifecycle management, ie the lifecycle package. It works well, but I'm 
not sure about performance figures, extensibility, etc.

There is no working implementation that I know of which is easily 
compatible with existing avalon code which manages lifecycle materials 
(there's lots of implementations, but the only one I know of which 
doesn't come with a massive amount of cruft like a J2EE server is 
nanning (http://nanning.sourceforge.net/), and I don't think that is 
ready for use; I'm not sure how for xinvoke (over @ spice) has 
progressed, but it is moving so fast I can't keep track), so a 
comparison is difficult.

In theory, an interceptor architecture could radically improve 
performance, design, scalability and pluggability of avalon containers. 
I've been experimenting with event-based AOP, and results are amazing, 
but it'll be a few months before any such setup will actually be 
workable in java.

IMO, the thing to do here is ensure that it will be possible in the 
feature to provide a 'wrapper' around the lifecycle package which fits 
in an event- or interceptor-based architecture. The way I see it, this 
is trivially simple, and the suggestion of the other Leo to make the 
methods return Object should make it even easier, but I'm not sure 
that's neccessary.

An interceptor usually looks something like

class Interceptor
	void setup( [Context] )
	void intercept( Invocation )

where setup( [Context] ) can be implemented by using the constructor, or 
by having an active interceptor looking things up using jndi, or by 
having some kind of initialize/contextualize setup, or by using aspects.

It should be trivial to write a CreatorInterceptor:

class CreatorInterceptor implements Interceptor
	void setup( Context context )
		m_context = context
		clazz = context.get( "class" )
		class = Class.forName( clazz )
		m_creator = class.newInstance()
		m_creator.contextualize( context )
		m_creator.initialize()

	void intercept( invocation )
		context = getContext( invocation )
		if( invocation.method == create )
			m_creator.create( invocation.target, context )
		if( invocation.method == destroy )
			m_creator.destroy( invocation.target, context )

and something similar for an AccessInterceptor.

That way, it would be easy to support the lifecycle package in an 
interceptor-based system. So I don't see why the two approaches are 
incompatible in any way.

cheers!

- Leo



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


Mime
View raw message