Menu
▾
▴
springframework-developer
|
From: March, A. <am...@so...> - 2004-09-16 16:59:50
|
Glad to hear people are still thinking about OSCache. I wonder about the comment made about the "weak configuration". I am actively contributing to it right now and would love any input on it. As far as a pluggable cache system goes, I think hibernate's model works fairly well and I would like to see something like that in Spring. One selfish question, I researched all the other open source caches out there; however, I found them all to be immature except OSCache. Is there a reason you are considering EHCache instead? I have asked this question in many forums but can never get any answer. > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf > Of Rob Harrop > Sent: Thursday, September 16, 2004 6:59 AM > To: spr...@li... > Subject: Re: [Springframework-developer] oscache >=20 > I think the ability to support multiple caching implementations is a > good idea. I think it is unlikely that there is a solution that is out > and out the best for any given scenario. >=20 > Rob >=20 > Dmitriy Kopylenko wrote: >=20 > > We're planning to use EHCache and I'm planning to write convenience > > EhCacheFactoryBean for easy configuration and injection of EHCache > > Caches using DI in Spring app context. May be it would make sense to > > create a "cache" package to write integrations/support/convenient > > configuration...you name it, for different caching systems i.e. > > OSCache... > > > > What does everyone think? > > > > Regards, > > Dmitriy. > > > > > > bryan wrote: > > > >> Has any work been done or is any work planned to integrate oscach > >> with the spring framework ? It is a great product but suffers from a > >> weak configuration system. > >> > >> --b > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > >> Project Admins to receive an Apple iPod Mini FREE for your judgement on > >> who ports your project to Linux PPC the best. Sponsored by IBM. > >> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > >> _______________________________________________ > >> Springframework-developer mailing list > >> Spr...@li... > >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > >> > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: March, A. <am...@so...> - 2004-09-16 19:59:37
|
Thanks for your feedback. > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf > Of Dmitriy Kopylenko > Sent: Thursday, September 16, 2004 10:15 AM > To: spr...@li... > Subject: Re: [Springframework-developer] oscache >=20 >=20 > >there a reason you are considering EHCache instead? > > > > > We have nothing against OSCache as we did not evaluate or looked at > OSCache at all. Our requirements are very, very simple (get, put, > remove, that's about it). EHCache looks very, very lightweight. That's > all there is to it. >=20 > Dmitriy. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-16 21:05:23
|
> As far as a pluggable cache system goes, I think hibernate's model = works fairly well and I would like to see something like that in Spring. The difference is that Spring does not currently have a use case for = such a cache abstraction itself. This is a bit similar to our current = support for scheduling and also O/R mapping: I prefer to not go for a = complete abstraction here but rather for convenient means to work with = the respective *native* API of existing cache products. =20 So IMO, an EhCacheFactoryBean like Dmitriy proposes is certainly a = useful addition, exposing EhCache's native Cache object for bean = references. I just don't think that trying to abstract that cache API is = the right way to go for Spring: There are potentially too many subtle = features and semantic details involved. Let's rather expose the full = power of the respective native API. =20 Juergen |
|
From: Ben A. <ben...@ac...> - 2004-09-16 21:52:16
|
jürgen höller [werk3AT] wrote:
>>As far as a pluggable cache system goes, I think hibernate's model works
>>
>>
>fairly well and I would like to see something like that in Spring.
>
>The difference is that Spring does not currently have a use case for such a cache abstraction itself. This is a bit similar to our current support for scheduling and also O/R mapping: I prefer to not go for a complete abstraction here but rather for convenient means to work with the respective *native* API of existing cache products.
>
>So IMO, an EhCacheFactoryBean like Dmitriy proposes is certainly a useful addition, exposing EhCache's native Cache object for bean references. I just don't think that trying to abstract that cache API is the right way to go for Spring: There are potentially too many subtle features and semantic details involved. Let's rather expose the full power of the respective native API.
>
>
>
>
Having three cache interfaces and corresponding EH-CACHE implementations
in Acegi Security puts me in a bit of a position to comment about this.
I fully agree with Juergen - the subtle variations between caches exist
and it's of questionable value trying to come up with a
one-size-fits-all interface. In Acegi Security we expose a simple
project-specific interface, such as:
public interface UserCache {
public UserDetails getUserFromCache(String username);
public void putUserInCache(UserDetails user);
public void removeUserFromCache(String username);
}
If people really need cache pluggability within their own projects, they
can expose project-specific interfaces to the cache (as above) and then
write a simple implementation that just does casting and passes through
to the cache engine.
In relation to Spring loading and configuring the cache engines, there
is a lot of value in this. We've had two issues emerge with EH-CACHE
loading after web context refreshes, and then null pointer exceptions
with the fix. Thus it would be better if we could interface with a cache
engine Spring worries about managing, and users already know how to
configure. Due to widespread use, such bugs are likely to be ironed out
quickly, and projects such as Acegi Security can provide more
implementations of their own project-specific cache interfaces, given
Spring takes care of the engine-specific mechanics.
Best regards
Ben
|
|
From: Dmitriy K. <dko...@ru...> - 2004-09-16 23:11:48
|
I have a EhCacheFactoryBean implementation ready locally, so I could
commit that tomorrow if there are no objections.
Regards,
Dmitriy.
Ben Alex wrote:
> jürgen höller [werk3AT] wrote:
>
>>> As far as a pluggable cache system goes, I think hibernate's model
>>> works
>>>
>>
>> fairly well and I would like to see something like that in Spring.
>>
>> The difference is that Spring does not currently have a use case for
>> such a cache abstraction itself. This is a bit similar to our current
>> support for scheduling and also O/R mapping: I prefer to not go for a
>> complete abstraction here but rather for convenient means to work
>> with the respective *native* API of existing cache products.
>>
>> So IMO, an EhCacheFactoryBean like Dmitriy proposes is certainly a
>> useful addition, exposing EhCache's native Cache object for bean
>> references. I just don't think that trying to abstract that cache API
>> is the right way to go for Spring: There are potentially too many
>> subtle features and semantic details involved. Let's rather expose
>> the full power of the respective native API.
>>
>>
>>
>>
> Having three cache interfaces and corresponding EH-CACHE
> implementations in Acegi Security puts me in a bit of a position to
> comment about this. I fully agree with Juergen - the subtle variations
> between caches exist and it's of questionable value trying to come up
> with a one-size-fits-all interface. In Acegi Security we expose a
> simple project-specific interface, such as:
>
> public interface UserCache {
> public UserDetails getUserFromCache(String username);
> public void putUserInCache(UserDetails user);
> public void removeUserFromCache(String username);
> }
>
> If people really need cache pluggability within their own projects,
> they can expose project-specific interfaces to the cache (as above)
> and then write a simple implementation that just does casting and
> passes through to the cache engine.
>
> In relation to Spring loading and configuring the cache engines, there
> is a lot of value in this. We've had two issues emerge with EH-CACHE
> loading after web context refreshes, and then null pointer exceptions
> with the fix. Thus it would be better if we could interface with a
> cache engine Spring worries about managing, and users already know how
> to configure. Due to widespread use, such bugs are likely to be ironed
> out quickly, and projects such as Acegi Security can provide more
> implementations of their own project-specific cache interfaces, given
> Spring takes care of the engine-specific mechanics.
>
> Best regards
> Ben
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: March, A. <am...@so...> - 2004-09-17 00:09:10
|
Your points are well taken and my example of hibernate is a bit =
different situation than spring is in. Caching is an integral part of =
hibernate that they have thankfully made pluggable. =20
Spring IoC is more like a service provider with really good glue. I can =
think of plenty of examples where I would like access to the "native" =
API of a particular service and not have to be hindered by an overly =
simplistic abstract API.
Obviously I was more interested in getting feedback on OSCache than =
thinking about the issue ;)
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Ben Alex
> Sent: Thursday, September 16, 2004 2:52 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] oscache
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >>As far as a pluggable cache system goes, I think hibernate's model =
works
> >>
> >>
> >fairly well and I would like to see something like that in Spring.
> >
> >The difference is that Spring does not currently have a use case for =
such
> a cache abstraction itself. This is a bit similar to our current =
support
> for scheduling and also O/R mapping: I prefer to not go for a complete
> abstraction here but rather for convenient means to work with the
> respective *native* API of existing cache products.
> >
> >So IMO, an EhCacheFactoryBean like Dmitriy proposes is certainly a =
useful
> addition, exposing EhCache's native Cache object for bean references. =
I
> just don't think that trying to abstract that cache API is the right =
way
> to go for Spring: There are potentially too many subtle features and
> semantic details involved. Let's rather expose the full power of the
> respective native API.
> >
> >
> >
> >
> Having three cache interfaces and corresponding EH-CACHE =
implementations
> in Acegi Security puts me in a bit of a position to comment about =
this.
> I fully agree with Juergen - the subtle variations between caches =
exist
> and it's of questionable value trying to come up with a
> one-size-fits-all interface. In Acegi Security we expose a simple
> project-specific interface, such as:
>=20
> public interface UserCache {
> public UserDetails getUserFromCache(String username);
> public void putUserInCache(UserDetails user);
> public void removeUserFromCache(String username);
> }
>=20
> If people really need cache pluggability within their own projects, =
they
> can expose project-specific interfaces to the cache (as above) and =
then
> write a simple implementation that just does casting and passes =
through
> to the cache engine.
>=20
> In relation to Spring loading and configuring the cache engines, there
> is a lot of value in this. We've had two issues emerge with EH-CACHE
> loading after web context refreshes, and then null pointer exceptions
> with the fix. Thus it would be better if we could interface with a =
cache
> engine Spring worries about managing, and users already know how to
> configure. Due to widespread use, such bugs are likely to be ironed =
out
> quickly, and projects such as Acegi Security can provide more
> implementations of their own project-specific cache interfaces, given
> Spring takes care of the engine-specific mechanics.
>=20
> Best regards
> Ben
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement =
on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dmitriy K. <dko...@ru...> - 2004-09-16 17:13:17
|
>there a reason you are considering EHCache instead? > > We have nothing against OSCache as we did not evaluate or looked at OSCache at all. Our requirements are very, very simple (get, put, remove, that's about it). EHCache looks very, very lightweight. That's all there is to it. Dmitriy. |
