You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Hemanta Gupta (JIRA)" <ji...@apache.org> on 2007/05/25 06:57:16 UTC
[jira] Created: (JCR-942) Thoughts on supporting JNDI based Oracle
file system/persistence manager implementations
Thoughts on supporting JNDI based Oracle file system/persistence manager implementations
----------------------------------------------------------------------------------------
Key: JCR-942
URL: https://issues.apache.org/jira/browse/JCR-942
Project: Jackrabbit
Issue Type: Improvement
Components: core
Affects Versions: 1.3
Environment: Oracle 10g
Reporter: Hemanta Gupta
Priority: Minor
This may not be relevant for too many people, but I faced a situation where I couldn't use the stock Oracle file system and persistence manager implementations since we couldn't place the clear text DB password in repository.xml (for security reasons).
I tried adapting the classes to use a data-source instead, but this didn't work out immediately because of the Oracle specific blob handling being performed by these classes. They expect the connection to be the original native connection returned by the driver, so in the case of wrapped connections returned by managed data-sources, a ClassCastException is thrown by oracle.sql.BLOB.createTemporary().
I finally got things working thanks to the fact that both application servers we support (JBoss and WebLogic) allow extraction of the native connection from a wrapped managed connection. Spring's NativeJdbcExtractor interface proved very helpful here; I simply used the right implementation for extracting the native connection and using it wherever I thought it was required (modified code to be attached later).
So to sum up, would it be possible for JR to provide this kind of functionality out-of-the-box? To be specific, could you provide JNDI based Oracle file system and persistence manager implementations where we can plug in some kind of native connection extractor, and have the implementations internally use the native connection for Oracle specific stuff?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-942) Thoughts on supporting JNDI based Oracle
file system/persistence manager implementations
Posted by "Hemanta Gupta (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hemanta Gupta updated JCR-942:
------------------------------
Attachment: OracleJNDIFileSystem.java
Attaching modified file system implementation which uses a data-source and a native connection extractor (see usages of getNativeConnection()).
> Thoughts on supporting JNDI based Oracle file system/persistence manager implementations
> ----------------------------------------------------------------------------------------
>
> Key: JCR-942
> URL: https://issues.apache.org/jira/browse/JCR-942
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.3
> Environment: Oracle 10g
> Reporter: Hemanta Gupta
> Priority: Minor
> Attachments: OracleJNDIFileSystem.java
>
>
> This may not be relevant for too many people, but I faced a situation where I couldn't use the stock Oracle file system and persistence manager implementations since we couldn't place the clear text DB password in repository.xml (for security reasons).
> I tried adapting the classes to use a data-source instead, but this didn't work out immediately because of the Oracle specific blob handling being performed by these classes. They expect the connection to be the original native connection returned by the driver, so in the case of wrapped connections returned by managed data-sources, a ClassCastException is thrown by oracle.sql.BLOB.createTemporary().
> I finally got things working thanks to the fact that both application servers we support (JBoss and WebLogic) allow extraction of the native connection from a wrapped managed connection. Spring's NativeJdbcExtractor interface proved very helpful here; I simply used the right implementation for extracting the native connection and using it wherever I thought it was required (modified code to be attached later).
> So to sum up, would it be possible for JR to provide this kind of functionality out-of-the-box? To be specific, could you provide JNDI based Oracle file system and persistence manager implementations where we can plug in some kind of native connection extractor, and have the implementations internally use the native connection for Oracle specific stuff?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-942) Thoughts on supporting JNDI based Oracle
file system/persistence manager implementations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-942:
------------------------------
Affects Version/s: (was: 1.3)
Status: Open (was: Patch Available)
Sorry for the *long* delay before anyone looked at this!
The proposed new class looks good to me, but is there a way to avoid using the NativeJdbcExtractor and ClassLoaderUtils classes that aren't included in Jackrabbit or any of its current dependencies?
> Thoughts on supporting JNDI based Oracle file system/persistence manager implementations
> ----------------------------------------------------------------------------------------
>
> Key: JCR-942
> URL: https://issues.apache.org/jira/browse/JCR-942
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Environment: Oracle 10g
> Reporter: Hemanta Gupta
> Priority: Minor
> Attachments: OracleJNDIFileSystem.java
>
>
> This may not be relevant for too many people, but I faced a situation where I couldn't use the stock Oracle file system and persistence manager implementations since we couldn't place the clear text DB password in repository.xml (for security reasons).
> I tried adapting the classes to use a data-source instead, but this didn't work out immediately because of the Oracle specific blob handling being performed by these classes. They expect the connection to be the original native connection returned by the driver, so in the case of wrapped connections returned by managed data-sources, a ClassCastException is thrown by oracle.sql.BLOB.createTemporary().
> I finally got things working thanks to the fact that both application servers we support (JBoss and WebLogic) allow extraction of the native connection from a wrapped managed connection. Spring's NativeJdbcExtractor interface proved very helpful here; I simply used the right implementation for extracting the native connection and using it wherever I thought it was required (modified code to be attached later).
> So to sum up, would it be possible for JR to provide this kind of functionality out-of-the-box? To be specific, could you provide JNDI based Oracle file system and persistence manager implementations where we can plug in some kind of native connection extractor, and have the implementations internally use the native connection for Oracle specific stuff?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-942) Thoughts on supporting JNDI based Oracle
file system/persistence manager implementations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-942:
------------------------------
Status: Patch Available (was: Open)
> Thoughts on supporting JNDI based Oracle file system/persistence manager implementations
> ----------------------------------------------------------------------------------------
>
> Key: JCR-942
> URL: https://issues.apache.org/jira/browse/JCR-942
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 1.3
> Environment: Oracle 10g
> Reporter: Hemanta Gupta
> Priority: Minor
> Attachments: OracleJNDIFileSystem.java
>
>
> This may not be relevant for too many people, but I faced a situation where I couldn't use the stock Oracle file system and persistence manager implementations since we couldn't place the clear text DB password in repository.xml (for security reasons).
> I tried adapting the classes to use a data-source instead, but this didn't work out immediately because of the Oracle specific blob handling being performed by these classes. They expect the connection to be the original native connection returned by the driver, so in the case of wrapped connections returned by managed data-sources, a ClassCastException is thrown by oracle.sql.BLOB.createTemporary().
> I finally got things working thanks to the fact that both application servers we support (JBoss and WebLogic) allow extraction of the native connection from a wrapped managed connection. Spring's NativeJdbcExtractor interface proved very helpful here; I simply used the right implementation for extracting the native connection and using it wherever I thought it was required (modified code to be attached later).
> So to sum up, would it be possible for JR to provide this kind of functionality out-of-the-box? To be specific, could you provide JNDI based Oracle file system and persistence manager implementations where we can plug in some kind of native connection extractor, and have the implementations internally use the native connection for Oracle specific stuff?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-942) Thoughts on supporting JNDI based
Oracle file system/persistence manager implementations
Posted by "Graeme Steyn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880382#action_12880382 ]
Graeme Steyn commented on JCR-942:
----------------------------------
I have run into the same problem when attempting to use Jackrabbit 1.6.1 with SpringSource tc Server (Tomcat 6.0.25). If you use any form of wrapped JNDI source, you will experience this problem, e.g. using C3PO, DBCP, tc Server High Concurrency pool. Thi sis a bi tfrustrating as the only way to use Oracle via JNDI with Liferay 5.2 EE SP4 and Jackrabbit is to defined the JNDI resource as being a type that returns the native connection, e.g. Oracle UCP.
> Thoughts on supporting JNDI based Oracle file system/persistence manager implementations
> ----------------------------------------------------------------------------------------
>
> Key: JCR-942
> URL: https://issues.apache.org/jira/browse/JCR-942
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Environment: Oracle 10g
> Reporter: Hemanta Gupta
> Priority: Minor
> Attachments: OracleJNDIFileSystem.java
>
>
> This may not be relevant for too many people, but I faced a situation where I couldn't use the stock Oracle file system and persistence manager implementations since we couldn't place the clear text DB password in repository.xml (for security reasons).
> I tried adapting the classes to use a data-source instead, but this didn't work out immediately because of the Oracle specific blob handling being performed by these classes. They expect the connection to be the original native connection returned by the driver, so in the case of wrapped connections returned by managed data-sources, a ClassCastException is thrown by oracle.sql.BLOB.createTemporary().
> I finally got things working thanks to the fact that both application servers we support (JBoss and WebLogic) allow extraction of the native connection from a wrapped managed connection. Spring's NativeJdbcExtractor interface proved very helpful here; I simply used the right implementation for extracting the native connection and using it wherever I thought it was required (modified code to be attached later).
> So to sum up, would it be possible for JR to provide this kind of functionality out-of-the-box? To be specific, could you provide JNDI based Oracle file system and persistence manager implementations where we can plug in some kind of native connection extractor, and have the implementations internally use the native connection for Oracle specific stuff?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.