openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Date Wed, 19 Sep 2007 18:04:07 GMT
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 <ppoddar@bea.com> 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:plinskey@gmail.com]
> >Sent: Wednesday, September 19, 2007 2:14 AM
> >To: dev@openjpa.apache.org
> >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 <ppoddar@bea.com> 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:ppoddar@bea.com]
> >> >Sent: Tuesday, September 18, 2007 9:09 PM
> >> >To: dev@openjpa.apache.org
> >> >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:jira@apache.org]
> >> >>Sent: Tuesday, September 18, 2007 9:03 PM
> >> >>To: dev@openjpa.apache.org
> >> >>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

Mime
View raw message