Win a copy of Getting started with Java programming language this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Global javascript file available to all webapps on Tomcat server  RSS feed

 
Duke Keys
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

maybe this is a very basic question, but i couldn't find it inhere nor browsing google.
(Probably i'm not using the best search terms)
I have a Apache Tomcat 7 on which i want to have 1 global javascript file (where i put many environment variables into)

Is this doable or are there too many security risks involved?

1) Where do i have to place this file in the Webapps-folder?
2) Which config-file do i need to adapt so all apps from webapps-folder will look at this file?  (somewhere in the WEB-INF folder of every webapp?)

 
Tim Holloway
Bartender
Posts: 18504
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, a web server is not a file server. So you cannot just plunk down files and expect them to behave like they would on a file server.

Web servers serve web applications. A web application is expected to be self-contained, with all of its local resources in its WAR, which according to J2EE and JEE specs is a JAR file, although many servers - including Tomcat - allow the WAR to be unzipped into an equivalent set of directories and files (a so-called "exploded" WAR). The default arrangement in Tomcat is that any directory directly under TOMCAT_HOME/webapps is expected to be the root of a WAR with a corresponding URL context path equal to that directory's name. WARS (and therefore webapps) are all first-class objects - no WAR may contain another WAR either physically or logically.

So, unless you exploit OS-specific hacks, unusual Tomcat settings and other discouraged practices, there are only 2 ways to get multiple webapps to share any static resource.

The first way is brute force, where you simply include a copy of the resource in each WAR that you deploy.

The second way is to create a separate webapp specifically to hold that resource (and possibly other shared resources as well), and code the other webapps to reference the URL path of the resource within that webapp. Of course, since this is a separate webapp, you don't even actually have to use Tomcat to serve up that shared static resource - you could just as easily have an independent high-performance server (such as Apache httpd or Nginx) serve up that resource. This is basically what any webapp that uses something like jQuery does if it references the master jQuery URL instead of copying the jQuery javascript files directly into the webapp that uses them. And, of course, the global jQuery URL is pulling from an external server.

Note that while taking the second approach breaks the self-containedness of a strict J2EE webapp, you gain several advantages by using it. Not only do you have smaller referencing webapps and a one-stop update point for any modifications to that resource, but you can set client caching options so that the user's client keeps a single shared copy instead of making a separate copy for each webapp.
 
Duke Keys
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a very clear answer. Thanks, Tim!
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65764
130
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:The first way is brute force, where you simply include a copy of the resource in each WAR that you deploy.


Not seeing how this is "brute force" (with its negative connotations) -- it's simply sharing at build time rather than at run time. It's the preferred approach taken by most modern client side applications, usually managed by a package manager such as bower or npm.

But here, it does sound like the OP desires run-time sharing (which precludes each application from managing its own dependencies, but that may be just the point here), so the CDN-like approach may be what's needed.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!