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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
