Other interceptor implementations --------------------------------- Some direct links for comparison:
http://cvs.apache.org/viewcvs.cgi/jakarta-hivemind/framework/src/java/org/apache/hivemind/ http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/aop/ http://cvs.sourceforge.net/viewcvs.py/aopalliance/aopalliance/src/main/org/aopalliance/ https://dynaop.dev.java.net/source/browse/dynaop/src/dynaop/ http://cvs.codehaus.org/viewcvs.cgi/nanning/src/main/org/codehaus/nanning/?root=nanning
make sure to look at the Interceptor or MethodInterceptor class in all of these, how they are implemented in the examples, and how interceptors are matched to methods/components.
Disclaimer ---------- hammett wrote:
Please consider the work that has been done, I'll issue a vote soon (before enter the plane) ;-)
I've read through the code once. No attempt at compiling or using or understanding it fully just yet ;)
Event -----
EventManager getEventManager();
In general in cases like this I would rather see this in a seperate interface. Introducing a new method on a public interface is a bit tough, and here we can avoid it. ie
interface EventManagerProvider
{
EventManager getEventManager();
}class InterceptorContainer extends DefaultContainer
implements EventManagerProvider { ... }that said, we've got this event framework (d-haven event) we're using in other parts of the code. I think it would be good to use it consistently for events. Is that possible here? Mixing swing-like events with OO-style events seems like a recipe for confusion...
I've fallen in love with this general principle that its good to write things in pure java and then when you introduce things like doc tags or xml files this just delegates to the java stuff. Fortress doesn't do this right now, but I'd definately like to introduce it at some point. Let's try and make sure that remains possible :-DMetainfo --------
Metainfo could be a nice way to declare some special behavior of your class (service implementation) and its methods. Fortress already use metainfo at some extend. What I've done was to increase its support without changing the current behavior. So now, during the container start up, the container initialize what I've called ExtendedMetaInfo. This interface exposes all attributes related to the class and its methods.
Do you think it would be possible to just reuse the MetaClass Attribute class and access methods? For example DefaultInterceptorManager.obtainComponentFamily() could just use
Attributes.getAttributes( method );
At any time your component can access the ExtendedMetaInfo if it looks up for MetaInfoManager role.
why? Isn't the metainfo supposed to be directed at the container, and the component is configured using Configurable semantics?
Metainfo Collector ----------------- The collect-meta task now loads and persists the class and methods attributes. We still using qDox to parse the attributes, and now we're using MetaClass project to handle serialization and deserialization of these tags.
QDoxSerializer leads the way!
I think step two is already done elsewhere:
http://svn.metaclass.codehaus.org/trunk/tools/src/java/org/codehaus/metaclass/tools/qdox/
I can't help but think that we can move away (but support of course) from our own xml format and use the metaclass one in one swell swoop. But that's bigger changes than what you're proposing.
Oh, and static singleton factories I no like :-D
To avoid the kitchen sink container syndrome, the InterceptorEnabledContainer was created. If you want to use interceptors, you should create this container instead of DefaultContainer - or extend InterceptorEnabledContainer instead of DefaultContainer.
What you need to know about InterceptorEnabledContainer is: - It turn off the proxy manager. No component will be proxy but the interceptable components.
Again, I think I see oppurtunity for bigger changes! We could get completely rid of our old proxy management code and recast it as utilization of some AOP or interceptor toolkit. That would completely integrate interceptor support as to "tacking it on". WDYT?
The InterceptorManager interface --------------------------------- Family issues? --------------
the way I'm seeing this is that "family" defines the association of any particular interceptor stack with any particular method on any particular component, ie it is a limited version of an "aspect". And instead of using pointcuts (ie https://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch01.html#d0e65) or some kind of interception point syntax (ie http://cvs.apache.org/viewcvs.cgi/jakarta-hivemind/framework/src/java/org/apache/hivemind/methodmatch/), there's this new concept.
I think its a better idea to go with the flow and terminology of the "pointcut" idea.
Interceptor ----------- Sample interceptor implementation --------------------------------- InterceptableFactory -------------------
looking pretty familiar again (= good thing). In my experience in the end I found that passing around an Invocation object is quite a bit cleaner, ie like
https://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch02s02.html#d0e317
Trying to lower the expensiveness of creating/invoking a method using reflection the InterceptableFactory was created.
No offense, but I don't think we're able to maintain a very efficient proxy/interception library by ourselves. Looking at projects like HiveMind and Spring, you can also see how this has impacted them. A dedicated project like dynaop with dedicated experts is just so much faster.
(...)
How about this...we start another branch (so you don't need to miss your project deadline) that's a little more radical and weaves dynaop and metaclass right into the fortress core, then after that we look back and try and figure out a way forward. WDYT?
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
