Hi!
Aaron Mulder wrote:
> Hmmm... disturbing. I've never seen a JDBC driver try to
> deserialize internally to reply to getObject. I've only seen it return a
> raw byte array from getObject if it didn't have anything more appropriate.
> Hmph. I'm not sure there's an answer to this one.
> The correct ClassLoader, for what it's worth, is
> Thread.currentThread().getContextClasLoader() which seems to be used by
> RMI but not a general ObjectInputStream. So one solution would be for the
> Hypersonic folks to use that when they deserialize. Another would be
> for getObject to return a byte array, as I've seen it do before (though
> I can't remember whether it was Hypersonic or InstantDB). I'm a little
> uncomfortable about never trying getObject if we can't figure out what to
> call, since I'm not sure getBytes would return something coherent if there
> was actually a valid Object in the result set.
> But hey, I guess we're just as well fixing the bug you can
> demonstrate rather than the possibility that rubs me the wrong way.
One way to solve this is to not store the object directly, but first put
into a MarshalledObject. This will ensure that the context CL is used
during deserilization, regardless of who does it.
I.e.:
Object obj = someobj;
MarshalledObject mo = new MarshalledObject(obj);
stmt.setObject(idx, mo);
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
