> As I was reading the thread from the beginning I kept thinking of > something like the Inteceptor classes Alex pointed out. So where do you > want to do this? Here or over in the directory project? We could > easily host it in our sandbox.
Sure we could keep it over in our (Avalon) sandbox. We can copy it over while I slowly start making the directory use the general Avalon code. It would also be really nice if we talked to some of the commons folks to see if there is some chance to consolidate this framework or what ever. It might be worth just asking them after we get this defined better in JIRA. More on the idea ================= I actually use 3 separate interceptor chains or pipelines to inject services before, after and on the failure of a call. 1 for services injected before a method call. One after and then another exception handling chain or pipeline. The exceptional chain is there for services that need to cleanup after some failure. For example consider implementing transactions. A service interceptor (might be same interceptor) in the before chain starts a transaction. The after interceptor commits it. And the exceptional (on failure) chain's interceptor for the txn service does a rollback. You can do many things here but 3 separate chains makes it complete and capable of handling every kind of construct Java can throw at you. Essentially the triad of interceptor chains are designed around the nature of Java and exception handling this way. Also note that the before and after chains are fail fast. Meaning any Interceptor within the chain can short the chain handing off the invocation to downstream Interceptors. The on error or exceptional chain is not. It is guaranteed to hand the invocation to every Interceptor within the chain regardless of whether or not a downstream Interceptor fails in the chain. Why is Eve such a babe? ======================= BTW no one asked why Eve uses this construct. For the curious the backend subsystem is designed as a LDAP JNDI provider which does not go over the wire but the JNDI operations are translated into backend ops directly. The problem I had was how to provide a bunch of services to all backends without having to have each backend implementation implement them. The interceptor pipeline idea came in. This is how authorization, schema checking etc are handled in the server. Basically we can decorate any JNDI call using this setup. Also triggers that call stored procs that make JNDI calls to access the back end wind up creating a Stack of JNDI contexts when there is a cascade. The interceptors also help manage trigger firings and prevent runaway cascades. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
