[jboss-dev-forums] [Design of POJO Server] - Re: Russian dolls and implicit deployment ordering

[adrian@jboss.org]

"bill.burke at jboss.com" wrote : 
  | 3) Expand our JNDI implementation so that it could be hooked into the MC's controller.  So, when things get bound into JNDI, the kernel is notified and could unblock a JNDI dependency.  THis is just an idea.
  | 

You can do this now with a KernelRegistryPlugin


  | <bean name="JNDIPlugin" class="org.jboss.naming.JNDIPlugin">
  |    <property name="environment"><!-- jndi config here --></property>
  | </bean>
  | 
  | public class JNDIPlugin implements KernelRegistryPlugin
  | {
  |    private Properties environment;
  | 
  |    public void setEnvironment(Properties environment)
  |    {
  |         this.environment = environment;
  |    }
  | 
  |    public KernelRegistryEntry getEntry(Object name)
  |    {
  |         if (name instanceof String == false)
  |            return null;
  | 
  |         InitialContext context;
  |         if (environment != null)
  |            context = new InitialContext(environment);
  |         else
  |            context = new InitialContext();
  | 
  |        try
  |        {
  |           Object o = context.lookup(name);
  |           if (o == null)
  |             return null;
  |           else
  |             return new AbstractKernelRegistry(o);
  |        }
  |        finally
  |        {
  |            context.close();
  |        }
  |    }
  | }
  | 

This has some advantages:
1) It works with any jndi implementation
2) It works with remote jndi implementation
3) It doesn't require any work from anybody else

It has lots of disadvantages:
1) Namespace conflicts, e.g. jndi name matches a bean name
2) It is going to be slow for remote jndi
3) There is nothing that initiates a recheck when jndi bindings appear or disappear
(although implementing jndi events api might facilitate this?)
4) You can only depend on the thing existing,
i.e. there are two states NOT_INSTALLED and INSTALLED
5) Probably some others? :-)

I much prefer the idea of using AOP (decorators) to handle jndi binding.

  | @JNDIBinding(...)
  | public class MyClass
  | 
  | or
  | 
  | <bean ...>
  |    <annotation>@JNDIBinding(name="whatever")</annotation>
  | </bean>
  | 

Because:
1) You can change what the jndi binding action means in different environments,
e.g. JBoss or Tomcat, without changing the configuration
2) It enables all sorts of other useful features, like not even binding into
jndi at all (for client usage) until the barrier service says "open the gates"
we're ready to go.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037086#4037086

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037086