[jbosscache-dev] POJO Cache no longer uses self-weaved interceptor stack

[Brian Stansberry]

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 at redhat.com
>>>> _______________________________________________
>>>> jbosscache-dev mailing list
>>>> jbosscache-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>
>>> -- 
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> manik at jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com