avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mirceat...@home.com>
Subject unistall implementation (was Re: App instantiation problem - advice needed.)
Date Wed, 24 Oct 2001 20:36:57 GMT
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" <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@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


Mime
View raw message