Re: svn commit: r594050 - /ofbiz/trunk/build.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r594050 - /ofbiz/trunk/build.xml

David E Jones-2

I don't think this is acceptable for the project as it goes pretty far  
in 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, [hidden email] 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>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r594050 - /ofbiz/trunk/build.xml

Jacques Le Roux
Administrator
Okay,

Then we are back to my proposition in https://issues.apache.org/jira/browse/OFBIZ-1385#action_12541533 (only in main task of POS
build.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 above

Both of this option have ready patches in https://issues.apache.org/jira/browse/OFBIZ-1385

But 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" <[hidden email]>

>
> I don't think this is acceptable for the project as it goes pretty far
> in 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, [hidden email] 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>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r594050 - /ofbiz/trunk/build.xml

David E Jones

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 POS
> build.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 above
>
> Both of this option have ready patches in https://issues.apache.org/jira/browse/OFBIZ-1385
>
> But 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" <[hidden email]>
>>
>> I don't think this is acceptable for the project as it goes pretty  
>> far
>> in 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, [hidden email] 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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r594050 - /ofbiz/trunk/build.xml

Jacques Le Roux
Administrator
>
> Blocking the POS or not, doing weird stuff should be avoided.

I reverted

> 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)

I created https://issues.apache.org/jira/browse/OFBIZ-1385 but I must admit I did not look really further

> 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 ;) ).

Then a specific clean-utilcache in POS build.xml could do the trick. But I would prefer on the main POS ant task to avoid
perplexity. Actually this is what I suggested in my patch, then I got excited and put it in the main build.xml :o)

Jacques

> -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 POS
> > build.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 above
> >
> > Both of this option have ready patches in https://issues.apache.org/jira/browse/OFBIZ-1385
> >
> > But 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" <[hidden email]>
> >>
> >> I don't think this is acceptable for the project as it goes pretty
> >> far
> >> in 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, [hidden email] 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>
> >>>
> >>>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r594050 - /ofbiz/trunk/build.xml

Jacques Le Roux
Administrator
In reply to this post by David E Jones-2
De : "David E Jones" <[hidden email]>

> I don't think this is acceptable for the project as it goes pretty far  
> in 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.

This is what Dan Dan Shields  proposed, his patch does that https://issues.apache.org/jira/browse/OFBIZ-1385#action_12541429

My idea was ot avoid perplexity for someone not aware of the problem. Anyway it's not a big deal...

Jacques

>
> -David
>
>
> On Nov 12, 2007, at 1:41 AM, [hidden email] 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>
> >
> >
>