Blocking the POS or not, doing weird stuff should be avoided.
Have you (Jacques) or anyone else that is close to the project actually seen this happen and looked into the problem? (I think you answered this as "no" in your email)
If not then there is a documented problem waiting for research and a solution. Until that is done funny fixes with big potential side effects should be kept for private repositories, and not go into the trunk.
Does that sound reasonable?As I mentioned in my other notes this should only happen once in an upgrade, and would be fixed by clearing the persisted cache once, and the problem would not come back until the object is updated (which hopefully shouldn't happen as hopefully Adam Heath has this out of his system for a while ;) ).
-David On Nov 12, 2007, at 10:57 AM, Jacques Le Roux wrote:
Okay,Then we are back to my proposition in https://issues.apache.org/jira/browse/OFBIZ-1385 #action_12541533 (only in main task of POSbuild.xml)Or the one Dan suggested (in the clean task of the main build.xml). >hich I found a bit tedious that's why I suggested the one aboveBoth of this option have ready patches in https://issues.apache.org/jira/browse/OFBIZ-1385But I agree that anyway they are just hacks and we should better find the problem origin which for the moment only affects POS. It should not be so hard and I will have a deeper look but I don't know when...I don't think a vote is needed for such a thing but we have to do something to not block the POS.Thanks Jacques De : "David E Jones" <[EMAIL PROTECTED]>I don't think this is acceptable for the project as it goes pretty farin deleting the persisted cache files on each build. Also, the error messages mentioned there are due to a change in the CacheLine class and would ONLY happen when upgrading a system. In general system upgrades may require clearing of any persisted cache, the UtilCache ones and others like the Tomcat persisted sessions (if any class in the session has changed data). After an upgrade this should only need to be done once. Unless someone convinces me otherwise I'll change this a little soon to only clear the cache in a more appropriate target, like a special clean target that is part of clean-all. -David On Nov 12, 2007, at 1:41 AM, [EMAIL PROTECTED] wrote:Author: jleroux Date: Mon Nov 12 00:41:21 2007 New Revision: 594050 URL: http://svn.apache.org/viewvc?rev=594050&view=rev Log: Clean the utilcache file else POS shows errors, more a hack than a definitive solution Modified: ofbiz/trunk/build.xml Modified: ofbiz/trunk/build.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.xml?rev=594050&r1=594049&r2=594050&view=diff = = = = = = = == = ====================================================================--- ofbiz/trunk/build.xml (original) +++ ofbiz/trunk/build.xml Mon Nov 12 00:41:21 2007 @@ -110,6 +110,18 @@ <target name="build"> <echo message="[build] ========== Start Building (Compile) =========="/> + <!--================================================================== -->+ <!-- Clean the utilcache file else POS shows errors like --> + <!-- org.ofbiz.base.util.cache.CacheLine; local class incompatible: --> + <!-- stream classdesc serialVersionUID = -1660410335854090898, --> + <!-- local class serialVersionUID = -7035478304991053884 --> + <!-- More a hack than a definitive solution --> + <!--================================================================== -->+ + <property file="framework/base/config/cache.properties"/> + <echo message="NOTICE: deleting ${cache.file.store}.db"/> + <delete file="${cache.file.store}.db" verbose="true"/> + <subant inheritall="false"> <filelist dir="." files="framework/build.xml"/> </subant>
smime.p7s
Description: S/MIME cryptographic signature
