Brian breathes sigh of relief. :-) Thanks, Jason. Jason T. Greene wrote: > I just finished PCACHE-68, which removes the AOP weaved interceptor > stack. This eliminates the possibility of a binary compatibility > issue due to an AOP version change. This also means that aopc is no > longer part of the POJO Cache build. It also simplifies the code a > bit since the interceptor design was overkill. -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

We have some refactoring in mind after 2.0.0.GA - could you point us towards some information about how you are using interceptors now? On 26 Jun 2008, at 11:15, Manik Surtani wrote: > Three cheers! > > On 26 Jun 2008, at 03:58, Brian Stansberry wrote: > >> Brian breathes sigh of relief. :-) >> >> Thanks, Jason. >> >> Jason T. Greene wrote: >>> I just finished PCACHE-68, which removes the AOP weaved interceptor >>> stack. This eliminates the possibility of a binary compatibility >>> issue due to an AOP version change. This also means that aopc is no >>> longer part of the POJO Cache build. It also simplifies the code a >>> bit since the interceptor design was overkill. >> >> -- >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> brian.stansberry(a)redhat.com >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev > > -- > Manik Surtani > Lead, JBoss Cache > manik(a)jboss.org > > > > > > > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Yeah, Kabir, that was the cause of my sigh of relief. Integrating into the AS a pojocache binary that had itself been weaved by a possibly different AOP release than what the AS uses -- very scary; possible nightmare when it comes to doing EA CP fixes etc. So I was very happy when Jason removed the need for it. Jason T. Greene wrote: > Just to clarify, by interceptor design I was referring to POJO > Cache's use of them in it's internal implementation, not the actual > AOP interceptor API/design. I only removed weaving of the POJO > Cache project itself, by dropping it's use of interceptors. It > turns out that the implementation is simpler without them, so I > didn't really need to replace it with a new interception system. > Also users never added to it, so no loss there. If in the future I > ever did bring interceptors back, I think I would prefer to use a > proxy based approach. > Weaving is still used though for user objects which are bound to > the cache. However, in this case, I recommend load-time weaving via > javaagent, and discourage precompiling, since this eliminates the > possibility of a binary compatibility problem. At some point I > would love to be able to do load-time weaving via the AS5 > classloaders, which would be more efficient than an agent, and work > out of the box. > Kabir Khan wrote: >> We have some refactoring in mind after 2.0.0.GA - could you point >> us towards some information about how you are using interceptors >> now? >> >> On 26 Jun 2008, at 11:15, Manik Surtani wrote: >> >>> Three cheers! >>> >>> On 26 Jun 2008, at 03:58, Brian Stansberry wrote: >>> >>>> Brian breathes sigh of relief. :-) >>>> >>>> Thanks, Jason. >>>> >>>> Jason T. Greene wrote: >>>>> I just finished PCACHE-68, which removes the AOP weaved >>>>> interceptor stack. This eliminates the possibility of a binary >>>>> compatibility issue due to an AOP version change. This also >>>>> means that aopc is no longer part of the POJO Cache build. It >>>>> also simplifies the code a bit since the interceptor design was >>>>> overkill. >>>> >>>> -- >>>> Brian Stansberry >>>> Lead, AS Clustering >>>> JBoss, a division of Red Hat >>>> brian.stansberry(a)redhat.com >>>> _______________________________________________ >>>> jbosscache-dev mailing list >>>> jbosscache-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>> >>> -- >>> Manik Surtani >>> Lead, JBoss Cache >>> manik(a)jboss.org >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com