11 Replies Latest reply on Jul 23, 2008 12:30 AM by Scott Stark

    appclient remote home regression

    Scott Stark Master

      I'm seeing the same 3 errors in the appclient tck tests as currently seen in the tck runs:
      http://hudson.qa.jboss.com/hudson/view/TCK5/job/tck5-appclient/lastBuild/testReport/unknownTestSuite.0/

      in the mc/vfs appclient work I'm doing, so its just a general regression in the jndi name of the ejb remote home. The home is resolving to the descriptor jndi-name, but the home is bound under ear-name/bean-name/home. These tests are effectively deploying ejb2.x beans as ejb3.x beans(no annotations, just a v3 ejb-jar.xml), and a j2ee 1.4 or earlier client is linking to the ejb using its bean name. Its a descriptor ejb-ref with a remote/home specified.

      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. 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.

        • 1. Re: appclient remote home regression
          Scott Stark Master

          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
            Andrew Rubinger Master

             

            "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
              Andrew Rubinger Master

               

              "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
                Scott Stark Master

                 

                "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
                  Scott Stark Master

                  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
                    Andrew Rubinger Master

                    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
                      Andrew Rubinger Master

                      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
                        Scott Stark Master

                        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
                          Andrew Rubinger Master

                          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
                            Andrew Rubinger Master

                            I see. An EJB3 Deployment, but EJB2.x Home Views.

                            S,
                            ALR

                            • 11. Re: appclient remote home regression
                              Scott Stark Master

                              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.