On Mar 31, 2010, at 11:12 , Guillaume Nodet wrote: > Wouldn't it make more sense to use service hooks instead ?
Service hooks are somewhat less dynamic in that I cannot decide lateron to install them and have them work with "everything that was already in place". This is explained in 12.7.3 about Ordering. I wanted to have this ability, even for services that were already used by clients before the aspect was installed. If you don't need that ability, and don't mind being able to run only on 4.2 frameworks, then service hooks are a good alternative. > The current design is limited as if a user wants to grab the list of > services and use those, that would not work. That depends on how you actually grab that list of course. If you just grab a list of all services of a certain type, that won't work, but it's not actually too hard to pick only the highest ranking service if there are multiple services in the list that otherwise have the same properties. But you are right, this is a little bit more involved and would be simpler if service hooks were used. Perhaps it would be nice to have the option to use service hooks if your trade offs are different and you don't mind having to install the hooks first. Greetings, Marcel > > On Wed, Mar 31, 2010 at 11:06, Marcel Offermans <[email protected] >> wrote: > >> On Mar 31, 2010, at 11:02 , Ivanhoe Abrahams wrote: >> >>> This is helpful in getting me pointing in the right direction. >>> So just to recap. >>> >>> Option 1 in your email is the traditional approach where you have aop >>> pointcuts, etc. defined >>> Option 2 is intercepting the calls and dynamically weaves in >>> code...something akin to asm bytecode weaving? >> >> It does not do bytecode weaving at all, it relies on the fact that services >> have a service ranking, so the aspect simply publishes a service with all >> the same properties as the original one, but a higher ranking. Clients will >> automatically pick the service with the highest ranking. So there's no >> bytecode weaving at all (which makes debugging a lot easier, since your code >> still looks exactly like you wrote it). >> >> Greetings, Marcel >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
