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

• Key: OPENJPA-266
• Type: Improvement
• Status: Resolved
• Resolution: Fixed
• Priority: Trivial
• Assignee: Unassigned
• Reporter: Catalina Wei
• Component/s: jdbc
• Affects Version/s: 1.0.0
• Fix Version/s: 1.0.0

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.

Comments

[Catalina Wei]

The changes in the attached patch enable extensibility only.

Catalina

[Catalina Wei]

This patch has passed TCK with Derby

Catalina

[Kevin Sutter]

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!

[Catalina Wei]

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

[Michael Dick]

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

[Catalina Wei]

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

[Michael Dick]

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.

[Patrick Linskey]

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.

[Catalina Wei]

use dbdictionaryPlugin value to load vendor specific DBDictionary.