I like the notion of filters. I wonder how others will think of it as well. Ok back to reading more emails. It definitely is a more digestible concept for users and has less magic than the Interceptor/Aspect concepts. That's just my initial take.
Alex > -----Original Message----- > From: Peter Courcoux [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 11, 2004 1:23 PM > To: Avalon Dev List > Subject: RE: More "academic" ideas [Was: [VOTE] New sandbox project] > > It appears to me that the A4 framework implies a series of individual > contracts Configuration, Contextualisation, Servicable etc. AND an order > of execution. > > I can also see that other people may wish to alter the lifecycle in > unspecified ways, by changing, adding or removing stages. > > Is it feasible to specify any container by a combination of stage > contracts and mapping, in such a way as, for example, to allow a user to > remove the Configurable stage by removing it from the mapping of his > container and removing the stage handler with it? (or adding a mapping > and stage handler for a custom stage?) > > I'm thinking a bit of pipeline or filter chain definitions here (but > only loosely). > > This would make it very much easier to understand for new users who > could start simple and add stages as required. > > There would need to be some way of querying the available or required > services and I haven't thought about how this would impact on IOC but it > sounds as though it could be very good for SOC. > > just some loose thinking here... > > Peter > > > > > On Thu, 2004-03-11 at 17:30, Leo Sutic wrote: > > > From: Hamilton Verissimo de Oliveira (Engenharia - SPO) > > > > > > -----Mensagem original----- > > > De: Leo Sutic [mailto:[EMAIL PROTECTED] > > > > > > > The handlers then allow for extensions to plug in where appropriate > > > > *for the component type*. > > > > > > How's that? Tell me about it. > > > > I'm a little confused by your question - do you want to know what I > > mean by "where appropriate" or how the extension is plugged in? > > > > This is how it is plugged in: > > > > You have this interface: > > > > interface LifecycleInterceptor { > > public Object interceptCreation (Object instance); > > public Object interceptAccess (String accessor, Object > > instance); > > } > > > > Each method can do either or both of: > > > > + Proxy the instance, return the proxy. > > > > + Call some method in the instance. > > > > For example, you'd implement Initializable like this: > > > > public Object interceptCreation (Object instance) { > > if (instance instanceof Initializable) { > > ((Initializable) instance).initialize (); > > } > > return instance; > > } > > > > If you wanted to proxy the object, you'd do: > > > > public Object interceptCreation (Object instance) { > > Object proxy = createProxy (instance); > > return proxy; > > } > > > > Now, the question is, *when* do you apply the creation intercepts? > > > > + For an Avalon 4 component, it should be before Initialize. > > > > + For a Pico component, it should be after construction. > > > > > > You have Handlers that manage component instances, so it is there > > that these LifecycleInterceptors are called: > > > > http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/aspect/src/java/org/apa > > che/avalon/aspect/Avalon4ComponentHandler.java?rev=1.1&view=markup > > > > And this is how an Aspect provides the interceptor: > > > > http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/aspect/src/java/org/apa > > che/avalon/aspect/SecurityAspect.java?rev=1.1&view=markup > > > > /LS > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
