hi guys. my company is writing a "shrinkwrap" java servlet web application. we chose to write the app using the java servlet webapp paradigm for a number of reasons, not the least of which is that there is a nice standard way to package webapps for easy installation on any compliant servlet container. we're running into difficulties, however, in figuring out how to customize the deployment descriptor for the webapp on the customer's box.
for instance, the webapp looks for some servlet context configuration parameters to figure out what database url, username, and password or J2EE datasource it should use for persistent storage. we cannot set those data before packaging the webapp for sale since they're going to be different for each customer. another for instance is security constraints; we know that the customer is probably going to want to authenticate access to certain portions of the webapp, but we have no idea which groups or roles the customer is going to want to use. question is, what's the best way of changing these properties, either at installation time or whenever the customer changes their database? my naive answer was that we should tell the customer to install the webapp and then edit the servlet context configuration parameters using whatever facilities are provided by their servlet container. however, those facilities seem to be crude to nonexistent in the servlet containers we've used so far (websphere, resin, tomcat). another thought is that we should tell the customer to edit the deployment descriptor directly (either by hand or via a tool). unfortunately, not only do we not know where in the filesystem the web.xml will be extracted to, we don't even know that it _will_ be extracted to the filesystem, or that the servlet container won't unpack the webapp again the next time it restarts, destroying the changes to web.xml. the solution we're using now is to provide an installer that the client runs at installation (or whenever they change databases or other info in the deployment descriptor) that unzips the war archive, prompts them for values to put into the deployment descriptor, and then zips up the war archive again. this strikes me as cumbersome and wrong in some way, however. it may also make upgrading the webapp later tricky since the upgrade installer will have to merge the deployment descriptors from the currently installed product and the upgraded version. has anyone else had to address this issue or does anyone have any ideas on a better way to do so? i feel like there's a hole in the spec here; servlet and servlet context configuration parameters are things that are going to vary from installation to installation, but the way servlet engines handle war files doesn't seem to make it easy for customers to edit those parameters. maybe i am missing something? - donald ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
