--- Gianugo Rabellino <[EMAIL PROTECTED]> wrote:
> grenoml wrote:
> I
>
> > >>tend to think that there shouldn't be anything like a Catalina
> > >>configuration file, Catalina is not the only app server around.
> The
> > >idea >
> > >>is that the WAR should be as app-server agnostic as possible
>
>
> > I see your point about being app-server agnostic but I also see
> nothing
> > wrong with providing the user with a specific script for Tomcat,
> the
> > reference implementation, as long as it is clearly identified as
> being
> > for Tomcat.
>
>
> Absolutely +1, and thanks for providing it. It will be for sure
> included
> in the distribution.
>
> > Ok, the context config file is very simple to use. All you have to
> do
> > is place it in 'webapps' directory along with the WAR. The WAR and
> the
> > context config file must have exactly the same root name and only
> > differ as to extension, e.g. xindice1.1b.war, xindice1.1b.xml. Due
> to
> > a Tomcat chicken and egg scenario you may need to restart Tomcat
> > *twice* the very first time you use this file in order to see your
> new
> > context ( http://.../Xindice ) show up.
>
>
> Boy... this is ugly. :-/ Anyway, are we talking about every Tomcat
> around (3.x, 4.x) or just the latest versions?
>
Well, it's not that ugly!
1. The 'context XML config file' came into being with the Tomcat 4.1.x
releases. For earlier Tomcat releases the user can just put the
context mapping into the server.xml file or alternatively download the
release-identified war and rename it to Xindice.war.
2. It's use is enabled as long as the 'deployXML' attribute on the Host
element is set to 'true' which is the default.
3. Tomcat internally uses this mechanism for deploying its own 'admin'
and 'manager' apps.
4. The use of this file is really quite simple. The first-time chicken
and egg thing is probably already fixed (I'm using Tomcat 4.1.9).
> > >As for renaming the war xindice.war, I don't mind. It up to the
> > >Tomcat
> > >users to give their opinions. But it must be really easy to
> figure
> > >out
> > >the version, like adding this information to the war's metafile.
> >
> >
> > Being a somewhat experienced Tomcat user, I would much rather
> prefer
> > the context config file approach that maps the version to the
> /Xindice
> > context path and having the release number as part of the WAR name.
> > Once you rename a war to Xindice.war you have no idea what version
> that
> > WAR is. I dislike having jars and wars around that have no
> identifying
> > release number associated with them. A user can always rename the
> > xindice release-identified war file to 'Xindice.war' if they need
> to.
>
>
> I think that this is a matter of pure taste. I consider myself a
> somewhat experienced (albeit a bit disappointed) Tomcat user, but
> still
> I like more to have plain setups (besides, I would certainly use your
>
> context file for loggins setup, that's really cool). I think that if
> the
> jars inside WEB-INF/lib are versioned it's easy enough to understand
> what version you are running.
I'm not agreeing with you here. There's just no guarantee that any
of the jars in WEB-INF/lib would change between releases or that a
*user* would ever remember which third-party jar changes went with
which release of Xindice.
> OTOH, if the war is called just like
> the
> webapp, it's real "drop and forget" (which is an important target, at
>
> least to me).
You can still have this. The user just has to rename the
release-identified war to Xindice.war. Put it in an INSTALL DOC in BIG
BOLD LETTERS!
>Actually I never did any tomcat remapping, for these
> kind
> of needs I usually resort to the connector configuration in Apache.
>
> But again, I think it's a matter of taste, and I'm fine with both
> choices.
>
> > >Other
> > >idea: it would be nice to have zip and tar.gz archives for the war
> > >too.
> > > We would then have 3 releases (bin, war and src).
>
> I'm OK with this too. My only concern is about added complexity: we
> already have a questionable setup for the average DBA ("a .war? what
> am
> I supposed to do with a web application? I want a database"), so we
> need
> to make really clear what are the different archives about, since
> actually there is the server packaged as a war archive and the client
>
> packaged as a binary archive. I think that most people tend to think
> the
> opposite way ("oh, ok, the war is the web client, the bin is the
> server.
> I just need the server, so I'm set with the bin"). See my point?
Again, I think all that is necessary is a good INSTALL DOC that tells
them what each piece is and does.
>
> > One other suggestion:
> > I think that the Xindice WAR should contain a pre-populated
> collection
> > in the /db and a servlet that would kind of demonstrate what
> Xindice is
> > all about. I'm thinking maybe the example Addressbook servlet
> would
> > work here. This should be available from a welcome page when the
> user
> > goes to http://localhost:8080/Xindice/welcome or something like
> that.
> > As I stated on the lists before, the initial user experience is
> really
> > very important and by providing users with a real quick way to get
> a
> > grasp on Xindice I think it will help introduce Xindice to more
> users.
>
> Good suggestion, but it needs some work: I don't think that database
> trees and files are cross-platform, so it might be the case to
> populate
> them on the first request. Actually I'd rather have a demo
> application
> in .war file format 'a' la' drop-n-forget for that.
>
> Ciao,
>
> --
> Gianugo Rabellino
>
I think that the Xindice war should contain some type of internal
servlet for this rather than requiring the user to drop a separate war
into Tomcat. I like the concept of having a database collection setup
on first request. I think that whatever the first user demonstration
experience with Xindice is to be, that it must be entirely
self-contained within the Xindice war file. I'm speaking with my
*user* hat on here.
Regards,
Gerry Reno
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
