Next time I need to catch up on what has happened in the meantime I'll
probably take the top-down approach instead of the bottom-up ;-) OK,
I'll wait for what comes out of that discussion.
Cheers,
Olaf
Am 18.03.11 14:18, schrieb Galder Zamarreño:
Btw, I'll add this to the agenda for next week so that we can
discuss it on the side.
On Mar 18, 2011, at 2:17 PM, Galder Zamarreño wrote:
> Olaf, for the RemoteCacheManager version of org.springframework.cache.CacheManager,
you can simply return saying that this is not yet unsupported, that should allow you to
move forward.
>
> Mircea, I think you have a point there. However, I don't wanna add new verbs for
each of the JMX parameter a client might want to retrieve. The one that makes most sense
right now is returning cache names due to the current limitation that only allows caches
that are defined to be used, though I hope that limitation will go away in 5.0
(
https://issues.jboss.org/browse/ISPN-833)
>
> So, what about something ala twidle? So, having a generic management verb that can
take a mbean name, mbean attribute and the content as is (most probably a String)?
>
> On Mar 17, 2011, at 12:11 PM, Sanne Grinovero wrote:
>
>> On 17 Mar 2011 10:55, "Mircea Markus"<mircea.markus(a)jboss.com>
wrote:
>>>
>>> On 17 Mar 2011, at 10:22, Sanne Grinovero wrote:
>>>
>>>> I think we could suggest many improvements, but if it's not in this
>>>> specific existing API
>>> Which API do you have in mind?
>>> org.infinispan.client.hotrod.RemoteCache/RemoteCacheManager ?
>> The subject of this thread: Spring cache API ;)
>>
>>>> then people won't use it (at least via Spring's
>>>> integration)
>>>>
>>>> Il giorno mercoledì 16 marzo 2011, Mircea Markus
>>>> <mircea.markus(a)jboss.com> ha scritto:
>>>>> This method can return more than cache names, some info about status
would be helpful as well.
>>>>> E.g. verb to return all the cache names together with a status
indicator: defined, running, stopped.
>>>>> On 16 Mar 2011, at 08:06, Galder Zamarreño wrote:
>>>>>
>>>>>> Olaf, you're current method won't work since it will only
give you the cache names of the caches being interacted with by that client. It does not
represent all the caches active on the server side.
>>>>>>
>>>>>> It's something that could be useful and easy to implement -
I've created
https://issues.jboss.org/browse/ISPN-984
>>>>>>
>>>>>> Olaf, if you fancy learning some Scala, you could try
implementing it when you're finished with the Spring work? I can guide you through it
:)
>>>>>>
>>>>>> On Mar 14, 2011, at 1:40 PM, Manik Surtani wrote:
>>>>>>
>>>>>>> There isn't anything of the sort at the moment. I
presume you'd just have to use a singleton list containing the default cache name for
now.
>>>>>>>
>>>>>>> Galder/Mircea, what are your thoughts around adding a verb to
retrieve cache names to Hot Rod?
>>>>>>>
>>>>>>>
>>>>>>> On 13 Mar 2011, at 22:30, Olaf Bergner wrote:
>>>>>>>
>>>>>>>> I have more or less finished my first attempt at
implementing Spring
>>>>>>>> 3.1's forthcoming cache abstraction for Infinispan
embedded. While doing
>>>>>>>> the same for Infinispan remote, i.e. for Infinispan's
hotrod client, I
>>>>>>>> noticed that
org.infinispan.client.hotrod.RemoteCacheManager lacks a
>>>>>>>> method for asking it for the names of all caches that are
currently
>>>>>>>> known to it. This, however, is required for successfully
implementing
>>>>>>>> org.springframework.cache.CacheManager. For now, I work
around this
>>>>>>>> limitation by using reflection to get at
RemoteCacheManager's map from
>>>>>>>> cache names to caches. Suffice it to say that this reeks
of a hack.
>>>>>>>>
>>>>>>>> So do you think that adding such a method to
RemoteCacheManager is
>>>>>>>> feasible? Alternatively, do you know of any other way to
get at the
>>>>>>>> names of all caches managed by RemoteCacheManager?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Olaf
>>>>>>>> _______________________________________________
>>>>>>>> infinispan-dev mailing list
>>>>>>>> infinispan-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>> --
>>>>>>> Manik Surtani
>>>>>>> manik(a)jboss.org
>>>>>>>
twitter.com/maniksurtani
>>>>>>>
>>>>>>> Lead, Infinispan
>>>>>>>
http://www.infinispan.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> infinispan-dev mailing list
>>>>>>> infinispan-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>> --
>>>>>> Galder Zamarreño
>>>>>> Sr. Software Engineer
>>>>>> Infinispan, JBoss Cache
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev