-
1. Re: appclient remote home regression
starksm64 Jul 22, 2008 3:35 PM (in response to starksm64)So the MappedReferenceMetaDataResolverDeployer ends up doing:
// Determine the jndi name for the reference interface String iface = getInterface(ref); //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy(); String containerJndiName = target.getBeanMetaData().determineJndiName(); if(containerJndiName != null) ref.setResolvedJndiName(containerJndiName);
and the metadata determineJndiName() is implemented by JBossSessionPolicyDecorator.determineJndiName(), which calls JBossSessionPolicyDecorator.determineResolvedRemoteBusinessDefaultJndiName(). This is for an ejb3x remote reference, not an ejb2x remote home reference. The call to getInterface(ref) is unused. The resulting iface should be getting passed into determineResolvedJndiName(String iface) so the iface can be recognized as a home rather than a remote business interface.
What we need is a comprehensive metadata unit test that takes each type of ejb reference metadata, and resolves a jndi name for both ejb2x, ejb3x bean metadata. This is what the MappedReferenceMetaDataResolverDeployer needs to set each reference resolved jndi name. -
2. Re: appclient remote home regression
alrubinger Jul 22, 2008 4:44 PM (in response to starksm64)"scott.stark@jboss.org wrote:
The issue is that the MappedReferenceMetaDataResolverDeployer will have to resolve the ejb-ref differently based on whether the target ejb is a 2.x or 3.x. We should have this info available in the binding policy, so I need to see what is going on with not using it. I guess its just that the server specified binding policy is not in synch with the current ejb3 behavior.
The binding policy should know whether the target is EJB2 or EJB3? Nah, it's just a policy!
This is why I'd moved the policies away from the object model; at deployment we can now attach a binding policy to an EJB, and from then on the caller (Mapped Reference Deployer) doesn't need to choose (because it can do so incorrectly).
So far as the server binding policy being out of sync w/ EJB3 handling...they should both be pointing to the same thing at this point. See code below. Or am I missing somewhere else?"scott.stark@jboss.org wrote:
Is the ejb3 proxy layer using the deployment binding policy for all proxies yet? Looking at the code this does not appear to be the case.
Yes, the Binding Policy is added at deploy-time via:
http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/ejb/deployers/EjbMetadataJndiPolicyDecoratorDeployer.java
..and is picked up transparently by the code currently in EJB3 Core (I'm integrating EJB3 Proxy now). From BaseSessionProxyFactory.bindEjb:// Bind the proxy itself log.debug("Binding proxy for " + getContainer().getEjbName() + " in JNDI at " + this.getJndiName()); Util.rebind(getContainer().getInitialContext(), this.getJndiName(), proxy); // Bind a proxy per business interface //TODO This ugly block should be using polymorphism, but I'll allow it as the proxy mechanism // is going to be replaced entirely by EJB3 Proxy soon JBossSessionBeanMetaData smd = (JBossSessionBeanMetaData) container.getXml(); BusinessRemotesMetaData remotes = smd.getBusinessRemotes(); BusinessLocalsMetaData locals = smd.getBusinessLocals(); Set<String> businessInterfaces = new HashSet<String>(); boolean isLocal = this.isLocal(); if (!isLocal) { if (remotes != null) { businessInterfaces.addAll(remotes); } } else { if (locals != null) { businessInterfaces.addAll(locals); } } for (String businessInterface : businessInterfaces) { String jndiName = JbossSessionBeanJndiNameResolver.resolveJndiName(smd, businessInterface); log.debug("Binding proxy for " + getContainer().getEjbName() + ", interface " + businessInterface + " in JNDI at " + jndiName); if (Proxy.isProxyClass(proxy.getClass())) { for (Class<?> in : proxy.getClass().getInterfaces()) { log.debug("Proxy Interface for JNDI Name " + jndiName + ": " + in); } } Util.rebind(this.getContainer().getInitialContext(), jndiName, proxy); }
-
3. Re: appclient remote home regression
alrubinger Jul 22, 2008 4:50 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
So the MappedReferenceMetaDataResolverDeployer ends up doing:// Determine the jndi name for the reference interface String iface = getInterface(ref); //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy(); String containerJndiName = target.getBeanMetaData().determineJndiName(); if(containerJndiName != null) ref.setResolvedJndiName(containerJndiName);
Should like look more like:// Determine the jndi name for the reference interface String iface = getInterface(ref); String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(iface); if(containerJndiName != null) ref.setResolvedJndiName(containerJndiName);
?
S,
ALR -
4. Re: appclient remote home regression
starksm64 Jul 22, 2008 7:33 PM (in response to starksm64)"ALRubinger" wrote:
Should like look more like:// Determine the jndi name for the reference interface String iface = getInterface(ref); String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(iface); if(containerJndiName != null) ref.setResolvedJndiName(containerJndiName);
?
Yes, otherwise info is being thrown away. If I make that change the 1x_50 tests pass, but the ejb2x based tests start failing. I'm looking at why now. -
5. Re: appclient remote home regression
starksm64 Jul 22, 2008 8:54 PM (in response to starksm64)The problem is that the BasicJndiBindingPolicy that is the default used by the metadata layer is returning a remote home that is not compatible with the given jndi-name. Its returning the basename derived from the deployment summary which is an ejb3ism. I thought we had ejb2 style tests for the binding policy in metadata. Either the test is missing or its been changed to match the deployment scoped name, which is not compatible with how ejb2 homes are bound.
https://jira.jboss.org/jira/browse/JBMETA-79 -
6. Re: appclient remote home regression
alrubinger Jul 22, 2008 9:38 PM (in response to starksm64)So this was likely introduced in tandem with fixes for JBMETA-78.
http://fisheye.jboss.org/changelog/JBossAS/?cs=76015
So the tests were also aligned to match:
http://wiki.jboss.org/wiki/DevJNDIBinding
...which *does* call for a base name in EJB2.x Homes.
Or are we confusing "EJB2.x Homes" for "EJB2.x View of EJB3"? If so, can we further remove *all* determine* logic from the object model and apply the LegacyEjbJndiPolicy to EJB2.x deployments via a new Deployer, much like I'm doing w/ BasicJndiBindingPolicy for EJB3?
We're *still* fighting against each other in circles. :) I think the refactoring done in jboss-metadata to remove the JNDI Policy from the caller is the right direction in which to head, but please let me know how to want to handle the above.
Also note, BasicJndiBindingPolicy *is* for EJB3...EJB2.x should be using another policy.
S,
ALR -
7. Re: appclient remote home regression
alrubinger Jul 22, 2008 10:36 PM (in response to starksm64)I follow what you're getting at with the new test, "testRemoteHomeWithEarScope".
Problem I see is that "sbeanMD" is not decorated with any JNDI Policy, instead falling back on the @Deprecated methods with too much (improper) logic.
Why don't we introduce a JNDI Policy for EJB2, decorate with it at the deployer level, and get rid of the "detemine*" methods alltogether? I'm either sitting on the panacea of simple fixes which resolve all this, or am missing something big. :)
S,
ALR -
8. Re: appclient remote home regression
starksm64 Jul 22, 2008 10:45 PM (in response to starksm64)With the changes I made for JBMETA-79, all the appclient tests are passing.
We can add a decorator, but the current BasicJndiBindingPolicy is simply broken for ejb2x behavior when there is a deployment summary with an ear scope, so it needs to be fixed. This was not being tested. All that was tested was an empty deployment summary. -
9. Re: appclient remote home regression
alrubinger Jul 22, 2008 10:52 PM (in response to starksm64)This is what I'm not understanding. I thought BasicJndiBindingPolicy was only for EJB3. EJB2 would follow a different pattern, and it'd be handled there, no?
S,
ALR -
10. Re: appclient remote home regression
alrubinger Jul 22, 2008 10:57 PM (in response to starksm64)I see. An EJB3 Deployment, but EJB2.x Home Views.
S,
ALR -
11. Re: appclient remote home regression
starksm64 Jul 23, 2008 12:30 AM (in response to starksm64)BasicJndiBindingPolicy is for both ejb3/2. The MappedReferenceMetaDataResolverDeployer needs the metadata to provide the jndi name for both types of reference targets. Whether its a decorator or policy does not matter.