6 Replies Latest reply on Jan 23, 2004 8:32 PM by jonlee

    DataSources Don't Belong in java:/ Space

    acg6764

      As a new user to JBoss, I'm slowly learning the idiosyncracies involved with this application server. After successfully porting our application over to JBoss, I was rather surprised when I realized that our unit tests can't access the JBoss connection pool to get a connection as a result of JNDI lookup failures.

      From what I have gleaned from the numerous previous threads on this topic, the reason normally provided is that "it is not good application design and practice anyway". In my opinion, there *are* several places where the need to access the datasource externally is vital.

      For example, when writing unit tests, things normally do get executed in an external VM. Users should not have move all the code inside an application server just to test it. Also, since when is it an application server's job to enforce "proper design guidelines"? Perhaps suggest, but definitely not enforce.

      JBoss and Sun ONE are the only two application servers on the market that I know of that do this. Other players in the market like Weblogic, Websphere, Oracle 9i, Pramati and even Orion don't enforce this restriction.

      To summarize, I think this restriction makes development harder and presents JBoss as a more difficult proposition to integrate as a *development* server.

      If my assumptions or statements are incorrect or if this isn't the right forum, feel free to comment.

      Thank you,
      Amit Gollapudi

        • 1. Re: DataSources Don't Belong in java:/ Space
          darranl

          So basically you have been caught out with using the proprietary features of a commercial application server.

          Have you considered using Cactus for unit testing?

          • 2. Re: DataSources Don't Belong in java:/ Space
            darranl
            • 3. Re: DataSources Don't Belong in java:/ Space
              acg6764

              Proprietary? How is using unit tests that talk to a database proprietary? Like I mentioned previously, every other application server we've tried works alright other than Sun ONE. Sun ONE may work too with a custom external JVM. JBoss is the only appserver I know of that states that this will not work. I would like to emphasize again that we currently support 4 application servers and are in no way using any proprietary extensions. JNDI lookups to a connection pool aren't exactly uncommon in the J2EE realm.

              Cactus, although a worthwhile product, is geared mainly towards integration tests in my opinion. If my EJBs delegate the database interactions to other classes, then should I not write unit tests for all classes involved?

              I do appreciate your feedback but it seems that rather than addressing the issue, you're redirecting the argument to our application design by calling it flawed.

              • 4. Re: DataSources Don't Belong in java:/ Space
                jcprout

                From the J2EE 1.3 spec, a client should have access to java: in the JNDI namespace. Section 9.4:

                As with all J2EE components, application clients use JNDI to look up enterprise beans, to get access to resource managers, to reference configurable parameters set at deployment time, etc. Application clients use the java: JNDI namespace to access these items.

                A connection pool should be available through this mechanism, but I don't think JBoss yet supports this

                • 5. Re: DataSources Don't Belong in java:/ Space
                  acg6764

                  jcprout:

                  That is very interesting information. In the threads I had found so far by searching this forum, the claim was that the "java:" prefix implies (atleast as far as JBoss is concerned), an in-jvm namespace. And my understanding was that that was the reason for not allowing access to resources such as connection pools. It appeared as though the intent by JBoss developers was not to modify this behavior now or in the future. That is why I was proposing moving DataSources out of this namespace.

                  However, with the information you presented in light, I hope JBoss will support java: namespace lookups in the near future (4.0?). I'm just really surprised that even after the myriads of posts concerning this topic in these forums, this feature has not been implemented yet.

                  Does anyone in the development community have any comments on this topic?

                  • 6. Re: DataSources Don't Belong in java:/ Space
                    jonlee

                    The distinction made, as I understand it, is that the "java:/" is not available external to the JVM in which the JNDI schema is created, as opposed to "java:". That is; "java:/myObject" is not the same as "java:myObject". And there are security reasons for which you may not want objects accessible from an external JVM.

                    The issue with regards to access to the datasource from an external JVM in JBoss is ultimately a physical restriction with connections rather than an arbitrary choice by the JBoss developers. The DataSource is just a connection factory.

                    The physical connection is manifested between the JVM in which the DataSource is instantiated, and the actual datasource (database). Passing the connection handle (Connection) to an external environment would be of little use. Now the JBoss developers might produce a proxy implementation for connections manufactured from the DataSource but the cost benefits of a connection pool are diminished by the cost of establishing a separate connection between the external JVM and the JVM in which the real datasource connection resides.

                    Secondly, were JBoss developers to develop a proxy implementation for the connection pool, there is no security restriction inherent in the Connection manufacture from a DataSource such that exposing the DataSource to external access opens the datasource to possible malicious attack from unauthorised parties.

                    MHO.