You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2013/05/19 15:25:00 UTC
Backporting Recent Entity Engine Fixes
In revision 1484279 I believe I have fixed the last of the entity cache
issues. FYI - there were flaws in the entity cache code that GUARANTEED
stale values. In other words, data coming from the caches was unreliable.
In addition, I fixed a flaw in the GenericEntity/GenericValue classes
that allowed other threads to modify a shared instance that was supposed
to be immutable. This is a serious problem because it is common practice
to cast a Generic Entity to a java.util.Map, then pass it on to various
methods - with the result that in some remote corner of the project a
method thinks it is modifying a Map, but in reality it is modifying a
supposedly immutable GenericEntity.
These bugs are serious, and they really need to be fixed in the older
versions. The problem is, I have spent almost all of my free time fixing
these in the trunk, and I don't have any more free time to spare. In
other words, I need your help.
The bug fixes are mixed in with other changes I was doing at the time,
so I can't provide a simple list of revisions to backport. One approach
would be to copy the trunk EntityTestSuite.java to a release branch, and
start fixing the tests that fail - using the related trunk commits as a
guide.
So, if anyone is willing to help, I can provide some guidance - but I
can't do it all myself.
-Adrian
Re: Backporting Recent Entity Engine Fixes
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for the thorough explanation. I can help, also it will be good if we do it before creating the R13 branch. I don't mind having R13.06 or ven R13.07.
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
> In revision 1484279 I believe I have fixed the last of the entity cache
> issues. FYI - there were flaws in the entity cache code that GUARANTEED
> stale values. In other words, data coming from the caches was unreliable.
>
> In addition, I fixed a flaw in the GenericEntity/GenericValue classes
> that allowed other threads to modify a shared instance that was supposed
> to be immutable. This is a serious problem because it is common practice
> to cast a Generic Entity to a java.util.Map, then pass it on to various
> methods - with the result that in some remote corner of the project a
> method thinks it is modifying a Map, but in reality it is modifying a
> supposedly immutable GenericEntity.
>
> These bugs are serious, and they really need to be fixed in the older
> versions. The problem is, I have spent almost all of my free time fixing
> these in the trunk, and I don't have any more free time to spare. In
> other words, I need your help.
>
> The bug fixes are mixed in with other changes I was doing at the time,
> so I can't provide a simple list of revisions to backport. One approach
> would be to copy the trunk EntityTestSuite.java to a release branch, and
> start fixing the tests that fail - using the related trunk commits as a
> guide.
>
> So, if anyone is willing to help, I can provide some guidance - but I
> can't do it all myself.
>
> -Adrian
>
Re: Backporting Recent Entity Engine Fixes
Posted by Adrian Crum <ad...@sandglass-software.com>.
Thanks Jacques!
-Adrian
On 5/27/2013 9:08 AM, Jacques Le Roux wrote:
> I backported also to other living branches (11 and 10) merging from 12
>
> Jacques
>
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> I found some time between projects to backport the entity engine fixes
>> to the release 12 branch.
>>
>> Due to the seriousness of these issues, I recommend we create a new
>> binary release.
>>
>> -Adrian
>>
>> On 5/19/2013 2:25 PM, Adrian Crum wrote:
>>> In revision 1484279 I believe I have fixed the last of the entity
>>> cache issues. FYI - there were flaws in the entity cache code that
>>> GUARANTEED stale values. In other words, data coming from the caches
>>> was unreliable.
>>>
>>> In addition, I fixed a flaw in the GenericEntity/GenericValue classes
>>> that allowed other threads to modify a shared instance that was
>>> supposed to be immutable. This is a serious problem because it is
>>> common practice to cast a Generic Entity to a java.util.Map, then pass
>>> it on to various methods - with the result that in some remote corner
>>> of the project a method thinks it is modifying a Map, but in reality
>>> it is modifying a supposedly immutable GenericEntity.
>>>
>>> These bugs are serious, and they really need to be fixed in the older
>>> versions. The problem is, I have spent almost all of my free time
>>> fixing these in the trunk, and I don't have any more free time to
>>> spare. In other words, I need your help.
>>>
>>> The bug fixes are mixed in with other changes I was doing at the time,
>>> so I can't provide a simple list of revisions to backport. One
>>> approach would be to copy the trunk EntityTestSuite.java to a release
>>> branch, and start fixing the tests that fail - using the related trunk
>>> commits as a guide.
>>>
>>> So, if anyone is willing to help, I can provide some guidance - but I
>>> can't do it all myself.
>>>
>>> -Adrian
>>>
Re: Backporting Recent Entity Engine Fixes
Posted by Jacques Le Roux <ja...@les7arts.com>.
I backported also to other living branches (11 and 10) merging from 12
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
>I found some time between projects to backport the entity engine fixes
> to the release 12 branch.
>
> Due to the seriousness of these issues, I recommend we create a new
> binary release.
>
> -Adrian
>
> On 5/19/2013 2:25 PM, Adrian Crum wrote:
>> In revision 1484279 I believe I have fixed the last of the entity
>> cache issues. FYI - there were flaws in the entity cache code that
>> GUARANTEED stale values. In other words, data coming from the caches
>> was unreliable.
>>
>> In addition, I fixed a flaw in the GenericEntity/GenericValue classes
>> that allowed other threads to modify a shared instance that was
>> supposed to be immutable. This is a serious problem because it is
>> common practice to cast a Generic Entity to a java.util.Map, then pass
>> it on to various methods - with the result that in some remote corner
>> of the project a method thinks it is modifying a Map, but in reality
>> it is modifying a supposedly immutable GenericEntity.
>>
>> These bugs are serious, and they really need to be fixed in the older
>> versions. The problem is, I have spent almost all of my free time
>> fixing these in the trunk, and I don't have any more free time to
>> spare. In other words, I need your help.
>>
>> The bug fixes are mixed in with other changes I was doing at the time,
>> so I can't provide a simple list of revisions to backport. One
>> approach would be to copy the trunk EntityTestSuite.java to a release
>> branch, and start fixing the tests that fail - using the related trunk
>> commits as a guide.
>>
>> So, if anyone is willing to help, I can provide some guidance - but I
>> can't do it all myself.
>>
>> -Adrian
>>
>
Re: Backporting Recent Entity Engine Fixes
Posted by Adrian Crum <ad...@sandglass-software.com>.
I found some time between projects to backport the entity engine fixes
to the release 12 branch.
Due to the seriousness of these issues, I recommend we create a new
binary release.
-Adrian
On 5/19/2013 2:25 PM, Adrian Crum wrote:
> In revision 1484279 I believe I have fixed the last of the entity
> cache issues. FYI - there were flaws in the entity cache code that
> GUARANTEED stale values. In other words, data coming from the caches
> was unreliable.
>
> In addition, I fixed a flaw in the GenericEntity/GenericValue classes
> that allowed other threads to modify a shared instance that was
> supposed to be immutable. This is a serious problem because it is
> common practice to cast a Generic Entity to a java.util.Map, then pass
> it on to various methods - with the result that in some remote corner
> of the project a method thinks it is modifying a Map, but in reality
> it is modifying a supposedly immutable GenericEntity.
>
> These bugs are serious, and they really need to be fixed in the older
> versions. The problem is, I have spent almost all of my free time
> fixing these in the trunk, and I don't have any more free time to
> spare. In other words, I need your help.
>
> The bug fixes are mixed in with other changes I was doing at the time,
> so I can't provide a simple list of revisions to backport. One
> approach would be to copy the trunk EntityTestSuite.java to a release
> branch, and start fixing the tests that fail - using the related trunk
> commits as a guide.
>
> So, if anyone is willing to help, I can provide some guidance - but I
> can't do it all myself.
>
> -Adrian
>
Re: Backporting Recent Entity Engine Fixes
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 19, 2013, at 3:25 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
> In addition, I fixed a flaw in the GenericEntity/GenericValue classes that allowed other threads to modify a shared instance that was supposed to be immutable. This is a serious problem because it is common practice to cast a Generic Entity to a java.util.Map, then pass it on to various methods - with the result that in some remote corner of the project a method thinks it is modifying a Map, but in reality it is modifying a supposedly immutable GenericEntity.
Adrian, all,
how would you recommend to check and spot for existing code that may modify the content of objects now immutable? Here I am considering both ootb code and custom code that is running on one of the release branches where these fixes have been backported.
The purpose of this message is to find out the best ways to spot the issues that a custom instance may have after an update to the next release: should we recommend to search for some patterns while doing static code analysis? Considering that the client code may be written in Java, Groovy, Minilang etc... it may be difficult to define some good patterns. Any ideas?
Of course testing the screens/code is also a good way to spot these issues, but sometimes this is not a viable option.
Should we document this in Confluence (also with suggested ways of fix the code)?
Thanks,
Jacopo