[jbosscache-dev] Access to data in CacheListener.nodePassivated

[Brian Stansberry]

No, I don't mind at all. It was a hack.  I kind of miss peek(), which 
was a more coherent way to solve the same problem -- give a 
sophisticated caller access to the data, trusting that they understand 
the state of system and know whether a peek() call is OK.  Dangerous if 
the caller isn't sophisticated though.

But, with nodeLoaded and nodePassivated providing the data, that solves 
the specific use case I had for peek() in a better way than peek() did.

Thanks!

P.S. JIRA says Fix Version = GA, CR2. I hope for CR2, as I really need 
to get CR2 in the AS trunk build.

Manik Surtani wrote:
> Ok, sure.  Makes sense, since nodeLoaded passes in data.  Consistency 
> would be nice.  :)
> 
>     http://jira.jboss.com/jira/browse/JBCACHE-1073
> 
> Hope you don't mind about the Option.setBypassInterceptorChain() 
> disappearing - that really stank.
> 
> 
> On 25 May 2007, at 01:12, Brian Stansberry wrote:
> 
>> The EJB3 SFSB layer needs access to the data in the relevant node when 
>> it gets a nodePassivated(fqn, true) callback.  It needs it so it can 
>> get the bean context and invoke any @PrePassivate methods.
>>
>> When it gets the data, it can't go through the interceptor chain or 
>> that causes a bunch of problems that we sorted last fall and early 
>> this year.
>>
>> In CR2 getting this data w/o going through the interceptors is now 
>> impossible, at least w/o some nasty hacks I haven't dreamed up yet.  
>> In 1.4 we did it with the now removed peek() method.  Earlier in 2.0 
>> we used Option.setBypassInterceptorChain(), but it seems that is now 
>> gone as well.
>>
>> How about we change the method signature of the notification to 
>> provide the data in the callback?  Looking at the 
>> PassivationInterceptor, this is easy to do -- the data map is sitting 
>> right there.  If we do, this data param should be null in the 'post' 
>> callback.
>>
>> --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
> JBoss, a division of Red Hat
> 
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
> 
> 


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