On Monday 02 August 2004 14:15, Alexis Agahi wrote: > Real good point, but do you think interface implementation is required?
Well, the I can't see any reason why not to use interfaces for Interceptors. That keeps things a lot more understandable and organized, IMO. > I like your approach, simple and nice. > I continue thinking on that track If you go to runtime/activation/impl/src/java/org/apache/avalon/activation/impl/ and check out the classes DefaultAppliance and ApplianceInvocationHandler. DefaultAppliance is the class that 'manages' the component in runtime, and if proxies are enabled, it wraps the component with the ApplianceInvocationHandler. Interceptor support is needed to be added within/around these classes. The following steps would be required for Explicit Interception; 1. Define the @avalon.interceptor tag, and add support for it in Meta. 2. Add Interception support in Composition, so it can be retrieved from the Model. Probably by adding a InterceptionModel, which carries the info needed, and adding a method to the ComponentModel to retrieve it. 3. Add a InterceptionInvocationHandler class in the above package. 4. Change DefaultAppliance to check for if interception is enabled in the component model, if so instantiate the InterceptionInvocationHandler instead and accordingly. For Implicit interception, need to add support in Kernel and have that propogate down to the model as well. That means that from the DefaultAppliance PoV, it can't tell if the support is implicit or explicit. One close parallel to it all is Life Cycle Stage extensions, and by looking at how that is handled in many places, one can get through it all. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
