Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1562

JNDI data sources with various PersistenceManager: wrong default values

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: core 1.4.2, core 1.4.3, core 1.4.4
    • Fix Version/s: core 1.4.5
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      With JCR-1305 Jackrabbit supports creating a connection throug a JNDI Datasource and without configuring user and password. This works for some but not all provided PersistenceManagers. Some of them - like the Oracle-specific BundleDBPersistenceManager - sets default values for user and password if none are provided in the jackrabbit config. This way its impossible to use such PersistenceManagers with the plain JNDI DS.

      This concerns the following BundleDbPersistenceManagers: OraclePersistenceManager, DerbyPersistenceManager, H2PersistenceManager.

      There also might be other PMs (perhaps some special SimpleDbPersistenceManagers) with similar behaviour.

        Activity

        Hide
        Thomas Mueller added a comment -

        I agree, the default value for user name and password should be null (or an empty string if the database doesn't support that).

        Show
        Thomas Mueller added a comment - I agree, the default value for user name and password should be null (or an empty string if the database doesn't support that).
        Hide
        Thomas Mueller added a comment -

        By the way, Derby seems to simply ignored user name and password. Funny

        Show
        Thomas Mueller added a comment - By the way, Derby seems to simply ignored user name and password. Funny
        Hide
        Thomas Mueller added a comment -

        We need to think about backward compatibility. Do we just document this change (simpler)? Or do we use empty passwords only when using JNDI (good for compatibility)?

        Show
        Thomas Mueller added a comment - We need to think about backward compatibility. Do we just document this change (simpler)? Or do we use empty passwords only when using JNDI (good for compatibility)?
        Hide
        Thomas Mueller added a comment -

        This patch removes the default user name and password for Oracle, H2, and Derby.

        This will always work in Derby as Derby doesn't check user names and passwords by default.

        For Oracle and H2 the problem is backward compatibility: if user name and password was not configured in previous installations, the old default values (sa for H2, crx for Oracle) were used. For Oracle, a user name and password is required in any case. I think this is a problem, but the best way to solve it is (in my view) to document this change in the release notes.

        If nobody objects, I will commit this change in a few days.

        Show
        Thomas Mueller added a comment - This patch removes the default user name and password for Oracle, H2, and Derby. This will always work in Derby as Derby doesn't check user names and passwords by default. For Oracle and H2 the problem is backward compatibility: if user name and password was not configured in previous installations, the old default values (sa for H2, crx for Oracle) were used. For Oracle, a user name and password is required in any case. I think this is a problem, but the best way to solve it is (in my view) to document this change in the release notes. If nobody objects, I will commit this change in a few days.
        Hide
        Jukka Zitting added a comment -

        +1 to dropping the defaults and documenting the change

        Show
        Jukka Zitting added a comment - +1 to dropping the defaults and documenting the change
        Hide
        fabrizio giustina added a comment -

        I noticed that also the schema gets default values, for example in oracle:

        if (getSchema() == null)

        { setSchema("oracle"); }

        shouldn't that be removed too?

        Show
        fabrizio giustina added a comment - I noticed that also the schema gets default values, for example in oracle: if (getSchema() == null) { setSchema("oracle"); } shouldn't that be removed too?
        Hide
        Thomas Mueller added a comment -

        > if (getSchema() == null)

        { > setSchema("oracle"); > }

        > shouldn't that be removed too?

        No. The term 'schema' is a bit misleading: here the schema property controls what .ddl file to use to create the tables. For Oracle, the file src/main/resources/org/apache/jackrabbit/core/persistence/bundle/oracle.ddl file is used. It doesn't have to do with the database schema.

        See also http://issues.apache.org/jira/browse/JCR-1180

        Show
        Thomas Mueller added a comment - > if (getSchema() == null) { > setSchema("oracle"); > } > shouldn't that be removed too? No. The term 'schema' is a bit misleading: here the schema property controls what .ddl file to use to create the tables. For Oracle, the file src/main/resources/org/apache/jackrabbit/core/persistence/bundle/oracle.ddl file is used. It doesn't have to do with the database schema. See also http://issues.apache.org/jira/browse/JCR-1180
        Hide
        Naresh Gangapur added a comment -

        Hi, I am new to using 'jackrabbit' but hit the same issue while trying to configure OraclePersistenceManager.
        Can you please advise an alternative on this or shall we wait for the next release, if any planned as we don't have db user id and password in production and datasource is the only way to configure PMs .

        Thanks

        Show
        Naresh Gangapur added a comment - Hi, I am new to using 'jackrabbit' but hit the same issue while trying to configure OraclePersistenceManager. Can you please advise an alternative on this or shall we wait for the next release, if any planned as we don't have db user id and password in production and datasource is the only way to configure PMs . Thanks
        Hide
        Grégory Joseph added a comment -

        > For Oracle, a user name and password is required in any case.
        But it's provided by the datasource, so it shouldn't be mandatory (or have a default value) at the PM's configuration level, right ?

        Show
        Grégory Joseph added a comment - > For Oracle, a user name and password is required in any case. But it's provided by the datasource, so it shouldn't be mandatory (or have a default value) at the PM's configuration level, right ?
        Hide
        Thomas Mueller added a comment -

        > Can you please advise an alternative
        You could patch the classes yourself as long as there is no new version available. Otherwise I don't have an alternative I am afraid.

        > > For Oracle, a user name and password is required in any case.
        > But it's provided by the datasource,
        > so it shouldn't be mandatory (or have a default value) at the PM's configuration level, right ?

        Yes. The Oracle JDBC driver requires user name and password. If that's configured in the data source then that's OK.

        Show
        Thomas Mueller added a comment - > Can you please advise an alternative You could patch the classes yourself as long as there is no new version available. Otherwise I don't have an alternative I am afraid. > > For Oracle, a user name and password is required in any case. > But it's provided by the datasource, > so it shouldn't be mandatory (or have a default value) at the PM's configuration level, right ? Yes. The Oracle JDBC driver requires user name and password. If that's configured in the data source then that's OK.
        Hide
        Thomas Mueller added a comment -

        Fixed in revision 654514

        Show
        Thomas Mueller added a comment - Fixed in revision 654514
        Hide
        Grégory Joseph added a comment - - edited

        Thomas: could you let us know if this will be included in 1.4.3, 1.4.4, ... or even possibly the 1.3 branch ? Thanks.

        Show
        Grégory Joseph added a comment - - edited Thomas: could you let us know if this will be included in 1.4.3, 1.4.4, ... or even possibly the 1.3 branch ? Thanks.
        Hide
        Jukka Zitting added a comment -

        If there's enough demand for a 1.3.x or 1.4.x patch release with this and/or other fixes, then we can certainly do that. Please follow up on dev@ about what you'd like to see released.

        Show
        Jukka Zitting added a comment - If there's enough demand for a 1.3.x or 1.4.x patch release with this and/or other fixes, then we can certainly do that. Please follow up on dev@ about what you'd like to see released.
        Hide
        Jukka Zitting added a comment -

        Merged to the 1.4 branch in revision 654514.

        Show
        Jukka Zitting added a comment - Merged to the 1.4 branch in revision 654514.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sven Rieckhoff
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development