Re: svn commit: r587109 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java

[Adam Heath-2]

[hidden email] wrote:

> Author: jaz
> Date: Mon Oct 22 07:23:48 2007
> New Revision: 587109
>
> URL: http://svn.apache.org/viewvc?rev=587109&view=rev
> Log:
> small change to allow ofbiz to compile again
>
> Modified:
>     ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java
>
> Modified: ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java?rev=587109&r1=587108&r2=587109&view=diff
> ==============================================================================
> --- ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java (original)
> +++ ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java Mon Oct 22 07:23:48 2007
> @@ -146,20 +146,20 @@
>       * Create a map from passed nameX, valueX parameters
>       * @return The resulting Map
>       */
> -    public static <K, V> Map<K, V> toMap(Object... data) {
> +    public static <K, V> Map<String, V> toMap(Object... data) {
>          if (data == null) {
>              return null;
>          }
>          if (data.length == 1 && data[0] instanceof Map) {
>              // Fix for javac's broken type inferring
> -            return UtilGenerics.<K, V>checkMap(data[0]);
> +            return UtilGenerics.<String, V>checkMap(data[0]);
>          }
>          if (data.length % 2 == 1) {
>              throw new IllegalArgumentException("You must pass an even sized array to the toMap method");
>          }
> -        Map<K, V> map = FastMap.newInstance();
> +        Map<String, V> map = FastMap.newInstance();
>          for (int i = 0; i < data.length; ) {
> -            map.put((K) data[i++], (V) data[i++]);
> +            map.put((String) data[i++], (V) data[i++]);
>          }
>          return map;
>      }

This is *not* the right way to fix whatever problem you are having.
Absolutely *not* right.

What error did you get?  Everything compiles for me.

[Tim Ruppert]

This was working last week before the supreme amount of changes.  Anybody got any ideas why this would be the case now:

org.ofbiz.webapp.view.ViewHandlerException: Error in streamDataResource (Unable to read BLOB data from input stream while getting value : imageData [IMAGE_DATA] (1): java.io.InvalidClassException: org.ofbiz.entity.util.ByteWrapper; local class incompatible: stream classdesc serialVersionUID = -2019470610749810950, local class serialVersionUID = -7811889960144925895 (org.ofbiz.entity.util.ByteWrapper; local class incompatible: stream classdesc serialVersionUID = -2019470610749810950, local class serialVersionUID = -7811889960144925895))

This is on a fresh checkout, so there are no old classes, etc.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

[David E Jones]

Interesting... this is worrisome as it means something isn't using  
the ByteWrapper properly. Only the bytes in the ByteWrapper should be  
sent to the database, not a serialized version of the object itself.

Because this issue exists we have a problem though... updating the  
ByteWrapper object will make existing database data stored with it  
useless unless the ByteWrapper object NEVER changes.

Tim, do you have a full stack trace on that? I'd like to trace  
through the code in the content stuff as well as the database that  
does both the saves and loads.

As an interim fix, change the ByteWrapper.java file back to its  
original version (before the enhancements that Adam did recently). I  
don't know if we want to do this in the trunk, but I'll look at that  
as part of the above mentioned review.

-David


On Oct 22, 2007, at 3:35 PM, Tim Ruppert wrote:

> This was working last week before the supreme amount of changes.  
> Anybody got any ideas why this would be the case now:
>
> org.ofbiz.webapp.view.ViewHandlerException: Error in  
> streamDataResource (Unable to read BLOB data from input stream  
> while getting value : imageData [IMAGE_DATA] (1):  
> java.io.InvalidClassException: org.ofbiz.entity.util.ByteWrapper;  
> local class incompatible: stream classdesc serialVersionUID =  
> -2019470610749810950, local class serialVersionUID =  
> -7811889960144925895 (org.ofbiz.entity.util.ByteWrapper; local  
> class incompatible: stream classdesc serialVersionUID =  
> -2019470610749810950, local class serialVersionUID =  
> -7811889960144925895))
>
> This is on a fresh checkout, so there are no old classes, etc.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>

[Tim Ruppert]

I do have the zip file that I've sent along - and yes rolling back worked fine - but there is a much bigger issue 'round this one . . . :(

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 22, 2007, at 3:42 PM, David E Jones wrote:

Interesting... this is worrisome as it means something isn't using the ByteWrapper properly. Only the bytes in the ByteWrapper should be sent to the database, not a serialized version of the object itself.

Because this issue exists we have a problem though... updating the ByteWrapper object will make existing database data stored with it useless unless the ByteWrapper object NEVER changes.

Tim, do you have a full stack trace on that? I'd like to trace through the code in the content stuff as well as the database that does both the saves and loads.

As an interim fix, change the ByteWrapper.java file back to its original version (before the enhancements that Adam did recently). I don't know if we want to do this in the trunk, but I'll look at that as part of the above mentioned review.

-David

On Oct 22, 2007, at 3:35 PM, Tim Ruppert wrote:

This was working last week before the supreme amount of changes.  Anybody got any ideas why this would be the case now:

org.ofbiz.webapp.view.ViewHandlerException: Error in streamDataResource (Unable to read BLOB data from input stream while getting value : imageData [IMAGE_DATA] (1): java.io.InvalidClassException: org.ofbiz.entity.util.ByteWrapper; local class incompatible: stream classdesc serialVersionUID = -2019470610749810950, local class serialVersionUID = -7811889960144925895 (org.ofbiz.entity.util.ByteWrapper; local class incompatible: stream classdesc serialVersionUID = -2019470610749810950, local class serialVersionUID = -7811889960144925895))

This is on a fresh checkout, so there are no old classes, etc.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

[Scott Gray]

Also, is there a reason why Andrew almost never replies to this type of
email?  I think it's important that all committers respond to concerns
especially when they are coming from other committers.

Scott

On 23/10/2007, Adam Heath <[hidden email]> wrote:

>
> [hidden email] wrote:
> > Author: jaz
> > Date: Mon Oct 22 07:23:48 2007
> > New Revision: 587109
> >
> > URL: http://svn.apache.org/viewvc?rev=587109&view=rev
> > Log:
> > small change to allow ofbiz to compile again
> >
>
> This is *not* the right way to fix whatever problem you are having.
> Absolutely *not* right.
>
> What error did you get?  Everything compiles for me.
>
>

[David E Jones]

Would be interested in feedback on this, here is what I propose:

1. revert Adam's changes to the ByteWrapper object so that data  
stored with it can be migrated to be plain bytes instead of a  
serialized ByteWrapper
2. deprecate the ByteWrapper object
3. change all code that uses the ByteWrapper object to just use a byte
[] (I think this should work fine in Java 1.5)
4. create a utility that unwraps all existing serialized ByteWrapper  
objects and just drops the byte[] into the db; this would have to be  
run for all existing blob data in any existing database

-David


On Oct 22, 2007, at 3:57 PM, Tim Ruppert wrote:

> I do have the zip file that I've sent along - and yes rolling back  
> worked fine - but there is a much bigger issue 'round this  
> one . . . :(
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Oct 22, 2007, at 3:42 PM, David E Jones wrote:
>
>>
>> Interesting... this is worrisome as it means something isn't using  
>> the ByteWrapper properly. Only the bytes in the ByteWrapper should  
>> be sent to the database, not a serialized version of the object  
>> itself.
>>
>> Because this issue exists we have a problem though... updating the  
>> ByteWrapper object will make existing database data stored with it  
>> useless unless the ByteWrapper object NEVER changes.
>>
>> Tim, do you have a full stack trace on that? I'd like to trace  
>> through the code in the content stuff as well as the database that  
>> does both the saves and loads.
>>
>> As an interim fix, change the ByteWrapper.java file back to its  
>> original version (before the enhancements that Adam did recently).  
>> I don't know if we want to do this in the trunk, but I'll look at  
>> that as part of the above mentioned review.
>>
>> -David
>>
>>
>> On Oct 22, 2007, at 3:35 PM, Tim Ruppert wrote:
>>
>>> This was working last week before the supreme amount of changes.  
>>> Anybody got any ideas why this would be the case now:
>>>
>>> org.ofbiz.webapp.view.ViewHandlerException: Error in  
>>> streamDataResource (Unable to read BLOB data from input stream  
>>> while getting value : imageData [IMAGE_DATA] (1):  
>>> java.io.InvalidClassException: org.ofbiz.entity.util.ByteWrapper;  
>>> local class incompatible: stream classdesc serialVersionUID =  
>>> -2019470610749810950, local class serialVersionUID =  
>>> -7811889960144925895 (org.ofbiz.entity.util.ByteWrapper; local  
>>> class incompatible: stream classdesc serialVersionUID =  
>>> -2019470610749810950, local class serialVersionUID =  
>>> -7811889960144925895))
>>>
>>> This is on a fresh checkout, so there are no old classes, etc.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>>
>>
>

[Adrian Crum]

Yeah, that's starting to bug me too.

Scott Gray wrote:

> Also, is there a reason why Andrew almost never replies to this type of
> email?  I think it's important that all committers respond to concerns
> especially when they are coming from other committers.
>
> Scott
>
> On 23/10/2007, Adam Heath <[hidden email]> wrote:
>
>>[hidden email] wrote:
>>
>>>Author: jaz
>>>Date: Mon Oct 22 07:23:48 2007
>>>New Revision: 587109
>>>
>>>URL: http://svn.apache.org/viewvc?rev=587109&view=rev
>>>Log:
>>>small change to allow ofbiz to compile again
>>>
>>
>>This is *not* the right way to fix whatever problem you are having.
>>Absolutely *not* right.
>>
>>What error did you get?  Everything compiles for me.
>>
>>
>
>

[Andrew Zeneski-2]

I cannot say exactly how much damage it causes, but since this is as  
far as the framework will compile, I figured it was time for a quick  
patch. If you have a better fix, please by all means check it in.  
Otherwise, let's just make sure we can compile the trunk without errors.

Andrew

-----

classes:
     [javac] Compiling 15 source files to /Users/jaz/Sandbox/
kickstartr/framework/entityext/build/classes
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map initialHistoryRes = dispatcher.runSync
("createEntitySyncHistory", UtilMisc.toMap("entitySyncId",  
entitySyncId, "runStatusId", "ESR_RUNNING", "beginningSynchTime",  
this.currentRunStartTime, "lastCandidateEndTime",  
this.currentRunEndTime, "userLogin", userLogin));
     [javac]                                               ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:745:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map updateEsRunResult = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",  
entitySyncId, "lastSuccessfulSynchTime", this.currentRunEndTime,  
"userLogin", userLogin));
     [javac]                                               ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:797:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map completeEntitySyncRes =  
dispatcher.runSync("updateEntitySyncRunning", UtilMisc.toMap
("entitySyncId", entitySyncId, "runStatusId", newStatusId,  
"userLogin", userLogin));
     [javac]                                                   ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:811:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]                 Map deleteEntitySyncHistRes =  
dispatcher.runSync("deleteEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "userLogin",  
userLogin));
     [javac]                                                         ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:822:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]                 Map completeEntitySyncHistRes =  
dispatcher.runSync("updateEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "runStatusId",  
"ESR_COMPLETE", "userLogin", userLogin));
     [javac]                                                           ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:945:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map errorEntitySyncRes = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",  
entitySyncId, "runStatusId", runStatusId, "userLogin", userLogin));
     [javac]                                                ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:954:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]                 Map errorEntitySyncHistoryRes =  
dispatcher.runSync("updateEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "runStatusId",  
runStatusId, "userLogin", userLogin));
     [javac]                                                           ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:979:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map startEntitySyncRes = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",  
entitySyncId, "runStatusId", "ESR_RUNNING", "userLogin", userLogin));
     [javac]                                                ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:1054:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]                 Map startEntitySyncRes =  
dispatcher.runSync("updateEntitySyncRunning", UtilMisc.toMap
("entitySyncId", entitySyncId, "runStatusId", "ESR_RUNNING",  
"userLogin", userLogin));
     [javac]                                                    ^
     [javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:1126:  
cannot find symbol
     [javac] symbol  : method runSync
(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
     [javac] location: interface org.ofbiz.service.LocalDispatcher
     [javac]             Map startEntitySyncRes = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",  
entitySyncId, "runStatusId", "ESR_RUNNING", "preOfflineSynchTime",  
this.lastSuccessfulSynchTime, "userLogin", userLogin));
     [javac]                                                ^
     [javac] Note: Some input files use unchecked or unsafe operations.
     [javac] Note: Recompile with -Xlint:unchecked for details.
     [javac] 10 errors

[Adam Heath-2]

Andrew Zeneski wrote:

> I cannot say exactly how much damage it causes, but since this is as far
> as the framework will compile, I figured it was time for a quick patch.
> If you have a better fix, please by all means check it in. Otherwise,
> let's just make sure we can compile the trunk without errors.
>
> Andrew
>
> -----
>
> classes:
>     [javac] Compiling 15 source files to
> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>     [javac]
> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:
> cannot find symbol
>     [javac] symbol  : method
> runSync(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>     [javac]             Map initialHistoryRes =
> dispatcher.runSync("createEntitySyncHistory",
> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
> "lastCandidateEndTime", this.currentRunEndTime, "userLogin", userLogin));

Everything compiles for me.  I don't check in unless things compile.
What javac are you using?  I use java 1.6 normally.  I just tried with
java 1.5, and it worked as well.  1.5 had a few more warnings, but those
aren't errors.

[Adam Heath-2]

David E Jones wrote:

>
> Interesting... this is worrisome as it means something isn't using the
> ByteWrapper properly. Only the bytes in the ByteWrapper should be sent
> to the database, not a serialized version of the object itself.
>
> Because this issue exists we have a problem though... updating the
> ByteWrapper object will make existing database data stored with it
> useless unless the ByteWrapper object NEVER changes.
>
> Tim, do you have a full stack trace on that? I'd like to trace through
> the code in the content stuff as well as the database that does both the
> saves and loads.
>
> As an interim fix, change the ByteWrapper.java file back to its original
> version (before the enhancements that Adam did recently). I don't know
> if we want to do this in the trunk, but I'll look at that as part of the
> above mentioned review.

Oh bother.

I added 2 new write methods.  Since ByteWrapper implements Serializable,
and does *not* set it's own serialVersionID, one is auto-generated based
on the defined method signatures, and a hash.

This can be fixed, but requires implementing the hidden private methods.
   That'll fix it going forward.

Since there is no set serialVersionID, each compiler is free to
implement it's own algorithm for setting it; it's really poor to not
have one.  I'm not sure this can be fixed in a backwards compatible manner.

(this goes for other serializable classes too)

>
> -David
>
>
> On Oct 22, 2007, at 3:35 PM, Tim Ruppert wrote:
>
>> This was working last week before the supreme amount of changes.
>> Anybody got any ideas why this would be the case now:
>>
>> org.ofbiz.webapp.view.ViewHandlerException: Error in
>> streamDataResource (Unable to read BLOB data from input stream while
>> getting value : imageData [IMAGE_DATA] (1):
>> java.io.InvalidClassException: org.ofbiz.entity.util.ByteWrapper;
>> local class incompatible: stream classdesc serialVersionUID =
>> -2019470610749810950, local class serialVersionUID =
>> -7811889960144925895 (org.ofbiz.entity.util.ByteWrapper; local class
>> incompatible: stream classdesc serialVersionUID =
>> -2019470610749810950, local class serialVersionUID =
>> -7811889960144925895))
>>
>> This is on a fresh checkout, so there are no old classes, etc.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>

[David E Jones]

On Oct 23, 2007, at 12:32 AM, Adam Heath wrote:

> David E Jones wrote:
>>
>> Interesting... this is worrisome as it means something isn't using  
>> the
>> ByteWrapper properly. Only the bytes in the ByteWrapper should be  
>> sent
>> to the database, not a serialized version of the object itself.
>>
>> Because this issue exists we have a problem though... updating the
>> ByteWrapper object will make existing database data stored with it
>> useless unless the ByteWrapper object NEVER changes.
>>
>> Tim, do you have a full stack trace on that? I'd like to trace  
>> through
>> the code in the content stuff as well as the database that does  
>> both the
>> saves and loads.
>>
>> As an interim fix, change the ByteWrapper.java file back to its  
>> original
>> version (before the enhancements that Adam did recently). I don't  
>> know
>> if we want to do this in the trunk, but I'll look at that as part  
>> of the
>> above mentioned review.
>
> Oh bother.
>
> I added 2 new write methods.  Since ByteWrapper implements  
> Serializable,
> and does *not* set it's own serialVersionID, one is auto-generated  
> based
> on the defined method signatures, and a hash.
>
> This can be fixed, but requires implementing the hidden private  
> methods.
>    That'll fix it going forward.
>
> Since there is no set serialVersionID, each compiler is free to
> implement it's own algorithm for setting it; it's really poor to not
> have one.  I'm not sure this can be fixed in a backwards compatible  
> manner.
>
> (this goes for other serializable classes too)

The REAL problem, as I see it, is that what makes it into the  
database is not the binary content, it is the binary content in a  
serialized Java object, which is really weird. So, I'm working on  
code changes to get away from that and just send the bytes over.

To make migration possible I'm reverting the ByteWrapper object to  
it's previous state, and deprecating it.

Where an object to wrap the byte[] is needed I'm changing everything  
from using the ByteWrapper to use the java.nio.ByteBuffer (hopefully  
a little more standardized and flexible...).

-David

[Adam Heath-2]

David E Jones wrote:
>
> The REAL problem, as I see it, is that what makes it into the database
> is not the binary content, it is the binary content in a serialized Java
> object, which is really weird. So, I'm working on code changes to get
> away from that and just send the bytes over.

Well, we may need to look at all implementations of Serializable in the
code base for the same kind of problems.  Data gets put into the
session, and saved between restarts.

But I agree, serialized java objects in a database suck.

[David E Jones]

On Oct 23, 2007, at 1:23 AM, Adam Heath wrote:

> David E Jones wrote:
>>
>> The REAL problem, as I see it, is that what makes it into the  
>> database
>> is not the binary content, it is the binary content in a  
>> serialized Java
>> object, which is really weird. So, I'm working on code changes to get
>> away from that and just send the bytes over.
>
> Well, we may need to look at all implementations of Serializable in  
> the
> code base for the same kind of problems.  Data gets put into the
> session, and saved between restarts.
>
> But I agree, serialized java objects in a database suck.

I'm not so worried about serialized session stuff. That isn't a great  
loss if the object is out of date as the stuff is meant to be  
temporary anyway.

For binary data in the database, my opinion is that it isn't  
acceptable...

-David

[David E Jones]

Okay, this is finally done... :)

The changes are in revision 587433, and more notes are in the commit  
comments.

This is a pretty big hole to plug, and I put a lot of effort into  
backward compatibility, so hopefully the update service  
(unwrapByteWrappers) will allow those with existing data sets to be  
able to update. Also in the interim reading old serialized  
ByteWrapper data should also work fine.

All new and updated data will be persisted as a raw byte[] data  
instead of wrapped in a serialized Java object, which makes it so  
other applications can't read it, and makes it very sensitive to Java  
serialization which isn't very reliable or consistent (which brought  
up the whole problem...).

All those little details made this implementation a bit of a run  
around, so please let me know if anyone has any issues with this.

Someone I'm working with will be testing this soon on a client  
database that has been around for a while, but if anyone runs into  
anything sooner, again please let me know.

-David


On Oct 22, 2007, at 4:21 PM, David E Jones wrote:

>
> Would be interested in feedback on this, here is what I propose:
>
> 1. revert Adam's changes to the ByteWrapper object so that data  
> stored with it can be migrated to be plain bytes instead of a  
> serialized ByteWrapper
> 2. deprecate the ByteWrapper object
> 3. change all code that uses the ByteWrapper object to just use a  
> byte[] (I think this should work fine in Java 1.5)
> 4. create a utility that unwraps all existing serialized  
> ByteWrapper objects and just drops the byte[] into the db; this  
> would have to be run for all existing blob data in any existing  
> database
>
> -David
>
>
> On Oct 22, 2007, at 3:57 PM, Tim Ruppert wrote:
>
>> I do have the zip file that I've sent along - and yes rolling back  
>> worked fine - but there is a much bigger issue 'round this  
>> one . . . :(
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>> On Oct 22, 2007, at 3:42 PM, David E Jones wrote:
>>
>>>
>>> Interesting... this is worrisome as it means something isn't  
>>> using the ByteWrapper properly. Only the bytes in the ByteWrapper  
>>> should be sent to the database, not a serialized version of the  
>>> object itself.
>>>
>>> Because this issue exists we have a problem though... updating  
>>> the ByteWrapper object will make existing database data stored  
>>> with it useless unless the ByteWrapper object NEVER changes.
>>>
>>> Tim, do you have a full stack trace on that? I'd like to trace  
>>> through the code in the content stuff as well as the database  
>>> that does both the saves and loads.
>>>
>>> As an interim fix, change the ByteWrapper.java file back to its  
>>> original version (before the enhancements that Adam did  
>>> recently). I don't know if we want to do this in the trunk, but  
>>> I'll look at that as part of the above mentioned review.
>>>
>>> -David
>>>
>>>
>>> On Oct 22, 2007, at 3:35 PM, Tim Ruppert wrote:
>>>
>>>> This was working last week before the supreme amount of  
>>>> changes.  Anybody got any ideas why this would be the case now:
>>>>
>>>> org.ofbiz.webapp.view.ViewHandlerException: Error in  
>>>> streamDataResource (Unable to read BLOB data from input stream  
>>>> while getting value : imageData [IMAGE_DATA] (1):  
>>>> java.io.InvalidClassException:  
>>>> org.ofbiz.entity.util.ByteWrapper; local class incompatible:  
>>>> stream classdesc serialVersionUID = -2019470610749810950, local  
>>>> class serialVersionUID = -7811889960144925895  
>>>> (org.ofbiz.entity.util.ByteWrapper; local class incompatible:  
>>>> stream classdesc serialVersionUID = -2019470610749810950, local  
>>>> class serialVersionUID = -7811889960144925895))
>>>>
>>>> This is on a fresh checkout, so there are no old classes, etc.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>>
>>>
>>
>

[Adam Heath-2]

Adam Heath wrote:

> Andrew Zeneski wrote:
>> I cannot say exactly how much damage it causes, but since this is as far
>> as the framework will compile, I figured it was time for a quick patch.
>> If you have a better fix, please by all means check it in. Otherwise,
>> let's just make sure we can compile the trunk without errors.
>>
>> Andrew
>>
>> -----
>>
>> classes:
>>     [javac] Compiling 15 source files to
>> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>>     [javac]
>> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:
>> cannot find symbol
>>     [javac] symbol  : method
>> runSync(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>>     [javac]             Map initialHistoryRes =
>> dispatcher.runSync("createEntitySyncHistory",
>> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
>> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
>> "lastCandidateEndTime", this.currentRunEndTime, "userLogin", userLogin));
>
> Everything compiles for me.  I don't check in unless things compile.
> What javac are you using?  I use java 1.6 normally.  I just tried with
> java 1.5, and it worked as well.  1.5 had a few more warnings, but those
> aren't errors.

So, Andy, are you going to respond to this, or what?

[David E Jones]

On Oct 24, 2007, at 4:36 PM, Adam Heath wrote:

> Adam Heath wrote:
>> Andrew Zeneski wrote:
>>> I cannot say exactly how much damage it causes, but since this is  
>>> as far
>>> as the framework will compile, I figured it was time for a quick  
>>> patch.
>>> If you have a better fix, please by all means check it in.  
>>> Otherwise,
>>> let's just make sure we can compile the trunk without errors.
>>>
>>> Andrew
>>>
>>> -----
>>>
>>> classes:
>>>     [javac] Compiling 15 source files to
>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>>>     [javac]
>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/
>>> entityext/synchronization/EntitySyncContext.java:305:
>>> cannot find symbol
>>>     [javac] symbol  : method
>>> runSync
>>> (java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>>>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>>>     [javac]             Map initialHistoryRes =
>>> dispatcher.runSync("createEntitySyncHistory",
>>> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
>>> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
>>> "lastCandidateEndTime", this.currentRunEndTime, "userLogin",  
>>> userLogin));
>>
>> Everything compiles for me.  I don't check in unless things compile.
>> What javac are you using?  I use java 1.6 normally.  I just tried  
>> with
>> java 1.5, and it worked as well.  1.5 had a few more warnings, but  
>> those
>> aren't errors.
>
> So, Andy, are you going to respond to this, or what?

I seem to remember him responding, including a paste of the compile  
errors he was getting and such.

I'm guessing you didn't see that message... I've deleted it already  
but can look it up if you can't find it. Of course, you should be  
able to look it up pretty easily too... ;)

-David

[Adam Heath-2]

David E Jones wrote:

> On Oct 24, 2007, at 4:36 PM, Adam Heath wrote:
>
>> Adam Heath wrote:
>>> Andrew Zeneski wrote:
>>>> I cannot say exactly how much damage it causes, but since this is as
>>>> far
>>>> as the framework will compile, I figured it was time for a quick patch.
>>>> If you have a better fix, please by all means check it in. Otherwise,
>>>> let's just make sure we can compile the trunk without errors.
>>>>
>>>> Andrew
>>>>
>>>> -----
>>>>
>>>> classes:
>>>>     [javac] Compiling 15 source files to
>>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>>>>     [javac]
>>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:
>>>>
>>>> cannot find symbol
>>>>     [javac] symbol  : method
>>>> runSync(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>>>>
>>>>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>>>>     [javac]             Map initialHistoryRes =
>>>> dispatcher.runSync("createEntitySyncHistory",
>>>> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
>>>> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
>>>> "lastCandidateEndTime", this.currentRunEndTime, "userLogin",
>>>> userLogin));
>>>
>>> Everything compiles for me.  I don't check in unless things compile.
>>> What javac are you using?  I use java 1.6 normally.  I just tried with
>>> java 1.5, and it worked as well.  1.5 had a few more warnings, but those
>>> aren't errors.
>>
>> So, Andy, are you going to respond to this, or what?
>
> I seem to remember him responding, including a paste of the compile
> errors he was getting and such.
>
> I'm guessing you didn't see that message... I've deleted it already but
> can look it up if you can't find it. Of course, you should be able to
> look it up pretty easily too... ;)

If you read my last email again, I include one of the errors he got.

I was responding to my own email, which was a response to his response,
that included errors.

I've tried to duplicate the errors he is seeing.  I can't.  There is
something unique to Andy's environment.

[Tim Ruppert]

Nope - I was getting it to - AND on our linux servers, so I'm really not sure what the deal was - but he was not alone.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 24, 2007, at 5:24 PM, Adam Heath wrote:

David E Jones wrote:

On Oct 24, 2007, at 4:36 PM, Adam Heath wrote:

Adam Heath wrote:

Andrew Zeneski wrote:

I cannot say exactly how much damage it causes, but since this is as

far

as the framework will compile, I figured it was time for a quick patch.

If you have a better fix, please by all means check it in. Otherwise,

let's just make sure we can compile the trunk without errors.

Andrew

-----

classes:

    [javac] Compiling 15 source files to

/Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes

    [javac]

/Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:

cannot find symbol

    [javac] symbol  : method

runSync(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)

    [javac] location: interface org.ofbiz.service.LocalDispatcher

    [javac]             Map initialHistoryRes =

dispatcher.runSync("createEntitySyncHistory",

UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",

"ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,

"lastCandidateEndTime", this.currentRunEndTime, "userLogin",

userLogin));

Everything compiles for me.  I don't check in unless things compile.

What javac are you using?  I use java 1.6 normally.  I just tried with

java 1.5, and it worked as well.  1.5 had a few more warnings, but those

aren't errors.

So, Andy, are you going to respond to this, or what?

I seem to remember him responding, including a paste of the compile

errors he was getting and such.

I'm guessing you didn't see that message... I've deleted it already but

can look it up if you can't find it. Of course, you should be able to

look it up pretty easily too... ;)

If you read my last email again, I include one of the errors he got.

I was responding to my own email, which was a response to his response,

that included errors.

I've tried to duplicate the errors he is seeing.  I can't.  There is

something unique to Andy's environment.

[Adam Heath-2]

Adam Heath wrote:

> Andrew Zeneski wrote:
>> I cannot say exactly how much damage it causes, but since this is as far
>> as the framework will compile, I figured it was time for a quick patch.
>> If you have a better fix, please by all means check it in. Otherwise,
>> let's just make sure we can compile the trunk without errors.
>>
>> Andrew
>>
>> -----
>>
>> classes:
>>     [javac] Compiling 15 source files to
>> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>>     [javac]
>> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:
>> cannot find symbol
>>     [javac] symbol  : method
>> runSync(java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>>     [javac]             Map initialHistoryRes =
>> dispatcher.runSync("createEntitySyncHistory",
>> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
>> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
>> "lastCandidateEndTime", this.currentRunEndTime, "userLogin", userLogin));
>
> Everything compiles for me.  I don't check in unless things compile.
> What javac are you using?  I use java 1.6 normally.  I just tried with
> java 1.5, and it worked as well.  1.5 had a few more warnings, but those
> aren't errors.
>

[resend]
So, Andy, are you going to respond to this, or what?

[Andrew Zeneski-2]

I use javac 1.5.0_07 (Apple OSX build 1.5.0_07-164), but I have also  
seen this with 1.5.0_04 on Linux as well. The error comes from a  
total clean build.

Notice that in EntitySyncContext there are a number of inline  
UtilMisc calls which were never changed. You made a number of changes  
to other files, but not this one.

What JDK are you using?

On Oct 25, 2007, at 6:24 PM, Adam Heath wrote:

> Adam Heath wrote:
>> Andrew Zeneski wrote:
>>> I cannot say exactly how much damage it causes, but since this is  
>>> as far
>>> as the framework will compile, I figured it was time for a quick  
>>> patch.
>>> If you have a better fix, please by all means check it in.  
>>> Otherwise,
>>> let's just make sure we can compile the trunk without errors.
>>>
>>> Andrew
>>>
>>> -----
>>>
>>> classes:
>>>     [javac] Compiling 15 source files to
>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
>>>     [javac]
>>> /Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/
>>> entityext/synchronization/EntitySyncContext.java:305:
>>> cannot find symbol
>>>     [javac] symbol  : method
>>> runSync
>>> (java.lang.String,java.util.Map<java.lang.Object,java.lang.Object>)
>>>     [javac] location: interface org.ofbiz.service.LocalDispatcher
>>>     [javac]             Map initialHistoryRes =
>>> dispatcher.runSync("createEntitySyncHistory",
>>> UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
>>> "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
>>> "lastCandidateEndTime", this.currentRunEndTime, "userLogin",  
>>> userLogin));
>>
>> Everything compiles for me.  I don't check in unless things compile.
>> What javac are you using?  I use java 1.6 normally.  I just tried  
>> with
>> java 1.5, and it worked as well.  1.5 had a few more warnings, but  
>> those
>> aren't errors.
>>
>
> [resend]
> So, Andy, are you going to respond to this, or what?