You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Catalina Wei (JIRA)" <ji...@apache.org> on 2007/06/26 02:06:25 UTC
[jira] Created: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
----------------------------------------------------------------------------------------------------------------
Key: OPENJPA-266
URL: https://issues.apache.org/jira/browse/OPENJPA-266
Project: OpenJPA
Issue Type: Improvement
Components: jdbc
Affects Versions: 1.0.0
Reporter: Catalina Wei
Priority: Trivial
Fix For: 1.0.0
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback
Posted by "Roytman, Alex" <Ro...@peacetech.com>.
Hello Patrick,
Thank you for your reply.
Could you guys at least help me to convince BEA support that this
behavior is not in compliance with specs? As it is they keep saying it
works per specs and refuse to do anything.
Aren't you and Neelan still Kodo program/tech managers?
An email from you should be sufficient.
Unfortunately the specs are not crystal clear in this respect. It does
say about making exception fatal on when an exception happens on flush()
but they say nothing specific about recognized types of exceptions which
should behave per specs. That is why we need an expert opinion here.
Whatever specs say or do not say, I believe it is a very serious
deficiency killing huge class of absolutely necessary functionality.
We need to release a new version of our old application in couple of
months. It was developed before this exception re-wrap has been
introduced and have extremely heavy consistency validation logic
happening in jdoPerStore() now it is all broken because of the rollback.
This should be a trivial fix. Just introduce another config param
whether to wrap or not and inspect an exception class before wrapping
it.
The trouble is that all the expertise and core developers seem to be in
this OpenJPA group while official BEA support appears to be just
figureheads. As a maintenance paying customer I am very upset with it.
On the other note, do you think JPA will reach level of JDO 2.0 services
in the near future?
Thanks again
Alex
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: Tuesday, July 24, 2007 2:58 PM
To: dev@openjpa.apache.org
Subject: Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with
FatalDataStoreException forcing transaction rollback
Hi,
Sadly, nothing that happens in this community has any impact on Kodo
3. OpenJPA is only used in Kodo 4.1 and newer.
I believe that this behavior is different in Kodo 4.1 at least -- the
fatal-ness of an exception is separate from its type now. It looks
like in OpenJPA, we setRollbackOnly when any exception (including
OpenJPA exceptions) happens during flush or attach operations.
However, it looks like we do *not* do any rollback configuration if
you call preFlush() directly. You might want to try calling
KodoPersistenceManager.preFlush() to see if you can recover from that
method invocation.
(Everything above is based solely on code inspection, so take it with
a grain of salt.)
-Patrick
On 7/24/07, Roytman, Alex <Ro...@peacetech.com> wrote:
> Hello everyone,
>
> I noticed that at some point in Kodo 3.x its behavior changed. Now it
catches any exception including JDOUserException thrown in jdoPreStore()
and wraps it in FatalDataStoreException which forces transaction
rollback and preventing further retry.
>
> JDOUserException is a retriable exception according to specs while
FatalDataStoreException is not. This change of JDO exception type makes
it completely impossible to retry JDOUserException thrown in
jdoPreStore() since the transaction is automatically rolled back.
>
> It causes severe functionality loss as most of the model consistency
can be only enforced on store (when all the changes have been done) and
now any validation JDOUserException thrown in jdoPerStore() causes
immediate rollback with no chance to fix the issue and recommit
>
> I struggled for a month with BEA official support but they do not even
want (able to?) to look into it seriously and try to convince me that it
functions as expected. I tried to reason that JDOUserException is
defined as retriable but to no avail
>
> Thank you
>
> Alex
>
--
Patrick Linskey
202 669 5907
Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback
Posted by Patrick Linskey <pl...@gmail.com>.
Hi,
Sadly, nothing that happens in this community has any impact on Kodo
3. OpenJPA is only used in Kodo 4.1 and newer.
I believe that this behavior is different in Kodo 4.1 at least -- the
fatal-ness of an exception is separate from its type now. It looks
like in OpenJPA, we setRollbackOnly when any exception (including
OpenJPA exceptions) happens during flush or attach operations.
However, it looks like we do *not* do any rollback configuration if
you call preFlush() directly. You might want to try calling
KodoPersistenceManager.preFlush() to see if you can recover from that
method invocation.
(Everything above is based solely on code inspection, so take it with
a grain of salt.)
-Patrick
On 7/24/07, Roytman, Alex <Ro...@peacetech.com> wrote:
> Hello everyone,
>
> I noticed that at some point in Kodo 3.x its behavior changed. Now it catches any exception including JDOUserException thrown in jdoPreStore() and wraps it in FatalDataStoreException which forces transaction rollback and preventing further retry.
>
> JDOUserException is a retriable exception according to specs while FatalDataStoreException is not. This change of JDO exception type makes it completely impossible to retry JDOUserException thrown in jdoPreStore() since the transaction is automatically rolled back.
>
> It causes severe functionality loss as most of the model consistency can be only enforced on store (when all the changes have been done) and now any validation JDOUserException thrown in jdoPerStore() causes immediate rollback with no chance to fix the issue and recommit
>
> I struggled for a month with BEA official support but they do not even want (able to?) to look into it seriously and try to convince me that it functions as expected. I tried to reason that JDOUserException is defined as retriable but to no avail
>
> Thank you
>
> Alex
>
--
Patrick Linskey
202 669 5907
Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback
Posted by "Roytman, Alex" <Ro...@peacetech.com>.
Hello everyone,
I noticed that at some point in Kodo 3.x its behavior changed. Now it catches any exception including JDOUserException thrown in jdoPreStore() and wraps it in FatalDataStoreException which forces transaction rollback and preventing further retry.
JDOUserException is a retriable exception according to specs while FatalDataStoreException is not. This change of JDO exception type makes it completely impossible to retry JDOUserException thrown in jdoPreStore() since the transaction is automatically rolled back.
It causes severe functionality loss as most of the model consistency can be only enforced on store (when all the changes have been done) and now any validation JDOUserException thrown in jdoPerStore() causes immediate rollback with no chance to fix the issue and recommit
I struggled for a month with BEA official support but they do not even want (able to?) to look into it seriously and try to convince me that it functions as expected. I tried to reason that JDOUserException is defined as retriable but to no avail
Thank you
Alex
[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508314 ]
Catalina Wei commented on OPENJPA-266:
--------------------------------------
This patch has passed TCK with Derby
Catalina
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: openjpa-jdbc.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-266:
---------------------------------
Attachment: openjpa-jdbc.patch
The changes in the attached patch enable extensibility only.
Catalina
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: openjpa-jdbc.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515020 ]
Patrick Linskey commented on OPENJPA-266:
-----------------------------------------
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.
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514987 ]
Michael Dick commented on OPENJPA-266:
--------------------------------------
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.
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-266:
---------------------------------
Attachment: openjpa-jdbc.patch
changes are mostly in "private" to "protected".
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: openjpa-jdbc.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-266:
---------------------------------
Attachment: OpenJPA-266.patch
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
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508328 ]
Kevin Sutter commented on OPENJPA-266:
--------------------------------------
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!
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter updated OPENJPA-266:
---------------------------------
Attachment: (was: openjpa-jdbc.patch)
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-266:
---------------------------------
Attachment: OPENJPA-266.patch.txt
Attaching updated patch. I committed the changes to PreparedStatementImpl earlier this week. This patch contains the rest of the changes Catalina proposed.
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "David Wisneski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Wisneski resolved OPENJPA-266.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.0.0
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: DBDictionaryFactory.patch, OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-266:
------------------------------------
Fix Version/s: (was: 1.0.0)
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Attachments: DBDictionaryFactory.patch, OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-266:
---------------------------------
Attachment: DBDictionaryFactory.patch
use dbdictionaryPlugin value to load vendor specific DBDictionary.
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: DBDictionaryFactory.patch, OpenJPA-266.patch, OPENJPA-266.patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-266) Add Extensibility: Change "private"
field/method to "protected" or "public" in OpenJPA classes to be
extendable
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-266:
---------------------------------
Attachment: (was: openjpa-jdbc.patch)
> Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-266
> URL: https://issues.apache.org/jira/browse/OPENJPA-266
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.0.0
> Reporter: Catalina Wei
> Priority: Trivial
> Fix For: 1.0.0
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.