JBMETA-6, JBMETA-25 resolved jndi name

[starksm64]

I still cannot get a definitive view of the jndi name to use for the resolved jndi name output from the resolving deployers because the default jndi policy is not used in the metadata layer. I resolve an ejb link to the approriate JBossSessionBeanMetaData, but its determineJndiName() result does not match what the BaseSessionProxyFactory ends up using. Here the MappedReferenceMetaDataResolverDeployer sees the resolvedJndiName to be HelloWorldBean (defaulting to the ejb-name), while the BaseSessionProxyFactory uses the PackagingBasedJndiBindingPolicy default of ee5client-test/HelloWorldBean/remote:

2008-04-23 11:07:17,658 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer] (RMI TCP Connection(4)-127.0.0.1) Processing unit=ee5client-test.jar, structure:
ee5client-test.ear

+ee5client-test-client.jar
++@EJB(helloWorldService) -> mappedName=null| resolvedJndiName=HelloWorldBean

+ee5client-test.jar
++EjbEndpoint:ejbName=HelloWorldBean,ejbClass=org.jboss.test.ee5client.ejb.HelloWorldBean,BusinessRemotes: [org.jboss.test.ee5client.ejb.HelloWorldService]
++EjbEndpoint:ejbName=MessageReplierBean,ejbClass=org.jboss.test.ee5client.ejb.MessageReplierBean

...

2008-04-23 11:07:18,672 DEBUG [org.jboss.ejb3.ProxyFactoryHelper] (RMI TCP Connection(4)-127.0.0.1) Obtaining JNDI name from policy org.jboss.ejb3.jndipolicy.impl.PackagingBasedJndiBindingPolicy
2008-04-23 11:07:18,690 DEBUG [org.jboss.ejb3.session.BaseSessionProxyFactory] (RMI TCP Connection(4)-127.0.0.1) Binding proxy for HelloWorldBean in JNDI at ee5client-test/HelloWorldBean/remote

The jndi names of an ejb need to be available to the resolving deployer so that the metadata can be used as the defining set of info for references and dependencies.

The metadata needs to have the org.jboss.ejb3.jndipolicy.DefaultJndiBindingPolicy interface with ejb3 providing the implementations. The metadata needs to be able to load the implementation as part of its determineJndiName behavior.

The RemoteBindingMetaData change Alexey made was for the legacy ejb2x detached invoker bindings. The equivalent in the ejb3 container is sitting off in some aop config that is not available via the JBossMetaData info. I'm not sure if one can specify alternate jndi bindings for the remoting layer there or not.

[aloubyansky]

Yes, I agree.
Looking at the interface I don't see how an implementation can get access to the metadata. I'd think there should be a way.

[starksm64]

What I'm testing right now is addition of EjbDeploymentSummary, DefaultJndiBindingPolicy to metadata under the org.jboss.metadata.ejb.jboss.jndipolicy.spi and the addition of a determineJndiName(EjbDeploymentSummary) method on JBossEnterpriseBeanMetaData that will load the policy if the default is needed. If there is no policy it will use an org.jboss.metadata.ejb.jboss.jndipolicy.plugins.EjbNameJndiBindingPolicy to derive the jndi names from the ejb-name.

The ejb3 variations of these api can be noop subclasses for backward compatibility if needed.

[aloubyansky]

I guess current determineJndiName logic should be the default one? How is this going to work if the JndiBindingPolicy doesn't have access to the metadata?

[starksm64]

The DefaultJndiBindingPolicy does not accept the metadata. Rather it takes a summary of the ejb deployment/bean in question:

public interface DefaultJndiBindingPolicy
{
 /**
 * Returns the JNDI name that should be assigned to this deployment
 * based on the information contained in the specified summary
 *
 * @param summary
 * @return
 */
 String getJndiName(EjbDeploymentSummary summary);

 String getDefaultRemoteJndiName(EjbDeploymentSummary summary);

 String getDefaultRemoteHomeJndiName(EjbDeploymentSummary summary);

 String getDefaultLocalHomeJndiName(EjbDeploymentSummary summary);

 String getDefaultLocalJndiName(EjbDeploymentSummary summary);
}
public class EjbDeploymentSummary
{
 // Instance Members
 private String deploymentName;
 private String deploymentScopeBaseName;
 private String ejbName;
 private String beanClassName;
 private boolean isLocal;
 private boolean isStateful;
 private boolean isHome;
 private boolean isService;
 private ClassLoader loader;
...
// accessors omitted
}

The determineJndiName(EjbDeploymentSummary) on the base class just implements the default name based on the DefaultJndiBindingPolicy. The entity and session bean metadata still have the determineJndiName() which has the old logic as well as an overriden determineJndiName(EjbDeploymentSummary) which looks at the other sources of jndi names before defaulting to the superclass policy version.

[aloubyansky]

I would make the binding policy responsible for the jndi names and give it access to the metadata.

[starksm64]

We could do that. It requires more changes to the current ext-api org.jboss.ejb3.jndipolicy api, possibly just dropping it in favor of the metadata version. Just need to make the call one way or the other.

[wolfc]

As long as the ear name can somehow be obtained.

[starksm64]

The same type of deployment summary info has to be passed into the metadata layer, and both the metadata and deployment summary would be passed to the jndi policy. The deployment layer has to create the summary view, so that will contain both the parent deployment base name (an ear or standalone jar) and the ejb deployment simple name.

[starksm64]

I created http://jira.jboss.com/jira/browse/EJBTHREE-1321 to move the ejb3-ext-api to metadata.

[starksm64]

This means the ejb3-ext-api will depend on metadata as this annotation would now refer to the DefaultJndiBindingPolicy api from metadata:

public @interface JndiBindingPolicy {

 /**
 * The JNDI Binding Policy that will be used
 *
 * @return
 */
 Class<? extends DefaultJndiBindingPolicy> policy();

}

[wolfc]

The EJB3 deployer should follow the jndi-names mandated. So for now the EJB3 variations can shout a loud warning, then throw IllegalState in the next iteration and then be removed.

The only issue I see is with multiple views. It should be possible to specify a jndi-name per view.

[aloubyansky]

On the other hand, wouldn't it be better to have metadata api represent just the data and take the logic part out of it?
If now we pass the metadata as an argument to the JNDI policy, does it have to be in metadata?

[starksm64]

The api might as well be in metadata since that is where the impl should be specified and there is a dependency on metadata if its passed in. The impls can be outside.

The policy will apply to all views. When determining the jndi names an ejb has we need to loop over the RemoteBindingMetaData (which @RemoteBinding should map to) and use the jndi-name or the policy to determine a default. We need a resolvedJndiName in the RemoteBindingMetaData as well as a getDefaultRemoteBinding(RemoteBindingMetaData) in DefaultJndiBindingPolicy?

[starksm64]

I have moved the api out of ejb3-ext-api into metadata and release beta9 with this change.

There are still code like ProxyDeployer that are going to the binding policy in the absence of any BindingPolicy annotations so what do we want to do to have this set in the metadata?