14 Replies Latest reply on May 22, 2008 5:20 PM by Carlo de Wolf

    JBMETA-42

    Scott Stark Master

      What do you mean by this Andrew?


      My last commit introduced no regression but has now interfered with the policy's expectations of bases upon which to build. As shown from the Proxy TestSuite:

      02:24:31,424 INFO [ProxySessionTestCase] Business Remote JNDI Name: MyStatelessBean/remote
      02:24:31,427 INFO [ProxySessionTestCase] Business Remote JNDI Name for org.jboss.ejb3.test.proxy.session.MyStatelessRemote: MyStatelessBean/remote/remote-org.jboss.ejb3.test.proxy.session.MyStatelessRemote
      02:24:31,427 INFO [ProxySessionTestCase] Local JNDI Name: MyStatelessBean/local
      02:24:31,427 INFO [ProxySessionTestCase] Business Local JNDI Name for org.jboss.ejb3.test.proxy.session.MyStatelessLocal: MyStatelessBean/remote/local-org.jboss.ejb3.test.proxy.session.MyStatelessLocal
      02:24:31,427 INFO [ProxySessionTestCase] Local Home JNDI Name: MyStatelessBean/remote/localHome
      02:24:31,427 INFO [ProxySessionTestCase] Home JNDI Name: MyStatelessBean/remote/remoteHome



        • 1. Re: JBMETA-42
          Andrew Rubinger Master

          In revision 73473 (http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=73473) I fixed 2 of the 6 Unit Tests that Carlo had committed. No regression in jboss-metadata occurred as a side effect.

          However, look at the base names now found for Business Remote (specific) Interface, Business Local (specific) interface, home and local home - they've got a baseName of:

          MyStatelessBean/remote

          ...instead of the expected:

          MyStatelessBean

          ...when a DeploymentSummary is present.

          Best I can tell is that there's a disconnect in "determineResolvedJndiName" when there's a DeploymentSummary in place, which is not always the case.

          S,
          ALR

          • 2. Re: JBMETA-42
            Scott Stark Master

            The change to determineLocalJndiName to drop the unique System.identityHashCode portion won't be valid for ejb2 deployments where there are multiple ejb jars that have the same ejb-names for beans with local interfaces, or mdbs. The same problem should exist for ejb3 as well doesn't? How are two standalone ejb3 jars each with a LocalBean going to share the same LocalBean/local global binding?

            I need to look at the tests to see what the issue is.

            • 3. Re: JBMETA-42
              Carlo de Wolf Master

               

              "scott.stark@jboss.org" wrote:
              How are two standalone ejb3 jars each with a LocalBean going to share the same LocalBean/local global binding?

              They don't. You'll get an error.

              • 4. Re: JBMETA-42
                Andrew Rubinger Master

                By default, we'll also run into Global JNDI collisions in the case that 2 EJB JARs (or EARs) are placed in different WARs.

                To avoid these defaults we introduced the JndiBindingPolicies, which should have priority over the commits I made.

                S,
                ALR

                • 5. Re: JBMETA-42
                  Andrew Rubinger Master

                  Also, if I introduced something that'll present a problem for EJB2, we should have a Unit Test for it? Tests green == commit away.

                  S,
                  ALR

                  • 6. Re: JBMETA-42
                    Scott Stark Master

                     



                    This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?

                    No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given.


                    • 7. Re: JBMETA-42
                      Andrew Rubinger Master

                      I'll stop mucking in there then. :)

                      S,
                      ALR

                      • 8. Re: JBMETA-42
                        Carlo de Wolf Master

                         

                        "scott.stark@jboss.org" wrote:
                        This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?

                        No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given.

                        That can't be. All jndi names must be unique or you'll get a NotContextException.

                        As already shown by Andrews prototype, my original idea of having the object factory bound at at a base jndi name turned out to be a 'Bad Idea (tm)'.

                        So the tests in ResolvedJndiNameUnitTestCase are out-dated in that respect.

                        What I also said was that the final jndi name is overridable. So if a jndi-name is set in jboss.xml then beanMD.determineResolvedJndiName(KnownInterfaces.REMOTE, null); must return that jndi-name.
                        This is just plain wrong in ResolvedJndiNameUnitTestCase.

                        There is a side issue where JBossWS expects to find a home interface on the jndi name. This might also be the case for EJB 2.1 compatibility.

                        • 9. Re: JBMETA-42
                          Carlo de Wolf Master

                          Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy.
                          As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself.

                          Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup?

                          • 10. Re: JBMETA-42
                            Scott Stark Master

                             

                            "wolfc" wrote:
                            Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy.
                            As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself.

                            Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup?

                            The profile service would only store the non-XmlTransient values, so as long determineResolvedJndiName does not set something like the jndiName, mappedName, its not interfering with the administered view.

                            • 11. Re: JBMETA-42
                              Carlo de Wolf Master

                              But does it store the orginal JBossSessionBeanMetaData, the merged one, or the final one (in this case JBossSessionPolicyDecorator)?

                              • 12. Re: JBMETA-42
                                Scott Stark Master

                                It stores the non-transient managed attachments. Any attachments derived from the managed metadata should be transient attachments that are not stored. Merged metadata should be transient. The deployer that adds the attachment controls this.

                                • 13. Re: JBMETA-42
                                  Carlo de Wolf Master

                                  In that case I vote in favor of patch 2 and removing the JNDI policy functionality from the base JBossSessionBeanMetaData.

                                  • 14. Re: JBMETA-42
                                    Carlo de Wolf Master

                                    Committed patch 2 as it introduces no regression.