Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Message-ID: <001301c14efd$b99cadb0$36094318@home.com>
From: "Mircea Toma" <mirceatoma@home.com>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
References: <001001c14aef$8176cbd0$36094318@home.com>
 <20011006062740.VRJD13193.mss.rdc2.nsw.optushome.com.au@there>
 <001b01c14ed4$3e6d0550$36094318@home.com>
 <20011007061940.VTEW13193.mss.rdc2.nsw.optushome.com.au@there>
Subject: Re: sar undeployment implementation
Date: Sun, 7 Oct 2001 01:00:18 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Sent: Sunday, October 07, 2001 12:08 AM
Subject: Re: sar undeployment implementation


> On Sun, 7 Oct 2001 12:03, Mircea Toma wrote:
> > > a list of files we install. Each file we copy we should copy via a
> > > DigestOutputStream and then get a MessageDigest of each file. So after
we
> > > install these files we create an installation "transcript" that looks
> > > like
> > >
> > > blocks/cornerstone.bar &jG%Jp(64H
> > >
> > > with one file + digest per line.
> > >
> > > Then when we goto uninstall we only try to delete the files actually
> > > installed. And we make sure they haven't been modified by getting
their
> > > digest and if they have been modified we skip deletion.
> >
> > Got it!... One question though, if we don't have to unjar the .sar files
in
> > the future there will be no need to do this step.
>
> We will need it for all the other non-support material. ie a Web server
may
> come with docs, a few sample .war files or whatever.

ok! I will try to implement it next week!

>
> > Then I would better try
> > to work on the VFS or a protocol handler that will allow to read nested
> > jars. Maybe you can explain how do you see it done?!
>
> VFS would be nice but I think it would be overkill at this stage. I was
> simply thinking of creating a URLStreamHandler that reads from a jar. So
we
> could go "sar:/SAR-INF/lib/myBlocks.jar" to refer to that resource in the
> .sar.
>
> As jar URLs can contain nested URLs we would then specify a particular
class
> like and all would run fine with a simple 1 line change in installer.
>
> jar:sar:/SAR-INF/lib/myBlocks.jar!/com/biz/MyBlock.class
>
> So basically al you should have to implement is a URLStreamHandler and a
> simple URLStreamHandlerFactory. It should be simple and just take a bit of
> time.

Yes!!! That's the thing I was referring to when I said 'protocol handler'. I
will definitely do this!

Mircea

>
> --
> Cheers,
>
> Pete
>
> --------------------------------
> My opinions may have changed,
> but not the fact that I am right
> --------------------------------
>
> ---------------------------------------------------------------------
> 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