> > The file is there I suppose (config/xindice.xml), but here I
> disagree. 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, so
> it's OK 
> > to add a configuration snippet, but I'd rather call the WAR
> Xindice.war 
> > so that there are no misunderstandings.

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.  A large number of users appear to be using Tomcat right
now so I see benefit here.  This way too all users would be able to
adapt it to whatever might be appropriate for their particular
app-server.  Maybe a how-to would be enough with the scripts contents
included and explained but I personally being a Tomcat user would like
to have the file available for download.  Since it can't exist inside
the WAR perhaps just posting it along with the .zip and .tar.gz files
would suffice.


> I tried the xindice.xml file and it wouldn't work with my Tomcat. 
> Since 
> I'm not a Tomcat user, I asked Gerry for a detailed (aka dumb-ass)
> howto 
> to see where the problems are.  But if we have a detailed Tomcat
> howto 
> with the configuration described, I don't have any problem removing
> the 
> file.

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.  That's all the 'how-to' there
is to this thing.  For specific internal details I would just link to
the explanation within the Tomcat site.  This file is working fine for
me.  If the user can't get this file to work then there is probably a
syntax problem in the file somewhere or they have redefined some
Context attributes like 'autoDeploy' to false.  

Another approach that accomplishes the same thing is to put this same
context mapping in the server.xml file which would be the way that
other app-servers would probably do it if they didn't support context
config files (they all have some type of main configuration file) .


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

> 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 agree with Vladimir totally on this and I would add the context
config file for Tomcat users to this list.  That way if you only want
the WAR you can get just the WAR (and optionally the context config
file) without having to bother with everything else.  With the
'xindicewar' script being internal to the WAR you would have everything
you need really in one neat package.  Just drop it into Tomcat and go.

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.

Regards,

Gerry Reno


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Reply via email to