I'll only cover @EJB on class level, because method and field just add beanInterface and name to the mix.
@EJB(name="ejb1", mappedName="refs/client/EJB1")
@EJB(name="ejb1")
@EJB(name="ejb1", beanInterface=IFace1.class)
@EJB(name="ejb1", beanName="Ejb2Bean")
@EJB(name="ejb1", beanName="../myjar.jar#Ejb3Bean")
This is an algorithm, not an api. I need the api on the metadata layer we agree to use for dependency resolution and when the proxy goes to actually bind into jndi.
My problems with Proxies and Scott's with JNDI Metadata have converged here.
The solution that will enable us to further decouple and get resolution more in-line with the current direction is to add the "resolvedJndiName" property accessors to JBossEnterpriseBeanMetaData, effective metadata-1.0.0.Beta12.
From there we can make another step towards decoupling the Proxy/ProxyFactory components from the Containers (read: EJB3 Core).
It'll then be the responsibility of the MappedReferenceMetaDataResolverDeployer to properly resolve the JNDI name in the case of @RemoteBinding overrides.
An issue exposed here is that @RemoteBindings(Array) is non-deterministic at the class level in the case that more than one interface is defined on the bean. For now, I'll assume that each @RemoteBinding in the specified array should be used on each of the business interfaces (creating multiple bindings).
Still to be covered is the handling of "getInvokedBusinessInterface()" under this mechanism, I'm looking into those tests now.
S,
ALR