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