7 Replies Latest reply on May 30, 2006 9:32 AM by galder.zamarreno

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

manik May 26, 2006 11:57 AM

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.

1. Re: Should the cache bind itself to a JNDI tree as well as J

manik May 26, 2006 11:59 AM (in response to manik)

Deployment of the cache should have nothing to do with the cache.

This is orthogonal and should be handled by the deployment environment. At the moment AS does it via JMX. If people want this bound to JNDI, they write a wrapper that constructs the cache and binds it where they want.

In the end, many use cases involve the cache as a standalone library rather than a service bound to an enterprise container.
Actions
2. Re: Should the cache bind itself to a JNDI tree as well as J

gavin.king May 26, 2006 12:26 PM (in response to manik)

That is all well and good that it is _possible_ to deploy it standalone. But all of our projects need an integrated deployment solution for JBoss AS. And it is the responsibility of the project team to provide that, because no-one else is going to.
Actions

3. Re: Should the cache bind itself to a JNDI tree as well as J

genman May 26, 2006 3:53 PM (in response to manik)

I think TreeCache has too many methods, but you could simply add an MBean attribute "JNDIName" or "JndiName" (depending on your convention) and add this stuff in:

 protected void startService() throws Exception {
 org.jboss.util.naming.Util.rebind(new InitialContext(), jndiName, this);
 }

 protected void stopService() throws Exception {
 org.jboss.util.naming.Util.unbind(new InitialContext(), jndiName);
 }

So you'd do:

TreeCache tc = new TreeCache();
tc.setJndiName("cache1");
tc.start();

If that didn't suit you, maybe you could create a TreeCacheProvider?

TreeCache tc = new TreeCache();
TreeCacheProvider tcp = new TreeCacheProvider(tc);
tcp.setJndiName("cache1");
tcp.start();

In MBean terms, you could write something like

<mbean code='TreeCacheProvider' ...>
 <depends opt-att-name="Cache">example:service=MyCache<depends>
 <attribute name="JndiName">cache1</attribute>
<mbean>

4. Re: Should the cache bind itself to a JNDI tree as well as J

ben.wang May 26, 2006 9:47 PM (in response to manik)

Binding cache to global jindi name is no problem. The thing is then people will access it remotely and expect "remote" cache operation to work. E.g., for the client side to do:

cache.get(fqn, key).

And both difficult to work and also not inline with the cache philosophy, IMO.
Actions
5. Re: Should the cache bind itself to a JNDI tree as well as J

belaban May 27, 2006 11:50 AM (in response to manik)

The standard way of binding into JNDI is via JRMPProxyFactory, JBossCache *will* not bind itself into JNDI, that a very bad idea (tm)
Actions
6. Re: Should the cache bind itself to a JNDI tree as well as J

belaban May 27, 2006 11:57 AM (in response to manik)

-1 on this; that's exactly what we had 1 year ago. I ripped out that code because we don't want to have a dependency on JNDI. BTW: neither do we want to have a dep on JMX, and we'll rip that dep out soon too. I mean, not JMX dep on interfaces, but on JBoss' *implementation* of JMS, like MBeanServerSupport
Actions
7. Re: Should the cache bind itself to a JNDI tree as well as J

galder.zamarreno May 30, 2006 9:32 AM (in response to manik)

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!

What about if you were looking up an EJB or a datasource? Don't u depend on
JNDI when doing a lookup?

I agree with Manik et al, Cache should not need to know what environment it
is being deployed in.
Actions

Go to original post