A "search path" for JSPs?

[Steinar Bang <sb...@dod.no>]

What I would like to do is to custimize installations of a
struts-based web application, in a way that isn't overwritten when a
new version of the webapp's .war file is installed.

Is it possible to do something like this for a struts application?

 - deliver the application as a .war file
 - customize the application by putting JSP files with the same names
   as the files inside the .war file into a directory that is scanned
   before the directory of the .war

Ie. have a search path for the JSPs?

Other ideas I have considered, are:
 - Change <forward> elements in the struts-config.xml file to point to
   the locally customized JSPs.
   This is difficult because the struts-config.xml resides inside of
   the .war file.  I'm also not sure if it is possible to point
   outside of the webapp?
 - Run a cronjob (or something) to patch the unpacked webapp by
   overwriting distributed JSPs with locally customized versions.
   This feels like a hack/last resort
 - Replace the class that reads the struts-config.xml file with a
   class that reads its config data from a database

Is there some obvious approach I have overlooked?

Thanx!


- Steinar



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Site customizations of webapps (Was: A "search path" for JSPs?)

[Steinar Bang <sb...@dod.no>]

>>>>> Steinar Bang <sb...@dod.no>:

> What I would like to do is to custimize installations of a
> struts-based web application, in a way that isn't overwritten when a
> new version of the webapp's .war file is installed.
[snip!]
> Ie. have a search path for the JSPs?

> Other ideas I have considered, are:
[snip!]

Here's my current best idea:
 - Don't use a .war for the webapp.  Deliver the webapp with an RPM
   that uses a directory out of tomcat's normal hierachy, and change
   server.xml to add a context for this directory
 - Subclass ActionServlet and replace the function that adds the
   action mapping (seems to be actionMapping() in 1.0, but that
   function was gone in HEAD), to first do a
	super.initMapping();
   and then read action configs from the database, potentially
   replacing the actions set by struts-config.xml

Instead of creating JSPs with identical names that are picked before
the standard JSPs, new JSPs will be created with different names, or
put in a separate subdirectory, and actions forwarding to these JSPs
will be put into the database.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>