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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
