Mircea, >>Is there a way, in xml configuration/assembly to force the unzipping of >>a sar entirely (as it used to be)? >> > >No, there isn't! > >>I ask because I'm chasing a second bug with deserialization (using >>Cornerstone's Store): >> >> ClassNotFoundException: >>org.apache.avalon.jesktop.core.LaunchableTargetHolder >> >>Now the class is there and the code used to worked for months, but now >>is not. The issue is that the Deserialization needs to use the same >>classloader that was holding the instance when it was serialed. We >>first encounteed this bug months ago and had to create a special >>ObjectInputStream derivative >>(org.apache.avalon.excalibur.io.ClassLoaderObjectInputStream) to >>overcome the issue. Now it seems that the JVM refuses to belive that >>the same classloader is in use for the shutdown of Jesktop and it's >>subsequent reboot. >> > >Maybe by adding the extracted directories to the classloader codebase would >solve the problem?! > Hmmm, I don't think that is applicable. Fede's Store does not use extracted directories from teh sar file for its persistence.
>>For the purposes of bug investigation I'd like to plain switch on SAR >>inzipping again. Is this possible using an assembly.xml entry? >> > >We can do that of course but I would prefer to know more about your problem >so we come up with a good consistent solution! > OK, it looks like you're volunteering to see the bug in action ;-) 1) (cornerstone) build jesktop main 2) (cornerstone) build jesktop install 3) phoenix/dist/bin .... run.bat 4) When Frame comes up, Ctrl-C (or choose Start->Shutdown) 3) phoenix/dist/bin .... run.bat ... exception is apparent in Sys.out Repeat test with phoenix bin from http://jakarta.apache.org/builds/jakarta-avalon/nightly/2001-10-14/ With the older Phoenix, the big is not apparent... Thanks for your help. Regards, - Paul H --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
