Can you elaborate on this? Not knowing anything else about the situation, my instinct is that a) is a better solution, since it seems like a better architecture for the future.
-Patrick On 9/18/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > >>I don't understand why we do the isDynamic() check in equals() and > >>hashCode(), though; shouldn't getOriginalValue() always be correct? > > > >Correct. Thanks. > > But one test openjpa.lib.conf.test.TestConfigurationImpl breaks because > it uses a different Configuration impl. > Either we a) modify the test or we b) retain the distinction between > original and current value. > I went for (b). > > > > > Pinaki Poddar > 972.834.2865 > > > >-----Original Message----- > >From: Pinaki Poddar [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, September 18, 2007 9:09 PM > >To: [email protected] > >Subject: RE: [jira] Commented: (OPENJPA-305) Dynamic > >configuration of EntityManagerFactory > > > > > >>I don't understand why we do the isDynamic() check in equals() and > >>hashCode(), though; shouldn't getOriginalValue() always be correct? > > > >Correct. Thanks. > > > >Pinaki Poddar > >972.834.2865 > > > > > >>-----Original Message----- > >>From: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, September 18, 2007 9:03 PM > >>To: [email protected] > >>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration of > >>EntityManagerFactory > >> > >> > >> [ > >>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla > >>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action > >>_12528633 ] > >> > >>Patrick Linskey commented on OPENJPA-305: > >>----------------------------------------- > >> > >>Generally, it looks good. Some comments: > >> > >>I don't understand why we do the isDynamic() check in equals() and > >>hashCode(), though; shouldn't getOriginalValue() always be correct? > >> > >>Also, it looks like there's a synchronization issue at hand > >-- based on > >>my reading, dynamic sets must occur in a synchronized manner, or the > >>behavior is non-deterministic. That is OK (I don't think that we > >>necessarily want to add synchronization on accesses), but should be > >>well-documented. > >> > >>> Dynamic configuration of EntityManagerFactory > >>> --------------------------------------------- > >>> > >>> Key: OPENJPA-305 > >>> URL: > >>https://issues.apache.org/jira/browse/OPENJPA-305 > >>> Project: OpenJPA > >>> Issue Type: New Feature > >>> Reporter: Pinaki Poddar > >>> Attachments: openjpa-305.patch.1.txt > >>> > >>> > >>> OpenJPA configures EntityManagerFactory at creation time via > >>an instance of Configuartion object. Once EntityManagerFactory is > >>created and a EntityManager is issued from it -- the Configuration is > >>frozen by design. That is no further changes to Configuration is > >>allowed as long as EntityManagerFactory lives. > >>> For certain configuration properties, it is desirable to > >>change them during the lifetime of a EntityManagerFactory. > >>> This issue is raised to initiate a discussion on such a > >>feature, the possibility and limitations of dynamic update and track > >>the impact of such a change as frozen Configuration is an important > >>assumption. > >>> > >> > >>-- > >>This message is automatically generated by JIRA. > >>- > >>You can reply to this email to add a comment to the issue online. > >> > >> > > > >Notice: This email message, together with any attachments, > >may contain information of BEA Systems, Inc., its > >subsidiaries and affiliated entities, that may be > >confidential, proprietary, copyrighted and/or legally > >privileged, and is intended solely for the use of the > >individual or entity named in this message. If you are not the > >intended recipient, and have received this message in error, > >please immediately return this by email and then delete it. > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and have > received this message in error, please immediately return this by email and > then delete it. > -- Patrick Linskey 202 669 5907
