[jbosscache-dev] Habanero: implementing peek() and _*() methods

[Galder Zamarreno]

+1 on not having direct access to any methods the client should not be calling.

Alternatives to access to those methods are not easy. An interface extending CacheSPI with these methods? I haven't been following the progress of 2.0.0 that much so maybe I'm saying something that's already been said...

Galder Zamarreño
Support Engineer
JBoss, a division of RedHat


-----Original Message-----
From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of Manik Surtani
Sent: 16 August 2006 19:15
To: Ben Wang
Cc: jbosscache-dev at lists.jboss.org
Subject: Re: [jbosscache-dev] Habanero: implementing peek() and _*() methods

The SPI is still for end users - people who write custom cache  
loaders, custom interceptors, etc.  I'd rather not have direct access  
methods here, somehow.  What does everyone think?
--
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


On 16 Aug 2006, at 16:11, Ben Wang wrote:

> If you expose these in the SPI, then it is not meant for end users,  
> isn't it?
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik at jboss.org]
> Sent: Wednesday, August 16, 2006 5:25 PM
> To: Ben Wang
> Cc: jbosscache-dev at lists.jboss.org
> Subject: Re: [jbosscache-dev] Habanero: implementing peek() and _* 
> () methods
>
> I agree that access to _* methods will be useful/necessary.
>
> This is why I proposed an interceptor chain bypass option, rather  
> than directly exposing methods.  My problem with directly exposing  
> methods is that end users may see these and use them.
>
>
> --
> 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
>
>
> On 16 Aug 2006, at 03:49, Ben Wang wrote:
>
>> Since I haven't done the integration so it is difficult to say for
>> sure. But I have a feeling that I will need to have the access to
>> _* methods as well from PojoCache. So would it be OK then to create a
>> delegate interface from CacheSPI (e.g., NakedNode, in that calls here
>> are not going thru any interceptor chain) that exposes these APIs?
>> User can still access these but at least it doesn't pollute the SPI
>> interfaces.
>>
>> BTW, maybe this deserves a forum thread? :-)
>>
>> My 2 cents,
>>
>> -Ben
>>
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-
>> bounces at lists.jboss.org] On Behalf Of Manik Surtani
>> Sent: Monday, August 14, 2006 8:17 PM
>> To: jbosscache-dev at lists.jboss.org
>> Subject: [jbosscache-dev] Habanero: implementing peek() and _*()
>> methods
>>
>> In 2.0.0, all interceptors have a reference to a CacheSPI only.
>>
>> This causes a problem in some interceptors (cache loader, lock
>> interceptors, etc) which currently make a few direct calls to _get  
>> (),
>> _put(), etc. to perform operations on the cache while bypassing the
>> interceptor stack entirely.
>>
>> What do people think the best way would be do provide this access for
>> very specialised cases, but not exposing such calls in the CacheSPI
>> interface for generic Interceptors people may implement?
>>
>> I'm currently doing this by creating a 'bypassInterceptorChain'
>> option and then calling a standard put() or get(), but this is at  
>> best
>> a hack, plus it exposes the 'bypassInterceptorChain' option in a
>> public API for users to (ab)use.  Any better ideas?
>>
>> Cheers,
>> --
>> 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
>>
>>
>> _______________________________________________
>> 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