sar undeployment implementation

[Mircea Toma <mi...@home.com>]

Hi,

Attached you can find the implemention for sar undeployment!

Mircea

Re: sar undeployment implementation

[Mircea Toma <mi...@home.com>]

----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@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

Re: sar undeployment implementation

[Peter Donald <do...@apache.org>]

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.

> 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. 

-- 
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

Re: sar undeployment implementation

[Mircea Toma <mi...@home.com>]

----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Saturday, October 06, 2001 12:21 AM
Subject: Re: sar undeployment implementation


> On Tue, 2 Oct 2001 13:08, Mircea Toma wrote:
> > Hi,
> >
> > Attached you can find the implemention for sar undeployment!
>
> Cool - I applied most of it except for uninstallation part. The reason was
> that we don't want uninstallation to delete whole tree because apps may be
> storing data in there (ie james stores it's mail spool there). I just
issued
> an error message for the time being.

Ok!

>
> What we should do is something like the following. When installing we
create
> 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. 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?!

Mircea

>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------------
> To fight and conquer in all your battles is not supreme
> excellence; supreme excellence consists in breaking the
> enemy's resistance without fighting. - Sun Tzu, 300 B.C.
> -------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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 undeployment implementation

[Peter Donald <do...@apache.org>]

On Sat, 6 Oct 2001 20:53, Pratik Patel wrote:
> There is a point I would like to bring up sooner rather than later w.r.t
> SAR deployment/undeployment and misc data files.
> Should we make a separate directory for config & data for SARs? Here's some
> reasons:

Thats a long term goal for me ;) The config data should be solely managed by 
the ConfigurationRepository. In case of the default configuration repository 
this will probably be good to be stored in another directory somewhere. In 
case of LDAP this is stored on a directory server somewhere.

However I really haven't thought about it long enough at this stage and don't 
have a lt of time to impliment it. Unless your volunteering to do it ? ;)

> * Upgrades: the code may change, but the config file will likely remain the
> same between at least minor releases of a bar/sar
> * Upgrades: data is not likely to be scrapped between upgrades, it might
> even be necessary to keep 'old' data around

definetly! 

I just had to go through the pain of upgrading something the other week and 
it was painful.

> * Upgrades: if the config file FORMAT does change, the bar would be
> responsible for migrating old config -> new config

Thats an interesting idea. I am not sure where the responsibility for this 
should lie though. I would prefer to use an XSL sheet to perform upgrades or 
maybe a separate class that is passed Config tree. So you add something like

<config-updater-class>com.biz.MyBlockUpdater</config-updater-class>

to your block info. That could be a very very very very good feature. It is 
something I know quite a few people would like. 

> * ModifyableConfig: When we eventually implement modifable configs, we need
> to have a standard place for reading and writing config files
> * Management Console: When we eventually write a managment console it would
> make it easier to discover config files which should be accessible for
> modification.
>
> The question as to where this separate dir (if at all) should be located.
> I've always bounced between keeping all of the bits of a module together
> vs. logically putting bits of a module into neat little buckets. Let me
> explain with some examples:

I can go either way. For small deployments, keeping all the bits of a module 
together is superior. However as soon as you start clustering or have large 
scale deployment it is better to centrally manage these things.

A few people in academic environs have requested centralized management a few 
times. They wanted to centrally manage all things from one place. ie Even if 
there was 10 different Foo servers round the place there would be one place 
where configuration is managed.

> Logically putting bits of a module into neat little buckets
> /avalon/config/BARname/config.xml
> /avalon/config/BAR2name/config.xml
> /avalon/config/BAR2name/users.xml
> /avalon/config/BAR2name/preferences.xml
> /avalon/config/server.xml
> /avalon/config/assembly.xml
> /avalon/data/BARname/bar_data_file.txt
> /avalon/data/BAR2name/spool/....
> /avalon/data/BAR2name/users/user1.data
> /avalon/common/lib/avalon.jar
> /avalon/common/lib/phoenix.jar
> /avalon/sar/BARname/BAR.jar
> /avalon/sar/BAR2name/BAR2.jar

Thats one thing that the EAS people wanted ages. The infrastructure for this 
sort of thing is about 30% done. I started to write an excalibur.extensions.* 
that managed repositorys of JDK1.3 style extensions. So you could say that 
Block foo requires SAX extension compatible with version 2.0 and Phoenix 
would search in Package Repository and grab out a suitable jar (say xerces or 
maybe crimson).

So when this is done you can store all the .bar and .jar files in a central 
repository (if they are marked as extensions/Optional Packages). All you have 
to do is make sure your code requires them using standard Optional Package 
declarations (see jdk1.3 docs for an example).

The rest would require minor changes to the Installer tool. So it is not hard 
to program this - it is just hard to figure out how to support this. Once we 
have more fully developed install/uninstall it should be easier to tweak 
though.

Anyways I kinda like the way we do it now for most purposes.

-- 
Cheers,

Pete

------------------------------------------------------------
 I just got lost in thought... It was unfamiliar territory.
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: sar undeployment implementation

[Pratik Patel <pr...@metalab.unc.edu>]

> Cool - I applied most of it except for uninstallation part. The reason was
> that we don't want uninstallation to delete whole tree because apps may be
> storing data in there (ie james stores it's mail spool there). I just
issued
> an error message for the time being.

There is a point I would like to bring up sooner rather than later w.r.t SAR
deployment/undeployment and misc data files.
Should we make a separate directory for config & data for SARs? Here's some
reasons:
* Upgrades: the code may change, but the config file will likely remain the
same between at least minor releases of a bar/sar
* Upgrades: data is not likely to be scrapped between upgrades, it might
even be necessary to keep 'old' data around
* Upgrades: if the config file FORMAT does change, the bar would be
responsible for migrating old config -> new config
* ModifyableConfig: When we eventually implement modifable configs, we need
to have a standard place for reading and writing config files
* Management Console: When we eventually write a managment console it would
make it easier to discover config files which should be accessible for
modification.

The question as to where this separate dir (if at all) should be located.
I've always bounced between keeping all of the bits of a module together vs.
logically putting bits of a module into neat little buckets. Let me explain
with some examples:

What was proposed in another email, or keeping all of the bits of a module
together
>>SAR-INF/lib/myBlockArchive.jar
>>SAR-INF/lib/mySupport.jar
>>SAR-INF/server.xml
>>SAR-INF/config.xml
>>SAR-INF/assembly.xml
>>SAR-INF/data/my-random-datafile.txt (I've prepended SAR-INF to this one)
(not exactly like this, but something similar)

Logically putting bits of a module into neat little buckets
/avalon/config/BARname/config.xml
/avalon/config/BAR2name/config.xml
/avalon/config/BAR2name/users.xml
/avalon/config/BAR2name/preferences.xml
/avalon/config/server.xml
/avalon/config/assembly.xml
/avalon/data/BARname/bar_data_file.txt
/avalon/data/BAR2name/spool/....
/avalon/data/BAR2name/users/user1.data
/avalon/common/lib/avalon.jar
/avalon/common/lib/phoenix.jar
/avalon/sar/BARname/BAR.jar
/avalon/sar/BAR2name/BAR2.jar


I prefer keeping everything together (first example above) but what got me
thinking about this was the management of these components: upgrading
sars/bars, adding/removing config params, handling data between server
restarts/code updates. The other thought was partitioning the data from the
everything else: if we have a mail spool or some other data directory, we
would ideally want to be able to keep an eye on it and even keep it on a
separate filesystem(?) in case it starts to grow quickly. Of course, option
two requires alot of work to unpack a bar/sar properly, and it is messy. The
danger in keeping everything together is that its too easy to think of
SAR-INF (or whatever we call it) as disposable rather than something that
should be persistant.

cheers
Pratik



---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: sar undeployment implementation

[Peter Donald <do...@apache.org>]

On Tue, 2 Oct 2001 13:08, Mircea Toma wrote:
> Hi,
>
> Attached you can find the implemention for sar undeployment!

Cool - I applied most of it except for uninstallation part. The reason was 
that we don't want uninstallation to delete whole tree because apps may be 
storing data in there (ie james stores it's mail spool there). I just issued 
an error message for the time being. 

What we should do is something like the following. When installing we create 
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. 

-- 
Cheers,

Pete

-------------------------------------------------------
To fight and conquer in all your battles is not supreme 
excellence; supreme excellence consists in breaking the 
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org