OpenJPA
  1. OpenJPA
  2. OPENJPA-266

Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.0.0
    • Component/s: jdbc
    • Labels:
      None

      Description

      In order to extend existing OpenJPA classes, for example OperationOrderUpdateManager, private field or method needed to change to protected or public.
      This kind of modification is not adding any functionality but making OpenJPA classes subclassable.

      1. OPENJPA-266.patch.txt
        5 kB
        Michael Dick
      2. OpenJPA-266.patch
        4 kB
        Catalina Wei
      3. DBDictionaryFactory.patch
        6 kB
        Catalina Wei

        Activity

        Hide
        Catalina Wei added a comment -

        The changes in the attached patch enable extensibility only.

        Catalina

        Show
        Catalina Wei added a comment - The changes in the attached patch enable extensibility only. Catalina
        Hide
        Catalina Wei added a comment -

        This patch has passed TCK with Derby

        Catalina

        Show
        Catalina Wei added a comment - This patch has passed TCK with Derby Catalina
        Hide
        Kevin Sutter added a comment -

        Although Catalina's patch passed the TCK, there were a couple of "extra contributions" that probably shouldn't have been part of the patch. Catalina will re-work the patch and re-post shortly. Thanks for your patience!

        Show
        Kevin Sutter added a comment - Although Catalina's patch passed the TCK, there were a couple of "extra contributions" that probably shouldn't have been part of the patch. Catalina will re-work the patch and re-post shortly. Thanks for your patience!
        Hide
        Catalina Wei added a comment -

        changes are mostly in "private" to "protected".

        Show
        Catalina Wei added a comment - changes are mostly in "private" to "protected".
        Hide
        Michael Dick added a comment -

        Attaching updated patch. I committed the changes to PreparedStatementImpl earlier this week. This patch contains the rest of the changes Catalina proposed.

        Show
        Michael Dick added a comment - Attaching updated patch. I committed the changes to PreparedStatementImpl earlier this week. This patch contains the rest of the changes Catalina proposed.
        Hide
        Catalina Wei added a comment -

        Allow vendor "extended" DB Dictionaray plugins.
        For example,
        public Class MyDB2Dictionary
        extends org.apache.openjpa.jdbc.sql.DB2Dictionary

        { ...}

        By changing default plugin values by :
        JDBCConfigurationImpl.dbdictionaryPlugin.setAlias("db2", "test.MyDB2Dictionary")

        will instantiate test.MyDB2Dictionary

        Show
        Catalina Wei added a comment - Allow vendor "extended" DB Dictionaray plugins. For example, public Class MyDB2Dictionary extends org.apache.openjpa.jdbc.sql.DB2Dictionary { ...} By changing default plugin values by : JDBCConfigurationImpl.dbdictionaryPlugin.setAlias("db2", "test.MyDB2Dictionary") will instantiate test.MyDB2Dictionary
        Hide
        Michael Dick added a comment -

        The last change regarding DBDictionaries looks like it's a good start, but I have a few questions / issues.

        The changes seem to be intended to enable other vendors to repackage OpenJPA with their own set of DBDictionaries. This is a good thing, but the code only allows DB2, Oracle and SQLServer to be extended. This should be expanded and generalized to allow any DBDictionary to be overridden.

        The fix also requires the user to get a configuration object and cast it to our implementation class. This should be changed to use the JDBCConfiguration interface.

        If this is intended for use by other vendors, why don't we just provide the ability for the DBDictionaryFactory class to be extended? If the DBDictionaryFactory class was configurable (like SQLFactory for example), then vendors could prefer their own set of classes without messing around with JDBCConfigurationImpl.

        Show
        Michael Dick added a comment - The last change regarding DBDictionaries looks like it's a good start, but I have a few questions / issues. The changes seem to be intended to enable other vendors to repackage OpenJPA with their own set of DBDictionaries. This is a good thing, but the code only allows DB2, Oracle and SQLServer to be extended. This should be expanded and generalized to allow any DBDictionary to be overridden. The fix also requires the user to get a configuration object and cast it to our implementation class. This should be changed to use the JDBCConfiguration interface. If this is intended for use by other vendors, why don't we just provide the ability for the DBDictionaryFactory class to be extended? If the DBDictionaryFactory class was configurable (like SQLFactory for example), then vendors could prefer their own set of classes without messing around with JDBCConfigurationImpl.
        Hide
        Patrick Linskey added a comment -

        Agreed. Additionally, it is already trivial for vendors to repackage OpenJPA with different dbdictionaries. All you need to do is create a ProductDerivation that changes the aliases listed in the JDBCConfigurationImpl.dbdictionaryPlugin.

        See JDBCPersistenceProductDerivation for an example of a product derivation that changes alias settings.

        Show
        Patrick Linskey added a comment - Agreed. Additionally, it is already trivial for vendors to repackage OpenJPA with different dbdictionaries. All you need to do is create a ProductDerivation that changes the aliases listed in the JDBCConfigurationImpl.dbdictionaryPlugin. See JDBCPersistenceProductDerivation for an example of a product derivation that changes alias settings.
        Hide
        Catalina Wei added a comment -

        use dbdictionaryPlugin value to load vendor specific DBDictionary.

        Show
        Catalina Wei added a comment - use dbdictionaryPlugin value to load vendor specific DBDictionary.

          People

          • Assignee:
            Unassigned
            Reporter:
            Catalina Wei
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development