10 Replies Latest reply on Feb 9, 2006 1:25 PM by gavin.king

    Beta 2: Names vs JNDI, jndiPattern, etc

    rdewell

      I don't know if it was a change in the ejb spec, Seam, or both, but my Seam code has just become a whole lot more complicated and error prone with this new release -- all with regard to the new JNDI naming requirements.

      For example, my *.ejb contains code for multiple web applications. They both have a Login local and LoginImpl SFSB, in different packages of course.

      Previously I could just give them different Seam names:

      @Name("CommerceLogin");
      @Name("ManagementLogin");

      And we were good to go. In Beta 2, though, these two beans are going to share the exact same JNDI name / location, since they're both Login+LoginImpl. Is this a change in the EJB spec? -- why didn't this conflict exist previously?

      So, to be absolutely safe and free of conflicts between the code of both web applications, I'm going to do this on every single bean:

      @Name("CommerceLogin");
      @Stateful(name="CommerceLogin");

      and

      @Name("ManagementLogin");
      @Stateful(name="ManagementLogin");

      What a weird change and a waste of typing. The alternative is to try and make sure that both packages never reuse the same class name which again is odd.

      If this new behavior isn't going away, can Seam at least allow:

      @Name()

      and then derive the name from

      @Stateful(name="**");

      ?

      Also, I'd suggest that Seam issue some kind of WARNING if it detects to Components with the same JNDI name which is what happens in the above example.

      I really like the old way of doing the JNDI lookup by fully qualified class name...

      Best regards,

      Ryan

        • 1. Re: Beta 2: Names vs JNDI, jndiPattern, etc
          gavin.king

          I think it is *extremely* uncommon to have to session beans with the same EJB name in the same EAR.

          • 2. Re: Beta 2: Names vs JNDI, jndiPattern, etc
            gavin.king

            Note that I asked for this change in EJB3 because we had a major problem where Seam apps would not deploy alongside each other because the same local interface existed in multiple EARs.

            So the old way was much more broken.

            • 3. Re: Beta 2: Names vs JNDI, jndiPattern, etc
              jay_stramel

              Although I can see how it was broken for that particular case, the JNDI change has made things much more difficult for many other cases.

              The application I'm working on is comprised of many different deployables and each one has a version number that changes over time. I'm not even sure how to use the new EJB3 look ups to make our application work anymore. I certainly don't want to have to make a new version of every module because the version of one of the modules changed (which I would have to do if I have to start hard-coding the version numbers in the JNDI look ups). I'm guessing that we're going to have to re-name every deployable so that it doesn't have a version. That pretty much sucks.

              The remote vs local change is less disruptive, but even then it seems like the container should be the one to decide if the call needs a remote or local bean.

              Is there something I'm missing with this change? Am I making things too hard for myself some way?

              • 4. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                gavin.king

                huh? So different "versions" lived in different packages?

                This is a very, very strange thing, surely?

                What is so hard about

                @Stateful(name="qualifiedName")

                in these kind of strange cases?

                • 5. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                  jay_stramel

                  Does that mean that if you specify the name with the annotation that the jar name isn't needed to look it up?

                  • 6. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                    gavin.king

                    You always need the name of the EAR. That is because it is perfectly valid and indeed common to have the same bean in multiple EARs.

                    • 7. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                      jay_stramel

                      So is there any way around hard coding ear names into our look ups?

                      • 8. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                        rdewell

                        I guess I always (incorrectly) assumed that JNDI lookups were automatically isolated to the EAR that I'm "in" -- by nature preventing any conflicts across EARs...

                        It's weird to me that by default multiple EARs share the same class / name lookup space.

                        • 9. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                          gavin.king

                           

                          "jay_stramel" wrote:
                          So is there any way around hard coding ear names into our look ups?


                          Sure. You can define a mapping of the global JNDI name into the ENC. (This requires vendor specific metadata, unfortunately; something that needs to be fixed in a future rev of EJB.)

                          But actually, with Seam, you are using org.jboss.seam.core.init.jndiPattern, which means that the JNDI name does not need to be hardcoded anywhere...

                          • 10. Re: Beta 2: Names vs JNDI, jndiPattern, etc
                            gavin.king

                             

                            "rdewell" wrote:
                            I guess I always (incorrectly) assumed that JNDI lookups were automatically isolated to the EAR that I'm "in" -- by nature preventing any conflicts across EARs...


                            ENC lookups are isolated. Not global JNDI lookups.

                            "rdewell" wrote:
                            It's weird to me that by default multiple EARs share the same class / name lookup space.


                            If you define ENC bindings, the don't.