You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Geoff Bennett <ge...@multitask.com.au> on 2003/07/01 01:38:12 UTC

RE: Modules and common files

Thanks Wendy, but the situation is a little different. They are common 
resources, not necessarily static resources.
For example:
        <script language="JavaScript" src="<html:rewrite page=
"/scripts/utilScript.jsp" />"></script>

When this line is processed on a jsp we get 
'/web-context/module-name/scripts/utilScript.jsp'
as the src element, but the file actually exists at 
'/web-context/scripts/utilScript.jsp' for EVERY module.

Is there some way to do this besides create our own tag or modify an 
existing one?


Thanks,

Geoff Bennett




Wendy Smoak <We...@asu.edu> 
01/07/2003 07:46 AM
Please respond to
"Struts Users Mailing List" <st...@jakarta.apache.org>


To
'Struts Users Mailing List' <st...@jakarta.apache.org>
cc

Subject
RE: Modules and common files






Geoff wrote:
> We have just started using modules and have run into a problem when it 
> comes to common files between the modules (eg: javascript, stylesheets,
images). 
> Has anyone else had this problem? If so, what did you do?

I have Apache serve these static resources.  For example, off the main
server root there is an 'images' directory.  In the Struts app, these 
links
are done as "/images/picture.jpg".  The leading slash backs up all the way
to the server root, and Apache will serve up the .jpg from the images
directory.

For development, I use Tomcat alone on my desktop.  To imitate the
Apache/Tomcat setup on the production server, I have placed 'images' in 
the
ROOT webapp.  That way no changes are required when I deploy to the
Apache/Tomcat setup.

If you have many different apps that need their own "common" files, you
could create a  directory structure under Apache's document root (or
Tomcat's ROOT webapp), maybe /common/thiswebapp/images, or whatever works.

This does make deployment a bit more work than just dropping in a .war 
file,
but it could be automated with a script to move the static resources where
they belong.

HTH,

-- 
Wendy Smoak
Applications Systems Analyst, Sr.
Arizona State University, PA, IRM