IIRC, we went to properties just for legacy reasons. I would not be surprised if the new restrictions about null values are causing these problems. Regardless, it sounds like this bears investigation, rather than re-writing either the test case.
I would start by investigating what happens if you maintain a boolean to record whether or not a value has been set, rather than overriding the meaning of null. -Patrick On 9/19/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > The test that broke (TestConfigurationImpl) defined a Configuration > implementation Ctest. > None of the Values of CTest is dynamic. CTest is not frozen. > The test > i. sets Values of C > ii. serializes-deserializes C to C' > iii. Compares C and C' (passes) > iv. updates values of C' > v. serializes-deserializes C' to C'' > vi. Compares C' and C'' (fails) > > I have not debugged it further to see why it breaks. > My initial guess is our assumption of 'original value' being null is > violated for C' which is deserialized version of C. > Keeping the distinction for dynamic Values using 'original' while > non-dynamic Values using 'current' strings makes the test pass (in a > easy-way-out sort of way) because none of the Values is dynamic. > > I will debug it (may not be today though) to find out further. > > In fact, I think a crtical unanswered question about all this changes I > have made is: > Why Configuration was transposed to Properties for equality/hashCode > computation? > > > Given that we are acting (tweaking?) with incomplete knowledge on a > stable Value framework, I suggest we keep the distiction based on > dynamic nature of Values as that way we will not at least hamper > non-dynamic Values. > > > Pinaki Poddar > 972.834.2865 > > > >-----Original Message----- > >From: Patrick Linskey [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, September 19, 2007 2:14 AM > >To: [email protected] > >Subject: Re: [jira] Commented: (OPENJPA-305) Dynamic > >configuration of EntityManagerFactory > > > >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 > > > > 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
