You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/10/20 15:19:36 UTC
Sar unpacking
Mircea,
Is there a way, in xml configuration/assembly to force the unzipping of
a sar entirely (as it used to be)?
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.
For the purposes of bug investigation I'd like to plain switch on SAR
inzipping again. Is this possible using an assembly.xml entry?
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Sar unpacking
Posted by Peter Donald <do...@apache.org>.
On Sat, 20 Oct 2001 23:19, Paul Hammant wrote:
> 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.
yikes - that may be because I am forgetting to set a thread local somewhere.
Ping me again if you can not track it down. I should be able to hack for a
bit today or maybe tuesday afternoon ;)
> For the purposes of bug investigation I'd like to plain switch on SAR
> inzipping again. Is this possible using an assembly.xml entry?
No but I havce implemented my SAR-INF proposal and may add that as a switch.
I just got to check it in and make sure everything is toasty. ;)
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Sar unpacking
Posted by Paul Hammant <Pa...@yahoo.com>.
Mircea,
>I followed your instuctions to recreate the bug, but everything looks fine!
>No System.out messages or errors in any of the log files! I did restarted a
>few times Phoenix with no problems at all.
>
Yup me too. I take it all back, if the problem were ever concrete, then
it has gone now. Sorry for wasting your time.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Sar unpacking
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Saturday, October 20, 2001 4:54 PM
Subject: Re: Sar unpacking
> 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
Hi Paul,
I followed your instuctions to recreate the bug, but everything looks fine!
No System.out messages or errors in any of the log files! I did restarted a
few times Phoenix with no problems at all.
mircea
>
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Sar unpacking
Posted by Paul Hammant <Pa...@yahoo.com>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Sar unpacking
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Saturday, October 20, 2001 7:19 AM
Subject: Sar unpacking
> 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?!
>
> 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!
mircea
>
> Regards,
>
> - Paul H
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org