Ales Justin wrote:

 

7) While injecting from ENC to filter/servlet, container runs into error because the EJBContainer (#3) which is responsible for setting up the JBoss specific JNDI names, which are the target of the LinkRef created in #4, hasn't yet been triggered for "start" by MC.

Do we have a failing test(s) for this?

e.g. in AS_testsuite

No there aren't any tests specifically for this. This issue keeps occuring transiently when SwitchBoard and EJB3 containers is integrated into AS trunk, because in theory it all depends on which MC bean gets picked up first in step#4 by MC container for resolution.

Ales Justin wrote:

 

How do I get a hold of this EJBContainer?

Afais, this is a MC bean under the JBossEnterpriseBeanMetaData::getContainerName?

That's correct.

Ales Justin wrote:

 

2) for @Singleton container it in done in SingletonBeanJNDIBinderDeployer in jboss-ejb3-singleton project
3) for no-interface views it's done in EJB3NoInterfaceViewDeployer in jboss-ejb3-nointerface project

OK, this two are obviously MC beans. :-)

 

For all 3 "jndi" binders:

a) Which is the code that does the custom JBoss jndi binding?

 

 

 

For no-interface jndi binding, it's the org.jboss.ejb3.nointerface.impl.jndi.NoInterfaceViewJNDIBinderFacade (MC bean) which does this binding.

For singletons it's the org.jboss.ejb3.singleton.deployer.JNDIBinderImpl

Ales Justin wrote:

 

b) Can it be already used from external bean/resource or does it need to be extracted / refactored?

 

I can determine (b) myself, once I can identify the jndi binding code. ;-)

It's not exposed yet and is internal impl details right now. Extracting/refactoring probably would require more work. I guess the easy way would be to use some specific MC bean name syntax for those binders and let the resource provider assume that syntax. For example:

LegacyMCBeanNameSupplier (or whatever we call that):

Set<String> getBinderDepencies(DeploymentUnit unit, JBossEnterpriseBeanMetaData metadata)
{
    Set<String> dependencies = new HashSet<String>();
    
    // for singleton
    if (metadata.isSession() && metadata.issingleton())
    {
        // add the binder, responsible for singleton view bindings, to the dependencies
        // The MC bean name is assumed to be of the following syntax:
        // jboss-ejb3-singleton-jndi-binder:appName=blah,module=blah,bean=beanName
        dependencies.add("jboss-ejb3-singleton-jndi-binder:appName=myapp,module=myapp,bean=blahblah");
    }    

    // for nointerface view
    if (metadata.exposesNoInterfaceView)
    {
        // add the binder, responsible for no-interface view bindings, to the dependencies
        // The MC bean name is assumed to be of the following syntax:
        // jboss-ejb3-nointerface-jndi-binder:appName=blah,module=blah,bean=beanName
        dependencies.add("jboss-ejb3-nointerface-jndi-binder:appName=myapp,module=myapp,bean=blahblah");
    }
    
    // for SLSB and SFSB
    if (metadata.isslsb || metadata.isSfsb)
    {
        // add legacy container MC bean as dependency
        dependencies.add(metadata.getJBossMetadata().getContainerName());
    }
    
    return dependencies;
}

That was actually a pseudo code, so was probably a bit confusing. For identifying the presence of no-interface view:

JBossEnterpriseBeanMetaData beanMetaData = ...

if ( beanMetaData.isSession() && beanMetaData instanceof JBossSessionBean31MetaData)
{
    JBossSessionBean31MetaData sessionBeanMetaData = (JBossSessionBean31MetaData) beanMetaData;
    if(sessionBeanMetaData.isNoInterfaceBean())
    {
        // ....
    }
}

Ales Justin wrote:

Is this name sytax already used, and such beans are already installed?

That syntax isn't being currently used and the MC beans being installed use some random internal naming scheme to deploy those MC beans.

Ales Justin wrote:

If yes, there is a bit of inconsistency in the naming, EJBBinderDeployer uses application instead of appName.

If not, I don't see who would provide these beans into MC.

We would require a change in the no-interface view and the singleton deployers. The reason I suggested that change was because to get the resource provider working, we do require some changes outside the resource provider and the simplest and quickly doable I could think of was that approach.

Ales Justin wrote:

And what is supposed to be 'bean' in this case (instead of blahblah)?

Each EJB bean has a jndi binder (MC bean). the "bean" in such a case would be the name of the EJB. so the no-interface view and singleton binder deployer would install binders for each EJB using that naming scheme.