excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject Re: Excalibur Fortress now supports Interceptors (among other new features)
Date Mon, 12 Jul 2004 14:27:05 GMT
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...

> Metainfo
> --------
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 :-D

> 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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Mime
View raw message