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 13:43:05 UTC
App instantiation problem - advice needed.
I am migrating Rana's FtpServer Admn GUI to be a Jesktop app (as well as
standalone). It works in standalone mode, but not when installed into
Jesktop which is weird because dozens of other apps I have ported do
work fine and are not that different.
I am getting a NoClassDefFoundError on org.jesktop.frimble.JFrimble.
I'm looking for advice on how to debug this scenario. The class I am
trying to instantiate (FtpAdminFrame) is there, but the class loader is
not finding the parent class (JFrimble) when it should do, it's worked a
million times before. Is it possibly a red-herring in that it's
actially some other class that is being looked for (and not found) or
perhaps a class versioning issue (which I doubt). We are talking of a
chain of classloaders about three or four deep (including Phoenix as the
primordial of course).
I really don't think this is related to the recent sar changes, as many
apps, upon installation, are still working.
Advice needed :-)
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: unistall implementation (was Re: App instantiation problem - advice needed.)
Posted by Peter Donald <do...@apache.org>.
On Thu, 25 Oct 2001 06:36, Mircea Toma wrote:
> Hi,
>
> I managed to complete application uninstall implementation (removing only
> the unmodified expanded files). I still have a problem with block files,
> when Installer tries to delete them will fail because the files are used by
> another process. The only process I can think of is the URLClassLoader but
> I'm not sure and I don't see how I can solve this problem anyway ... maybe
> you do?!
Change to a real OS ? ;)
Im not sure that there is an easy way to "fix" it under win32. What we can do
is dispose of all classloader material, call System.gc(0 and wait a bit and
hope that the GC has released file lock. Not sure.
> Peter, in a previous email you said that file digests (filename and
> checksum) should be stored to a file. You think that's still necessary? And
> if it is, why?
yep - still necessary. The reason is that I see installtion happening only
once - not everytime you start up phoenix.
So i want to do something like
install.sh myApp.sar
and then later on when I want to uninstalll it do something like
uninstall.sh myApp.sar
or something. Currently we install + uninstall everytime phoenix launches -
however that is mainly legacy from ages ago ;)
Does that make sense ?
--
Cheers,
Pete
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
unistall implementation (was Re: App instantiation problem - advice needed.)
Posted by Mircea Toma <mi...@home.com>.
Hi,
I managed to complete application uninstall implementation (removing only
the unmodified expanded files). I still have a problem with block files,
when Installer tries to delete them will fail because the files are used by
another process. The only process I can think of is the URLClassLoader but
I'm not sure and I don't see how I can solve this problem anyway ... maybe
you do?!
Peter, in a previous email you said that file digests (filename and
checksum) should be stored to a file. You think that's still necessary? And
if it is, why?
Mircea
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Tuesday, October 23, 2001 2:26 AM
Subject: Re: App instantiation problem - advice needed.
> On Tue, 23 Oct 2001 09:08, Mircea Toma wrote:
> > The only problem is that installation from remote URL-s are not possible
> > anymore (I guess you want to implement that once VFS is implemented).
>
> hmmm .. I forgot about that. I may have to add it back in ;)
>
> > There are a few things I wanted to bring to your attention:
> >
> > - right now there is no way to install multiple applications from the
same
> > .sar file because the application relative directory gets its name from
the
> > installation URL. I think that the Deployer should create application
base
> > directory and pass that to the Installer.
>
> sounds reasonable.
>
> > - for the unistallation part, files expanded to the file-system (not if
a
> > file is in the way) can be registered into the Installation object, when
> > uninstall is called the Installer will check the modification date and
> > remove only the files who were not modified.
>
> agreed. I would also check hases of the file aswell.
>
> > - instead of expanding the config.xml maybe is better to have a
persistent
> > ConfigurationRepository?!
>
> definetly ! But thats for the future.
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> For every complex problem there is a solution that
> is simple, neat and wrong
> ---------------------------------------------------
>
> ---------------------------------------------------------------------
> 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: App instantiation problem - advice needed.
Posted by Peter Donald <do...@apache.org>.
On Tue, 23 Oct 2001 09:08, Mircea Toma wrote:
> The only problem is that installation from remote URL-s are not possible
> anymore (I guess you want to implement that once VFS is implemented).
hmmm .. I forgot about that. I may have to add it back in ;)
> There are a few things I wanted to bring to your attention:
>
> - right now there is no way to install multiple applications from the same
> .sar file because the application relative directory gets its name from the
> installation URL. I think that the Deployer should create application base
> directory and pass that to the Installer.
sounds reasonable.
> - for the unistallation part, files expanded to the file-system (not if a
> file is in the way) can be registered into the Installation object, when
> uninstall is called the Installer will check the modification date and
> remove only the files who were not modified.
agreed. I would also check hases of the file aswell.
> - instead of expanding the config.xml maybe is better to have a persistent
> ConfigurationRepository?!
definetly ! But thats for the future.
--
Cheers,
Pete
---------------------------------------------------
For every complex problem there is a solution that
is simple, neat and wrong
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: App instantiation problem - advice needed.
Posted by Mircea Toma <mi...@home.com>.
Hi,
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Monday, October 22, 2001 7:58 AM
Subject: Re: App instantiation problem - advice needed.
> Hi,
>
> I started to rework the Installer slightly to work with the format I
proposed
> a while back. Everything in SAR-INF except config.xml/server.xml should
not
> be extracted. Anyways can you run it again and see if this produces any
> different results. I have a suspicion of where to look if the latest
version
> does not work for you.
>
> Mircea could you also check that I did things right and didn't remove any
of
> your functionality. I think I just reworked it a bit so hopefully it
should
> all be there.
The only problem is that installation from remote URL-s are not possible
anymore (I guess you want to implement that once VFS is implemented).
There are a few things I wanted to bring to your attention:
- right now there is no way to install multiple applications from the same
.sar file because the application relative directory gets its name from the
installation URL. I think that the Deployer should create application base
directory and pass that to the Installer.
- for the unistallation part, files expanded to the file-system (not if a
file is in the way) can be registered into the Installation object, when
uninstall is called the Installer will check the modification date and
remove only the files who were not modified.
- instead of expanding the config.xml maybe is better to have a persistent
ConfigurationRepository?!
mircea
>
> On Sat, 20 Oct 2001 21:43, Paul Hammant wrote:
> > I am migrating Rana's FtpServer Admn GUI to be a Jesktop app (as well as
> > standalone). It works in standalone mode, but not when installed into
> > Jesktop which is weird because dozens of other apps I have ported do
> > work fine and are not that different.
> >
> > I am getting a NoClassDefFoundError on org.jesktop.frimble.JFrimble.
> > I'm looking for advice on how to debug this scenario. The class I am
> > trying to instantiate (FtpAdminFrame) is there, but the class loader is
> > not finding the parent class (JFrimble) when it should do, it's worked a
> > million times before. Is it possibly a red-herring in that it's
> > actially some other class that is being looked for (and not found) or
> > perhaps a class versioning issue (which I doubt). We are talking of a
> > chain of classloaders about three or four deep (including Phoenix as the
> > primordial of course).
> >
> > I really don't think this is related to the recent sar changes, as many
> > apps, upon installation, are still working.
> >
> > Advice needed :-)
> >
> > Regards,
> >
> > - Paul H
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> --
> Cheers,
>
> Pete
>
> *-------------------------------------*
> | Does the name `Pavlov' ring a bell? |
> *-------------------------------------*
>
> ---------------------------------------------------------------------
> 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: App instantiation problem - advice needed.
Posted by Peter Donald <do...@apache.org>.
Hi,
I started to rework the Installer slightly to work with the format I proposed
a while back. Everything in SAR-INF except config.xml/server.xml should not
be extracted. Anyways can you run it again and see if this produces any
different results. I have a suspicion of where to look if the latest version
does not work for you.
Mircea could you also check that I did things right and didn't remove any of
your functionality. I think I just reworked it a bit so hopefully it should
all be there.
On Sat, 20 Oct 2001 21:43, Paul Hammant wrote:
> I am migrating Rana's FtpServer Admn GUI to be a Jesktop app (as well as
> standalone). It works in standalone mode, but not when installed into
> Jesktop which is weird because dozens of other apps I have ported do
> work fine and are not that different.
>
> I am getting a NoClassDefFoundError on org.jesktop.frimble.JFrimble.
> I'm looking for advice on how to debug this scenario. The class I am
> trying to instantiate (FtpAdminFrame) is there, but the class loader is
> not finding the parent class (JFrimble) when it should do, it's worked a
> million times before. Is it possibly a red-herring in that it's
> actially some other class that is being looked for (and not found) or
> perhaps a class versioning issue (which I doubt). We are talking of a
> chain of classloaders about three or four deep (including Phoenix as the
> primordial of course).
>
> I really don't think this is related to the recent sar changes, as many
> apps, upon installation, are still working.
>
> Advice needed :-)
>
> Regards,
>
> - Paul H
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
--
Cheers,
Pete
*-------------------------------------*
| Does the name `Pavlov' ring a bell? |
*-------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: App instantiation problem - advice needed.
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>I think we should fix the problem rather than add a hackity hack ;) In
>reality you should not be able to tell the difference between using a
>filesystem and libs in a jar.
>
I agree completely. But, we have to question why Sun have the
URLStreamHandlerFactory in one of the constructors for URLClassLoader....
I think that's a strong hint that complex classloaders trees will not
work without it. Jesktop just happens to be the first to encounter
this, JAMES has maillets which (I presume) are loaded in separate
classloaders, but it's fixed at a previous Phoenix version for the moment.
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: App instantiation problem - advice needed.
Posted by Peter Donald <do...@apache.org>.
I think we should fix the problem rather than add a hackity hack ;) In
reality you should not be able to tell the difference between using a
filesystem and libs in a jar.
On Tue, 23 Oct 2001 18:38, Paul Hammant wrote:
> Folks,
>
> I am fairly sure that we need to add the following to BlockContext.
>
> URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
>
> Reason? Phoenix apps that host sub apps in separate classloaders fail
> to traverse the parent classloader tree correctly.
> I would just add it, but Phoenix is an area of minor activity for me,
> and major for others.
>
> Regards,
>
> - Paul H
>
> >> I think it should be :
> >>
> >> public class JesktopURLClassLoader extends URLClassLoader {
> >> protected JesktopURLClassLoader(final URL[] urls) {
> >> super(urls, JesktopURLClassLoader.class.getClassLoader(),
> >> Phoenix.getURLStreamHandlerFactory());
> >> }
> >> }
> >
> > I can confirm that that fixes the bug I have.
> > I had to add...
> >
> > URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
> >
> > .. to BlockContext to get it working. I have not comitted any changes,
> > because I think this needs discussion.
> >
> > 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
--
Cheers,
Pete
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: App instantiation problem - advice needed.
Posted by Paul Hammant <Pa...@yahoo.com>.
Mircea,
>>I am fairly sure that we need to add the following to BlockContext.
>>
>> URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
>>
>>Reason? Phoenix apps that host sub apps in separate classloaders fail
>>to traverse the parent classloader tree correctly.
>>
>
>I'll check it out! It might be enough to set URL.setURLSr...... within that
>classloader.
>
That could work too, but it's a small variation. We'd still need the
URLStreamHandlerFactory passed in via BlockContext as phoenix-client.jar
only exposes interfaces. Your excellent SAR stream handler is in impl
and this hidden from phoenix dependant apps for purposes of compilation
if not class visibility too.
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: App instantiation problem - advice needed.
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Tuesday, October 23, 2001 2:38 AM
Subject: Re: App instantiation problem - advice needed.
> Folks,
>
> I am fairly sure that we need to add the following to BlockContext.
>
> URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
>
> Reason? Phoenix apps that host sub apps in separate classloaders fail
> to traverse the parent classloader tree correctly.
I'll check it out! It might be enough to set URL.setURLSr...... within that
classloader.
Mircea
> I would just add it, but Phoenix is an area of minor activity for me,
> and major for others.
>
> Regards,
>
> - Paul H
>
>
>
> >> I think it should be :
> >>
> >> public class JesktopURLClassLoader extends URLClassLoader {
> >> protected JesktopURLClassLoader(final URL[] urls) {
> >> super(urls, JesktopURLClassLoader.class.getClassLoader(),
> >> Phoenix.getURLStreamHandlerFactory());
> >> }
> >> }
> >
> >
> > I can confirm that that fixes the bug I have.
> > I had to add...
> >
> > URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
> >
> > .. to BlockContext to get it working. I have not comitted any changes,
> > because I think this needs discussion.
> >
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: App instantiation problem - advice needed.
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
I am fairly sure that we need to add the following to BlockContext.
URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
Reason? Phoenix apps that host sub apps in separate classloaders fail
to traverse the parent classloader tree correctly.
I would just add it, but Phoenix is an area of minor activity for me,
and major for others.
Regards,
- Paul H
>> I think it should be :
>>
>> public class JesktopURLClassLoader extends URLClassLoader {
>> protected JesktopURLClassLoader(final URL[] urls) {
>> super(urls, JesktopURLClassLoader.class.getClassLoader(),
>> Phoenix.getURLStreamHandlerFactory());
>> }
>> }
>
>
> I can confirm that that fixes the bug I have.
> I had to add...
>
> URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
>
> .. to BlockContext to get it working. I have not comitted any changes,
> because I think this needs discussion.
>
> 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: App instantiation problem - advice needed.
Posted by Paul Hammant <Pa...@yahoo.com>.
> I think it should be :
>
> public class JesktopURLClassLoader extends URLClassLoader {
> protected JesktopURLClassLoader(final URL[] urls) {
> super(urls, JesktopURLClassLoader.class.getClassLoader(),
> Phoenix.getURLStreamHandlerFactory());
> }
> }
I can confirm that that fixes the bug I have.
I had to add...
URLStreamHandlerFactory getDefaultURLStreamHandlerFactory();
.. to BlockContext to get it working. I have not comitted any changes,
because I think this needs discussion.
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: App instantiation problem - advice needed.
Posted by Paul Hammant <Pa...@yahoo.com>.
I am tracing this issue and it is most weird as it does not affect all apps.
I think it's because Jesktop hosts it's own applications and that I
should be giving a hint (for want of a better word) to the JVM that
there is a URLStreamHandlerFactory in the picture.
Here is the current class loader:
package org.apache.avalon.jesktop.core;
import java.net.URLClassLoader;
import java.net.URL;
public class JesktopURLClassLoader extends URLClassLoader {
protected JesktopURLClassLoader(final URL[] urls) {
super(urls, JesktopURLClassLoader.class.getClassLoader());
}
}
I think it should be :
public class JesktopURLClassLoader extends URLClassLoader {
protected JesktopURLClassLoader(final URL[] urls) {
super(urls, JesktopURLClassLoader.class.getClassLoader(),
Phoenix.getURLStreamHandlerFactory());
}
}
Granted there is no such method Phoenix.getURLStreamHandlerFactory(),
and if there were it would not be static anyway.
Hmmm, still searching for the cause.
Regards,
- Paul H
> I am migrating Rana's FtpServer Admn GUI to be a Jesktop app (as well
> as standalone). It works in standalone mode, but not when installed
> into Jesktop which is weird because dozens of other apps I have ported
> do work fine and are not that different.
>
> I am getting a NoClassDefFoundError on org.jesktop.frimble.JFrimble.
> I'm looking for advice on how to debug this scenario. The class I am
> trying to instantiate (FtpAdminFrame) is there, but the class loader
> is not finding the parent class (JFrimble) when it should do, it's
> worked a million times before. Is it possibly a red-herring in that
> it's actially some other class that is being looked for (and not
> found) or perhaps a class versioning issue (which I doubt). We are
> talking of a chain of classloaders about three or four deep (including
> Phoenix as the primordial of course).
>
> I really don't think this is related to the recent sar changes, as
> many apps, upon installation, are still working.
>
> Advice needed :-)
>
> 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