[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

[adrian@jboss.org]

"adrian at jboss.org" wrote : 
  | That's why I've always advocated doing the jndi binding via a real registry
  | which would know the cross reference between the context providing the binding
  | and its real name.
  | 
  | 
  |   | @JNDIBinding(name="java:/whatever")
  |   | public MyService {}
  |   | 
  | 
  | Where @JNDIBinding adds an advice to the controller context that registers
  | with the jndi registry the cross reference between the binding and real name.
  | 
  | Then a JNDIDependencyItem does something like:
  | 
  |   | public boolean isResolved()
  |   | {
  |   |    Object realName = jndiRegistry.getRealName(jndiBinding);
  |   |    if (realName != null) 
  |   |    {
  |   |       setIDependOn(realName);
  |   |       setResolved(true); 
  |   |    }
  |   |    return super.isResolved();
  |   | }
  |   | 
  | 
  | Now the iDependOn is set, we know when the providing service is removed
  | so we need to be removed/recycled.
  | 

In practice, as I discussed with Carlo, it is more difficult for ejb(3)
since you can actually depend on is the "ejb-link-ref-name",
resource-ref-name, etc. not the jndi name.

Only when the application providing the link is deployed do you know what the
real jndi name is. This is something that could be resolved either by

1) a seperate registry/dependency item for links provided by the 
javaee deployers/containers

or 

2) a more complicated jndi registry that understands deployments/links and
their contexts.

I think (1) is easier and cleaner. But the devil is always in the details. :-)

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

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