I'm not sure if this is needed in this case. The Java interceptors spec got moved out of EJB a long time a go and is now a standalone spec which is used by CDI, Spring and guice. The package is javax.interceptor and contains all the stuff we need.
If we do it in a similar style than Apache MyFaces CODI and now Apache DeltaSpike does it with the 'InterceptorStrategy' [1] then we are completely free of any container specific code. LieGrue, strub [1] https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/InterceptorStrategy.java;h=a772152c46ae589572c6bb2bfb0292a8e980b2d3;hb=HEAD ----- Original Message ----- > From: Matt Benson <gudnabr...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: > Sent: Wednesday, February 13, 2013 4:39 PM > Subject: Re: commons-monitoring? > > WRT a Commons Interceptor API, [proxy] defines Interceptor and other > related interfaces. > > Matt > > > On Wed, Feb 13, 2013 at 6:09 AM, Romain Manni-Bucau > <rmannibu...@gmail.com>wrote: > >> basically having a commons.Interceptor api can be interesting then we >> simply need to map to spring and cdi >> >> this is done in shiro for instance and works very well >> >> *Romain Manni-Bucau* >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> *Blog: **http://rmannibucau.wordpress.com/*< >> http://rmannibucau.wordpress.com/> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> *Github: https://github.com/rmannibucau* >> >> >> >> 2013/2/13 Benedikt Ritter <brit...@apache.org> >> >> > 2013/2/13 Paul Libbrecht <p...@hoplahup.net> >> > >> > > Benedikt, >> > > >> > > On 13 févr. 2013, at 08:49, Benedikt Ritter wrote: >> > > > Commons components usually don't have any dependencies. > How would you >> > > > implement this under this restriction? >> > > >> > > >> > > >> > > I've never seen this written before. Have you? >> > > >> > >> > Yes, on the commons website [1]: >> > >> > "Commons developers will make an effort to ensure that their > components >> > have minimal dependencies on other libraries, so that these components >> can >> > be deployed easily." >> > >> > But you're right If you wanted to point out, that this is not an > absolute >> > must-have. We can have minimal dependencies. >> > I guess (but I don't know!) it would be okay to have a dependency > to the >> > AOP alliance jars, for example to define a new MethodInterceptor [2] > for >> > monitoring. But IMHO it would be rather strange to have dependencies > to >> > org.springframework.aop to define a new MethodBeforeAdvice [3] for >> > monitoring. >> > >> > Makes sense? :) >> > >> > Benedikt >> > >> > [1] http://commons.apache.org/ >> > [2] >> > >> > >> > http://aopalliance.sourceforge.net/doc/org/aopalliance/intercept/MethodInterceptor.html >> > [3] >> > >> > >> > http://static.springsource.org/spring/docs/3.0.0.M1/javadoc-api/org/springframework/aop/MethodBeforeAdvice.html >> > >> > >> > > >> > > paul >> > > >> > > >> > > >> > > >> > >> > >> > -- >> > http://people.apache.org/~britter/ >> > http://www.systemoutprintln.de/ >> > http://twitter.com/BenediktRitter >> > http://github.com/britter >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org