Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      Our shop currently uses Oracle for most projects, most commonly in an application server (Tomcat, WebSphere, etc.), and use configured J2EE datasources. Unfortunately, many of the classes that fix quirks on specific DBMS force you to configure a JDBC connection (look at org.apache.jackrabbit.core.fs.db.OracleFileSystem for instance), which is a "bad idea" on an application server – the application server should be managing resources like DB connections, etc. If you want to use an DbFileSystem based on an Oracle database, you can't use a datasource from a JNDI lookup. This in effect makes Jackrabbit unusable in clustered enterprise environments.

      It would be much better to refactor the current database support to separate the method that an implementation obtains its connection from its functionality.

        Issue Links

          Activity

          Hide
          Thomas Mueller added a comment -

          I agree, all components of Jackrabbit should be able to get the connection via JNDI. This is already implemented in org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory.getConnection which is used in BundleDbPersistenceManager and DbDataStore: For all bundle persistence managers and for the database data store, JNDI can be used to get the connection. In this case, use the javax.naming.InitialContext as the driver and the JNDI name as the URL. User name and password are to be left empty if they are already set in the JNDI resource. Example JNDI settings:

          <param name="driver" value="javax.naming.InitialContext" />
          <param name="url" value="java:comp/env/jdbc/Test" />

          I suggest all components use this mechanism instead of using DriverManager.getConnection directly. To do that, the following classes need to be changed:

          org.apache.jackrabbit.core.fs.db.DbFileSystem
          org.apache.jackrabbit.core.journal.DatabaseJournal
          org.apache.jackrabbit.core.persistence.db.SimpleDbPersistenceManager

          I suggest to deprecate org.apache.jackrabbit.core.journal.JNDIDatabaseJournal. This class is anyway not a solution if somebody wants to use an Oracle database over JNDI: should he use JNDIDatabaseJournal or OracleDatabaseJournal? Also, org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem and org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager should be deprecated.

          Show
          Thomas Mueller added a comment - I agree, all components of Jackrabbit should be able to get the connection via JNDI. This is already implemented in org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory.getConnection which is used in BundleDbPersistenceManager and DbDataStore: For all bundle persistence managers and for the database data store, JNDI can be used to get the connection. In this case, use the javax.naming.InitialContext as the driver and the JNDI name as the URL. User name and password are to be left empty if they are already set in the JNDI resource. Example JNDI settings: <param name="driver" value="javax.naming.InitialContext" /> <param name="url" value="java:comp/env/jdbc/Test" /> I suggest all components use this mechanism instead of using DriverManager.getConnection directly. To do that, the following classes need to be changed: org.apache.jackrabbit.core.fs.db.DbFileSystem org.apache.jackrabbit.core.journal.DatabaseJournal org.apache.jackrabbit.core.persistence.db.SimpleDbPersistenceManager I suggest to deprecate org.apache.jackrabbit.core.journal.JNDIDatabaseJournal. This class is anyway not a solution if somebody wants to use an Oracle database over JNDI: should he use JNDIDatabaseJournal or OracleDatabaseJournal? Also, org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem and org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager should be deprecated.
          Hide
          Thomas Mueller added a comment -

          Fixed in revision 613914 (trunk).
          Unless there is an objection, I will commit the changes to the 1.4 branch as well.

          Show
          Thomas Mueller added a comment - Fixed in revision 613914 (trunk). Unless there is an objection, I will commit the changes to the 1.4 branch as well.
          Hide
          Jukka Zitting added a comment -

          > Unless there is an objection, I will commit the changes to the 1.4 branch as well.

          Please don't. This is more a feature change than a bug fix, and IMHO shouldn't go into the branch. Let's target 1.5 with this change.

          Show
          Jukka Zitting added a comment - > Unless there is an objection, I will commit the changes to the 1.4 branch as well. Please don't. This is more a feature change than a bug fix, and IMHO shouldn't go into the branch. Let's target 1.5 with this change.
          Hide
          Thomas Mueller added a comment -

          Will be resolved in Jackrabbit 1.5

          Show
          Thomas Mueller added a comment - Will be resolved in Jackrabbit 1.5

            People

            • Assignee:
              Thomas Mueller
              Reporter:
              Andy Key
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development