-
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. -
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.
-
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. -
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)
-
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
-
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.