7 Replies Latest reply on May 30, 2006 9:32 AM by Galder Zamarreño

    Should the cache bind itself to a JNDI tree as well as JMX?

    Manik Surtani Master

      An email discussion with Gavin:


      On 26 May 2006, at 16:40, Gavin King wrote:

      Definitely not true.

      If I deploy JBossCache by throwing an xxx-service.xml into the deploy
      dir, it should be exactly the same as if I deploy JMS, JDBC, Hibernate,
      etc, in the same way. ie. it is then available in global JNDI.

      There are two things here: the cache, and deployment of the cache.

      What is your current deployment solution?


      -----Original Message-----
      From: Manik Surtani [mailto:manik@jboss.org]
      Sent: Friday, May 26, 2006 11:36 AM
      To: Gavin King
      Subject: Re: Looking up JBossCache

      Both JNDI and JMX should *not* be a part of the JBossCache API, IMO.
      It should be up to the container (if deployed in one) or client code (if
      used in a standalone manner) to instantiate and bind the cache somewhere
      for the rest of the client code to look up. The fact that we still have
      the JMX binding is legacy, because this is how it is used elsewhere in
      the app server. According to Bela, there used to be a JNDI binding some
      while back but that was removed since it shouldn't be the task of the
      cache service to bind itself anywhere.


      On 26 May 2006, at 16:28, Gavin King wrote:

      There is no way I am going to get a dependency to JMX just to lookup a

      cache!

      Are you serious that there is no way to get it from JNDI?!

      You guys need to fix that. JMX is _not_ an application-visible API.