You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Andy Key (JIRA)" <ji...@apache.org> on 2008/01/14 16:52:34 UTC
[jira] Created: (JCR-1309) Refactor DBMS support for JNDI
datasources
Refactor DBMS support for JNDI datasources
------------------------------------------
Key: JCR-1309
URL: https://issues.apache.org/jira/browse/JCR-1309
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Affects Versions: 1.3.3
Reporter: Andy Key
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1309) Refactor DBMS support for JNDI
datasources
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561033#action_12561033 ]
Thomas Mueller commented on JCR-1309:
-------------------------------------
Fixed in revision 613914 (trunk).
Unless there is an objection, I will commit the changes to the 1.4 branch as well.
> Refactor DBMS support for JNDI datasources
> ------------------------------------------
>
> Key: JCR-1309
> URL: https://issues.apache.org/jira/browse/JCR-1309
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 1.3.3
> Reporter: Andy Key
> Assignee: Thomas Mueller
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1309) Refactor DBMS support for JNDI
datasources
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560967#action_12560967 ]
Thomas Mueller commented on JCR-1309:
-------------------------------------
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.
> Refactor DBMS support for JNDI datasources
> ------------------------------------------
>
> Key: JCR-1309
> URL: https://issues.apache.org/jira/browse/JCR-1309
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 1.3.3
> Reporter: Andy Key
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1309) Refactor DBMS support for JNDI
datasources
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller reassigned JCR-1309:
-----------------------------------
Assignee: Thomas Mueller
> Refactor DBMS support for JNDI datasources
> ------------------------------------------
>
> Key: JCR-1309
> URL: https://issues.apache.org/jira/browse/JCR-1309
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 1.3.3
> Reporter: Andy Key
> Assignee: Thomas Mueller
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1309) Refactor DBMS support for JNDI
datasources
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller resolved JCR-1309.
---------------------------------
Resolution: Fixed
Will be resolved in Jackrabbit 1.5
> Refactor DBMS support for JNDI datasources
> ------------------------------------------
>
> Key: JCR-1309
> URL: https://issues.apache.org/jira/browse/JCR-1309
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Andy Key
> Assignee: Thomas Mueller
> Fix For: 1.5
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1309) Refactor DBMS support for JNDI
datasources
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1309:
-------------------------------
Affects Version/s: (was: 1.3.3)
Fix Version/s: 1.5
> 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.
> Refactor DBMS support for JNDI datasources
> ------------------------------------------
>
> Key: JCR-1309
> URL: https://issues.apache.org/jira/browse/JCR-1309
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Andy Key
> Assignee: Thomas Mueller
> Fix For: 1.5
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.