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

          Andy Key created issue -
          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.
          Thomas Mueller made changes -
          Field Original Value New Value
          Assignee Thomas Mueller [ tmueller ]
          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.
          Jukka Zitting made changes -
          Fix Version/s 1.5 [ 12312920 ]
          Affects Version/s 1.3.3 [ 12312770 ]
          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
          Thomas Mueller made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Jukka Zitting made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Martijn Hendriks made changes -
          Link This issue blocks JCR-1693 [ JCR-1693 ]
          Jukka Zitting made changes -
          Workflow jira [ 12420836 ] no-reopen-closed, patch-avail [ 12468263 ]
          Gavin made changes -
          Link This issue blocks JCR-1693 [ JCR-1693 ]
          Gavin made changes -
          Link This issue is depended upon by JCR-1693 [ JCR-1693 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          92d 22h 15m 1 Thomas Mueller 16/Apr/08 15:07
          Resolved Resolved Closed Closed
          235d 21h 1 Jukka Zitting 08/Dec/08 11:07

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development