Commons-proxy you mean? I removed it. ATM we have cdi proxying,
aopalliance, ill add a correct aspectj and if we want more well use/(update
commons proxy to use)  asm. Commons proxy brings an easy API which a bunch
of issues behind ATM IMHO
Le 26 juil. 2013 19:26, "James Carman" <ja...@carmanconsulting.com> a
écrit :

> Well, with [proxy], you can get your AOP you're looking for, too.
>
> On Wed, Feb 13, 2013 at 3:02 PM, Mark Struberg <strub...@yahoo.de> wrote:
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to