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

[bill.burke@jboss.com]

"adrian at jboss.org" wrote : 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.
  | 

If you saw my original post, this just isn't feasible as the EJB container (or any component that uses EE metadata references) might be referencing something that is MC-unaware.  I.e. a third-party JMS implementation.

"adrian at jboss.org" wrote : 
  | 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.
  | 

Its actually more difficult than that.  EJB-refs might only know the interface of the EJB they are refencing, no other information.  They also have to look first within the EJB-jar, then EAR, then globally for beans of this type.  PersistenceUnits have exact same scoping rules as well, except that units defined in EJB jars or Wars are private.  Making it even more complicated.  For @Resource entries we rely on the mapped-name() attribute which we assume is a JNDI name.  There is no other way to do it generically.

"adrian at jboss.org" wrote : 
  | 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. :-)

We already do (1) (or did? not sure if carlo totally refactored this incorrectly)  for @EJB, @PersistenceContext, and @PersistenceUnit.  It is just not possible to do it for datasources, JMS objects, and other resources.  That's why I think a service is needed.

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

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