You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Eung-ju Park <co...@isoft.co.kr> on 2001/10/06 09:50:16 UTC
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.
---------------------------------------------------------------------
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