Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 42260 invoked from network); 15 May 2009 07:59:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 May 2009 07:59:10 -0000 Received: (qmail 41988 invoked by uid 500); 15 May 2009 07:59:10 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 41945 invoked by uid 500); 15 May 2009 07:59:10 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 41937 invoked by uid 99); 15 May 2009 07:59:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 07:59:10 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 07:59:06 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 8C686234C004 for ; Fri, 15 May 2009 00:58:45 -0700 (PDT) Message-ID: <1960109020.1242374325560.JavaMail.jira@brutus> Date: Fri, 15 May 2009 00:58:45 -0700 (PDT) From: "Serge Huber (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2 In-Reply-To: <486085487.1207593924880.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709752#action_12709752 ] Serge Huber commented on JCR-1525: ---------------------------------- Actually in the most recent versions of the Oracle driver (11) we no longer need the Oracle BLOB specific code. And the new driver solves this even for older versions of Oracle. If you're interested I have a patch for that also. But it's not clear to me if it's acceptable to Jackrabbit to have a dependency on the latest version of the driver ? Here is the extract from the README for the new driver : "New Factory Methods The JDBC 4.0 spec for java.sql.Connection includes factory methods for creating instances of the standard JDBC types, Array, Blob, Clob, etc. Building on this concept Oracle JDBC 11R1 oracle.jdbc.OracleConnection provides factory methods for creating instances of the Oracle specific types. Best practice is to use the standard JDBC types and the new factory methods. When it is necessary to use the Oracle specific types best practice is to create them via the new factory methods. Direct customer access to the the constructors for these types will be deprecated and later desupported. The supported types are all those in oracle.sql, including ARRAY, BFILE, DATE, INTERVALDS, NUMBER, STRUCT, TIME, TIMESTAMP, etc." Regards, Serge > Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2 > ------------------------------------------------------------------------------------------ > > Key: JCR-1525 > URL: https://issues.apache.org/jira/browse/JCR-1525 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core > Reporter: Esteban Franqueiro > Attachments: JCR-1525.patch > > > In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This special handling is no longer necesary for Oracle 10.2+, so we should provide a new implementation. As discussed on the list, we can create a new class for Oracle 10.2+, make it inherit from DbFileSystem, and override the createSchema(), and table space related methods, which are the ones that need special handling. Furthermore, we could refactor the current OracleFileSystem and break it into two clases, one of them to keep the current behavior and a new one to keep the common code (which we could rename to OracleBaseFileSystem or similar, to maintain compatiblity with code that uses OracleFileSystem for versions previous to 10.2). Then we make the Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.