Unit Testing Serialization

[Robert Bushman <bo...@traxel.com>]

Turns out this is a much more vexing problem
then I had anticipated. ClassLoaders always
attempt delegation to the parent ClassLoader
first, and the methods that could prevent
this behavior are all final.

Result? You can't create a ClassLoader that
loads an old version of a class, if there
is a newer version in your classpath. Everything
seems to be working nicely until you notice
that the dynamically loaded instance you have
is the new version, not the old.

However, you can call defineClass() and
just hand it the byte[] read from the
legacy .jar file.

Unfortunately, this
approach seems to lead unavoidably to a
java.lang.VerifyError, which has the clear
and meaningful description: 'Thrown when the
"verifier" detects that a class file, though
well formed, contains some sort of internal
inconsistency or security problem.'
Clear as mud. Thanks.

I think I'm at a brick wall on writing this
unit test. I'm going to revert to refactoring
and writing the documentation. I feel that
with the addition of the serialVersionUID
check, this version becomes *at it's worst*
as good as OIS.defaultReadObject(). Further,
it can be demonstrated empirically, though
not easily unit tested, that it is capable of
version safe deserialization from 1.1.3.

-------------------------------------------------------------------
  Who owns your data?
    Proprietary protocols and file formats are dangerous.
-------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Unit Testing Serialization

[Robert Bushman <bo...@traxel.com>]

Ahhh, excellant idea!

On Thu, 29 Nov 2001, Ceki Gulcu wrote:

>
> Robert,
>
> One possible solution is to have two classloaders each of which loads log4j from different directories and not putting log4j.jar on the classpath. That should do the trick. HTH, Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Unit Testing Serialization

[Ceki Gulcu <ce...@qos.ch>]

Robert,

One possible solution is to have two classloaders each of which loads log4j from different directories and not putting log4j.jar on the classpath. That should do the trick. HTH, Ceki


At 00:16 28.11.2001 -0500, you wrote:
>Turns out this is a much more vexing problem
>then I had anticipated. ClassLoaders always
>attempt delegation to the parent ClassLoader
>first, and the methods that could prevent
>this behavior are all final.
>
>Result? You can't create a ClassLoader that
>loads an old version of a class, if there
>is a newer version in your classpath. Everything
>seems to be working nicely until you notice
>that the dynamically loaded instance you have
>is the new version, not the old.
>
>However, you can call defineClass() and
>just hand it the byte[] read from the
>legacy .jar file.
>
>Unfortunately, this
>approach seems to lead unavoidably to a
>java.lang.VerifyError, which has the clear
>and meaningful description: 'Thrown when the
>"verifier" detects that a class file, though
>well formed, contains some sort of internal
>inconsistency or security problem.'
>Clear as mud. Thanks.
>
>I think I'm at a brick wall on writing this
>unit test. I'm going to revert to refactoring
>and writing the documentation. I feel that
>with the addition of the serialVersionUID
>check, this version becomes *at it's worst*
>as good as OIS.defaultReadObject(). Further,
>it can be demonstrated empirically, though
>not easily unit tested, that it is capable of
>version safe deserialization from 1.1.3.
>
>-------------------------------------------------------------------
>  Who owns your data?
>    Proprietary protocols and file formats are dangerous.
>-------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>