Mircea,
Hmmm, I don't think that is applicable. Fede's Store does not use extracted directories from teh sar file for its persistence.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?!
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]
