You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/25 20:14:59 UTC
[phoenix] Relooking at distributions
Hi,
Ages ago when we were deciding on the format of the .sar file there was a
number of proposals, questions and requests. I want to relook at our choices
again because I think we may have made a mistake ;)
.bar vs .jar
------------
The question of whether block archives should be named <myarchive>.bar or
<myarchive>.jar was asked. The first form was chosen because it allowed us to
easily identify archives with blocks in them. However that information is
already contained in the manifest of jar (namely Blocks are marked by
Avalon-Block: true attribute). So in theory we could rename this to jar with
little loss code-wise .... but do we loose anything conceptually.
Personally I can see certain advantages of both ways (.bar is easily human
distinguisable while .jar fits in with rest of java conventions) however I
have no real opinion which is better. However 2 separate people have asked me
to allow .bars to be named .jars recently so not sure. Thoughts? If we were
to change this we could still do it in a backwards compatible way and just
issue warnings that you are using .bar rather than .jar or whatever.
SAR-INF vs not
--------------
Originally we were also going to store a lot of the information in
SAR-INF/lib, SAR-INF/blocks and SAR-INF/conf rather than lib/, blocks/ and
conf/. At the time it was not obvious what the advantage would be other than
matching the patterns already used in java.
However I now see an advantage in using SAR-INF. The reason is that when
expanding the .sar we could designate everything in SAR-INF/** as being not
needed to be extracted. As SAR-INF only contains read-only data for
application that is manipulated by kernel (and not directly by application) I
can't see a negative. If you wanted data to be extracted when application is
installed (maybe a database or set of data XML files) then you would not
store them in SAR-INF and instead store them in base directory.
Thoughts? I like it and would +1 this ;) If we change this it would be easy
to do it in a backwards compatible manner.
blocks/ vs lib/
---------------
Is there a need for two different directories? In effect they are not treated
any different and merging them into on (say lib/) would simplify the
deployment format. Again - this could be done in a backwards portable manner.
Like this or not? (I think I do).
If we were to accept all these changes then the deployment layout would be
something like
SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
SAR-INF/lib/mySupport.jar
SAR-INF/conf/server.xml or SAR-INF/server.xml
SAR-INF/conf/config.xml or SAR-INF/config.xml
SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
data/my-random-datafile.txt
And only the last file would be expanded on filesystem.
--
Cheers,
Pete
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 10:44, Eung-ju Park wrote:
> > SAR-INF vs not
> > --------------
...snip...
>
> -1. Is configuration is read-only?
Well the other specs like servlet/ejb/etc (ie .war/.ear assemblies) have
read-only configurations. If you need to change configuration you are meant
to change it inside war/ear before you deploy it. IIRC there was an
opensource GUI that made this easy to (perhaps associated with JBOSS
project???).
However in time I suspect the configuration in the .sar will only be a
template that will be expanded once we install the sar file. So our config
template will be read-only while I am not sure about our config instance (or
even if it will be contained in .sar).
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Eung-ju Park <co...@isoft.co.kr>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, September 26, 2001 3:14 AM
Subject: [phoenix] Relooking at distributions
> Hi,
>
> Ages ago when we were deciding on the format of the .sar file there was a
> number of proposals, questions and requests. I want to relook at our
choices
> again because I think we may have made a mistake ;)
>
> .bar vs .jar
> ------------
>
> The question of whether block archives should be named <myarchive>.bar or
> <myarchive>.jar was asked. The first form was chosen because it allowed us
to
> easily identify archives with blocks in them. However that information is
> already contained in the manifest of jar (namely Blocks are marked by
> Avalon-Block: true attribute). So in theory we could rename this to jar
with
> little loss code-wise .... but do we loose anything conceptually.
>
> Personally I can see certain advantages of both ways (.bar is easily human
> distinguisable while .jar fits in with rest of java conventions) however I
> have no real opinion which is better. However 2 separate people have asked
me
> to allow .bars to be named .jars recently so not sure. Thoughts? If we
were
> to change this we could still do it in a backwards compatible way and just
> issue warnings that you are using .bar rather than .jar or whatever.
+0
>
> SAR-INF vs not
> --------------
>
> Originally we were also going to store a lot of the information in
> SAR-INF/lib, SAR-INF/blocks and SAR-INF/conf rather than lib/, blocks/ and
> conf/. At the time it was not obvious what the advantage would be other
than
> matching the patterns already used in java.
>
> However I now see an advantage in using SAR-INF. The reason is that when
> expanding the .sar we could designate everything in SAR-INF/** as being
not
> needed to be extracted. As SAR-INF only contains read-only data for
> application that is manipulated by kernel (and not directly by
application) I
> can't see a negative. If you wanted data to be extracted when application
is
> installed (maybe a database or set of data XML files) then you would not
> store them in SAR-INF and instead store them in base directory.
>
> Thoughts? I like it and would +1 this ;) If we change this it would be
easy
> to do it in a backwards compatible manner.
-1. Is configuration is read-only?
>
> blocks/ vs lib/
> ---------------
>
> Is there a need for two different directories? In effect they are not
treated
> any different and merging them into on (say lib/) would simplify the
> deployment format. Again - this could be done in a backwards portable
manner.
> Like this or not? (I think I do).
+0.
>
>
>
> If we were to accept all these changes then the deployment layout would be
> something like
>
> SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
> SAR-INF/lib/mySupport.jar
> SAR-INF/conf/server.xml or SAR-INF/server.xml
> SAR-INF/conf/config.xml or SAR-INF/config.xml
> SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> data/my-random-datafile.txt
>
> And only the last file would be expanded on filesystem.
>
> --
> Cheers,
>
> Pete
>
> ----------------------------------------------------------------
> Fools ignore complexity. Pragmatists suffer it.
> Some can avoid it. Geniuses remove it.
> -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
> ----------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Sat, 6 Oct 2001 17:50, Eung-ju Park wrote:
> > If we were to accept all these changes then the deployment layout would
> > be something like
> >
> > SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
> > SAR-INF/lib/mySupport.jar
> > SAR-INF/conf/server.xml or SAR-INF/server.xml
> > SAR-INF/conf/config.xml or SAR-INF/config.xml
> > SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> > data/my-random-datafile.txt
> >
> > And only the last file would be expanded on filesystem.
>
> SAR-INF/lib/myBlockArchive.jar
> SAR-INF/lib/mySupport.jar
> SAR-INF/server.xml
> SAR-INF/config.xml
> SAR-INF/assembly.xml
> data/my-random-datafile.txt
>
> I think above layout is good. because web.xml is placed in WEB-INF.
> And extract server.xml, config.xml, assembly.xml. before we have
> configuration templating mechanism.
Okays - works for me ;)
--
Cheers,
Pete
---------------------------------------
Be nice to your friends. If it weren't
for them, you'd be a complete stranger.
---------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
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 06, 2001 3:44 AM
Subject: Re: [phoenix] Relooking at distributions
> >
> >
> >>SAR-INF/lib/myBlockArchive.jar
> >>SAR-INF/lib/mySupport.jar
> >>SAR-INF/server.xml
> >>SAR-INF/config.xml
> >>SAR-INF/assembly.xml
> >>data/my-random-datafile.txt
> >>
> >>I think above layout is good. because web.xml is placed in WEB-INF.
> >>And extract server.xml, config.xml, assembly.xml. before we have
> >>configuration templating mechanism.
> >>
> >
> >I agree.
> >Looks clean and consistent.
-1
> >
> It is clean & consistent, but :
>
> WAR files are about web-content. As such all that's at the root level
> of the archive (HTML, JSP, GIF etc) can be said to be the primary
> content. Stuff in WEB-INF/classes and WEB-INF/lib can be said to be
> support. I.e. they are given a namespace (WEB-INF/*) that is unlikely
> to be required in the directory structure of the primary content.
I agree!
>
> I don't think Phoenix server apps are that category of thing. If I
> agree with SAR-INF at all it's to replace the "conf" dir and no more.
> That is, unless someone can come up with an example of a SAR files that
> would need the root namespace to the same level as WAR files do.
For simplicity sake I would put server.xml, config.xml and assembly.xml in
META-INF directory. Support libraries would go in 'lib' directory together
with block jars.
>
> Exec summary : Paul votes -1
>
> 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: [phoenix] Relooking at distributions
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>
>Technically I can't until you lift your -1 ;) Practically I can't as I have
>no time atm ;)
>
I'll drop to -0.5 to account for my weight in this area.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Sun, 7 Oct 2001 18:22, Paul Hammant wrote:
> Perhaps the ideal web server could take a WAR file (with plenty of
> static content) and, at load time, hand the static content to some
> sister server that is more tuned to serving static content.
Actually I remember hearing someone mutter that tomcat was going to try to do
that with one of the Apache connectors (warp?) or something. Not sure if it
does that right now though.
> I stand by
> my definition, despite performance concerns, that a WAR's root is for
> content and WEB-INF is a convenient place to hide conf, libs & classes.
And conversely a SAR's root is for content (or application data) and SAR-INF
is a convenient place to hide conf, libs & classes ???
> Of course I understand that servers come
> with conf and a miriad of jars. My point was simply that stuffing
> everything into SAR-INF looks daft and more like an imitation of WAR
> files.
It is an imitation but not everything will be stuffed into SAR-INF. In fact
there is quite a lot of stuff that won't be in a SAR-INF. It is just that up
until now we have not differentiated between stuff that is extracted and
stuff that is not. Ideally large chunks of james .sar will be extracted while
the standard *.bar, *.jar does not need to be extracted.
> However, I'm not a do-er in this area of Phoenix, so feel free
> to ignore my comments.
Technically I can't until you lift your -1 ;) Practically I can't as I have
no time atm ;)
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>WAR files are about web-content.
>>
>
>No - WAR files are about web applications, much like SAR files are about
>server applications ;)
>
>> As such all that's at the root level
>>of the archive (HTML, JSP, GIF etc) can be said to be the primary
>>content.
>>
>
>Some people do that but it is a misuse of it. Ideally anything that is not
>dynamically generated or an integral part of Web Application should be hosted
>behind a real web-server which has faaar better performance characteristerics
>and support than any servlet engine is likely to have for a while.
>
>But anyways thats just a pet hate of mine ;)
>
Perhaps the ideal web server could take a WAR file (with plenty of
static content) and, at load time, hand the static content to some
sister server that is more tuned to serving static content. I stand by
my definition, despite performance concerns, that a WAR's root is for
content and WEB-INF is a convenient place to hide conf, libs & classes.
>> Stuff in WEB-INF/classes and WEB-INF/lib can be said to be
>>support. I.e. they are given a namespace (WEB-INF/*) that is unlikely
>>to be required in the directory structure of the primary content.
>>
>
>SAR-INF/ sounds like support for server applications?
>
>>I don't think Phoenix server apps are that category of thing. If I
>>agree with SAR-INF at all it's to replace the "conf" dir and no more.
>>
>
>The reason is because currently there is no way we can only partially extract
>.sars. We need someway to separate support data from other data.
>
>> That is, unless someone can come up with an example of a SAR files that
>>would need the root namespace to the same level as WAR files do.
>>
>
>Almost all servers include documentation, some include sample data for
>serving or configuration or whatever. Of all the servers I have installed I
>can only think of one (DJ Bernsteins DNS server) that did not come with
>application data.
>
>For instance the httpd server comes with sample config files, documentation
>and a few other support utilities (like those for creating "encypted"
>password files). It is conceivable that James will come with separate mailet
>jars, mailet config and docs in future. DNS comes with whole sets of command
>line utilities as do the scheduling tools.
>
>Can you think of any server applications that don't (or shouldn't) have this
>sort of data? If not would you have these installed separately?
>
It was not about that Pete. Of course I understand that servers come
with conf and a miriad of jars. My point was simply that stuffing
everything into SAR-INF looks daft and more like an imitation of WAR
files. However, I'm not a do-er in this area of Phoenix, so feel free
to ignore my comments.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Sat, 6 Oct 2001 19:44, Paul Hammant wrote:
> >>SAR-INF/lib/myBlockArchive.jar
> >>SAR-INF/lib/mySupport.jar
> >>SAR-INF/server.xml
> >>SAR-INF/config.xml
> >>SAR-INF/assembly.xml
> >>data/my-random-datafile.txt
> >>
> >>I think above layout is good. because web.xml is placed in WEB-INF.
> >>And extract server.xml, config.xml, assembly.xml. before we have
> >>configuration templating mechanism.
> >
> >I agree.
> >Looks clean and consistent.
>
> It is clean & consistent, but :
>
> WAR files are about web-content.
No - WAR files are about web applications, much like SAR files are about
server applications ;)
> As such all that's at the root level
> of the archive (HTML, JSP, GIF etc) can be said to be the primary
> content.
Some people do that but it is a misuse of it. Ideally anything that is not
dynamically generated or an integral part of Web Application should be hosted
behind a real web-server which has faaar better performance characteristerics
and support than any servlet engine is likely to have for a while.
But anyways thats just a pet hate of mine ;)
> Stuff in WEB-INF/classes and WEB-INF/lib can be said to be
> support. I.e. they are given a namespace (WEB-INF/*) that is unlikely
> to be required in the directory structure of the primary content.
SAR-INF/ sounds like support for server applications?
> I don't think Phoenix server apps are that category of thing. If I
> agree with SAR-INF at all it's to replace the "conf" dir and no more.
The reason is because currently there is no way we can only partially extract
.sars. We need someway to separate support data from other data.
> That is, unless someone can come up with an example of a SAR files that
> would need the root namespace to the same level as WAR files do.
Almost all servers include documentation, some include sample data for
serving or configuration or whatever. Of all the servers I have installed I
can only think of one (DJ Bernsteins DNS server) that did not come with
application data.
For instance the httpd server comes with sample config files, documentation
and a few other support utilities (like those for creating "encypted"
password files). It is conceivable that James will come with separate mailet
jars, mailet config and docs in future. DNS comes with whole sets of command
line utilities as do the scheduling tools.
Can you think of any server applications that don't (or shouldn't) have this
sort of data? If not would you have these installed separately?
--
Cheers,
Pete
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>>SAR-INF/lib/myBlockArchive.jar
>>SAR-INF/lib/mySupport.jar
>>SAR-INF/server.xml
>>SAR-INF/config.xml
>>SAR-INF/assembly.xml
>>data/my-random-datafile.txt
>>
>>I think above layout is good. because web.xml is placed in WEB-INF.
>>And extract server.xml, config.xml, assembly.xml. before we have
>>configuration templating mechanism.
>>
>
>I agree.
>Looks clean and consistent.
>
It is clean & consistent, but :
WAR files are about web-content. As such all that's at the root level
of the archive (HTML, JSP, GIF etc) can be said to be the primary
content. Stuff in WEB-INF/classes and WEB-INF/lib can be said to be
support. I.e. they are given a namespace (WEB-INF/*) that is unlikely
to be required in the directory structure of the primary content.
I don't think Phoenix server apps are that category of thing. If I
agree with SAR-INF at all it's to replace the "conf" dir and no more.
That is, unless someone can come up with an example of a SAR files that
would need the root namespace to the same level as WAR files do.
Exec summary : Paul votes -1
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: [phoenix] Relooking at distributions
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Eung-ju Park [mailto:colus@isoft.co.kr]
> Sent: Saturday, 06 October, 2001 09:50
> To: Avalon Development
> Subject: Re: [phoenix] Relooking at distributions
>
>
> > If we were to accept all these changes then the deployment
> layout would be
> > something like
> >
> > SAR-INF/lib/myBlockArchive.jar (note the .jar rather than
> .bar ending)
> > SAR-INF/lib/mySupport.jar
> > SAR-INF/conf/server.xml or SAR-INF/server.xml
> > SAR-INF/conf/config.xml or SAR-INF/config.xml
> > SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> > data/my-random-datafile.txt
> >
> > And only the last file would be expanded on filesystem.
>
> SAR-INF/lib/myBlockArchive.jar
> SAR-INF/lib/mySupport.jar
> SAR-INF/server.xml
> SAR-INF/config.xml
> SAR-INF/assembly.xml
> data/my-random-datafile.txt
>
> I think above layout is good. because web.xml is placed in WEB-INF.
> And extract server.xml, config.xml, assembly.xml. before we have
> configuration templating mechanism.
I agree.
Looks clean and consistent.
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Eung-ju Park <co...@isoft.co.kr>.
> If we were to accept all these changes then the deployment layout would be
> something like
>
> SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
> SAR-INF/lib/mySupport.jar
> SAR-INF/conf/server.xml or SAR-INF/server.xml
> SAR-INF/conf/config.xml or SAR-INF/config.xml
> SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> data/my-random-datafile.txt
>
> And only the last file would be expanded on filesystem.
SAR-INF/lib/myBlockArchive.jar
SAR-INF/lib/mySupport.jar
SAR-INF/server.xml
SAR-INF/config.xml
SAR-INF/assembly.xml
data/my-random-datafile.txt
I think above layout is good. because web.xml is placed in WEB-INF.
And extract server.xml, config.xml, assembly.xml. before we have
configuration templating mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 17:49, Ulrich Mayring wrote:
> Peter Donald wrote:
> > Hmmm then there is something wrong here. I just went and updated 9
> > projects that use phoenix and I managed to bring them up to speed in
> > about 35 minutes.
>
> Perhaps because you wrote the stuff and I'm just a user without docs? :)
probably. I will try to be more clear about things that will need changing in
future then ;)
> > Even then all the changes of late in Phoenix have been backwards
> > compatible and only issue warnings when you dont comply.
>
> Well, recently I had to convert all my blocks to interfaces.
Not sure what you mean.
> Then the
> ThreadManager section left server.xml, went to config.xml and became its
> own block. I had to figure out which of the cornerstone blocks use it.
> Then I had to add <block> sections instead of <meta> sections etc.
>
> It really doesn't help much to deprecate and keep backwards
> compatibility, because that only delays the point where things break. So
> I better fix it now, because in several months I won't know anymore what
> I have to do.
Well my hope was that displaying warning messages explaining what was wrong
would make it easier to migrate to new interfaces. Some of the messages were
less specific but I have just made them more a bit more useful today and so
you should get exact messages telling you what to change.
Anyways this is probably just an active period. I have had two weeks off and
needed to keep active ;) So the slew of changes is definetly not a regular
occurence.
> > The changes that I am suggesting are almost required as the basis of
> > further progress. For instance a requested features is that .sar files
> > are not extracted onto filesystem if at all possible to stop people
> > accidently messing up the deployments. This is not really possible to do
> > now because we don't know which parts are safe to be kept in archive and
> > which need to be extracted. It is also required if/when I get around to
> > adding in some funky deployment management stuff.
>
> Well, this sounds nice, but I'd prefer if the current mechanism would
> work first. The .sar archives are not reliably expanded, sometimes old
> files from previous .sar archives are not overwritten. Perhaps have
> Avalon automatically delete the deployment directory on startup? That's
> what I currently have to do.
The problem is that the current mechanism is expected behaviour. If the
directory has already been extracted then it won't be written over. This was
to follow trends with other similar systems (specifically Tomcat3.x and many
other servlet containers).
It wouldn't be possible to delete this directory because many applications
use this directory to store extra information generated at runtime. For
instance it could be used to store a mail spool, log files, or virtually
anything else that the server generates/uses.
> > Anyways what I would suggest is that you complain loudly about specific
> > changes if you don't like them ;) That way we can add more backwards
> > compatability/transitioning support or maybe revert the change.
>
> My suggestion is to change things when it becomes necessary, not before.
> So, once you start to actually do some funky stuff with .sar archives,
> that would be a good time to change the .sar structure, if required.
> It's easier to sell to the users, because they immediately see what they
> get for it :)
Well I would suggest that you stay with recently released phoenix for a while
and perhaps wait till beta before grabbing next download.
I don't have the time/resources to develope in large steps. It has to be
incremental changes when I or other peeps have time. If we were to require
these large steps nothing would ever get done ;)
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Donald wrote:
>
> Hmmm then there is something wrong here. I just went and updated 9 projects
> that use phoenix and I managed to bring them up to speed in about 35 minutes.
Perhaps because you wrote the stuff and I'm just a user without docs? :)
> Even then all the changes of late in Phoenix have been backwards compatible
> and only issue warnings when you dont comply.
Well, recently I had to convert all my blocks to interfaces. Then the
ThreadManager section left server.xml, went to config.xml and became its
own block. I had to figure out which of the cornerstone blocks use it.
Then I had to add <block> sections instead of <meta> sections etc.
It really doesn't help much to deprecate and keep backwards
compatibility, because that only delays the point where things break. So
I better fix it now, because in several months I won't know anymore what
I have to do.
> The changes that I am suggesting are almost required as the basis of further
> progress. For instance a requested features is that .sar files are not
> extracted onto filesystem if at all possible to stop people accidently
> messing up the deployments. This is not really possible to do now because we
> don't know which parts are safe to be kept in archive and which need to be
> extracted. It is also required if/when I get around to adding in some funky
> deployment management stuff.
Well, this sounds nice, but I'd prefer if the current mechanism would
work first. The .sar archives are not reliably expanded, sometimes old
files from previous .sar archives are not overwritten. Perhaps have
Avalon automatically delete the deployment directory on startup? That's
what I currently have to do.
> Anyways what I would suggest is that you complain loudly about specific
> changes if you don't like them ;) That way we can add more backwards
> compatability/transitioning support or maybe revert the change.
My suggestion is to change things when it becomes necessary, not before.
So, once you start to actually do some funky stuff with .sar archives,
that would be a good time to change the .sar structure, if required.
It's easier to sell to the users, because they immediately see what they
get for it :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 05:41, Uli Mayring wrote:
> On Wed, 26 Sep 2001, Peter Donald wrote:
> > If we were to accept all these changes then the deployment layout would
> > be something like
> >
> > SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
> > SAR-INF/lib/mySupport.jar
> > SAR-INF/conf/server.xml or SAR-INF/server.xml
> > SAR-INF/conf/config.xml or SAR-INF/config.xml
> > SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> > data/my-random-datafile.txt
>
> Is that part of the "exciting and important things" you were planning on
> doing to Phoenix? :)
part of it.
> I see nothing wrong in allowing Block Archives as .bar, .jar or, for all I
> care, as .foo or whatever people decide on. But why prefer one name over
> the other? Either specify exactly what the name should be or leave it to
> the users, anything in-between creates unnecessary complexity.
I am not sure what you are saying. Quite a few people would prefer it if we
just used one convention to locate code which is exactly what I am proposing.
ie All code is stored in SAR-INF/lib/*.jar rathern than in multiple places
and multiple extensions (ie lib/*.jar and blocks/*.bar).
The aim of simplifying this to use one convention is to reduce uneeded
complexity ;)
> Like in ant now I am told that the jarfile attribute is deprecated and I
> should use file instead. Hell, why not just keep jarfile around and make
> an internal pointer to file? From a user's perspective "file" instead of
> "jarfile" is not really a cool new feature :)
jarfile does redirect to file. However theres a similar argument there. WOuld
you prefer to use ant if there were 100 ant tasks that all used different
attribute names for the same thing and each time you had to use task you
neede to go to documentation to figure out what the name of the attribute is
(ie src, source, nested filestet, file, dir, ....). Compare this to using
consistent naming conventions throughout ant tasks - much easier to read and
write files without having to go to documentation. Much better no?
Feature driven development is not something that leads to high quality
software. MS is a prime example of a shop that uses feature driven
development. It is true that a lot of their software eventually gets decent
or even good but they have thousands of man hours they can throw at a problem
... after it has been released and sold ;)
> I estimate we spend about 20 hours every week to change our applications
> and build-scripts, so that they work with the newest Avalon. Of course
> alpha means "can change", but it does not mean "must change, even for
> micro-benefits" :)
Hmmm then there is something wrong here. I just went and updated 9 projects
that use phoenix and I managed to bring them up to speed in about 35 minutes.
Even then all the changes of late in Phoenix have been backwards compatible
and only issue warnings when you dont comply. The one binary incompatability
(that I know of) is the removal of old ThreadContext and some changes to
ThreadPool interface from Excalibur project. This was unfortunate but
necessary for progress and you probably should not have been relying on these
classes considering they were Alpha and I had said several times for quite a
few months that I would change them ;)
Was there other changes that broke your builds or something? (If you tell us
we can revert or make it easier to migrate you across).
The changes that I am suggesting are almost required as the basis of further
progress. For instance a requested features is that .sar files are not
extracted onto filesystem if at all possible to stop people accidently
messing up the deployments. This is not really possible to do now because we
don't know which parts are safe to be kept in archive and which need to be
extracted. It is also required if/when I get around to adding in some funky
deployment management stuff.
Anyways what I would suggest is that you stay with the version you are
currently using (or maybe the recently released version) until Phoenix goes
beta. Between now and phoenix-beta I hope to make all changes backward
compatible and will just issue warnings if you don't comply ;) When we change
from alpha to beta there will be backwards incompatible changes but if you
wait till then to update phoenix it may be easier to manage - not sure.
Anyways what I would suggest is that you complain loudly about specific
changes if you don't like them ;) That way we can add more backwards
compatability/transitioning support or maybe revert the change.
--
Cheers,
Pete
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Relooking at distributions
Posted by Uli Mayring <ul...@denic.de>.
On Wed, 26 Sep 2001, Peter Donald wrote:
> If we were to accept all these changes then the deployment layout would be
> something like
>
> SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending)
> SAR-INF/lib/mySupport.jar
> SAR-INF/conf/server.xml or SAR-INF/server.xml
> SAR-INF/conf/config.xml or SAR-INF/config.xml
> SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> data/my-random-datafile.txt
Is that part of the "exciting and important things" you were planning on
doing to Phoenix? :)
I see nothing wrong in allowing Block Archives as .bar, .jar or, for all I
care, as .foo or whatever people decide on. But why prefer one name over
the other? Either specify exactly what the name should be or leave it to
the users, anything in-between creates unnecessary complexity.
Like in ant now I am told that the jarfile attribute is deprecated and I
should use file instead. Hell, why not just keep jarfile around and make
an internal pointer to file? From a user's perspective "file" instead of
"jarfile" is not really a cool new feature :)
I estimate we spend about 20 hours every week to change our applications
and build-scripts, so that they work with the newest Avalon. Of course
alpha means "can change", but it does not mean "must change, even for
micro-benefits" :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org