Jetty 5.1 Multiple Contexts with 1 war

[rpnz]

Hi,
We are using jetty 5.1 and need to run multiple contexts off 1 war.
What is the best 1 to do this.
We want to be able to use a ServletContextListener to load an ini file
and connect to the appropriate database, and
do client specific initialization.


Thanks in advance

 

[Arne Vajhøj]

We are using jetty 5.1 and need to run multiple contexts off 1 war.
What is the best 1 to do this.
We want to be able to use a ServletContextListener to load an ini file
and connect to the appropriate database, and
do client specific initialization.

Usually it is 1 war = 1 context.

Why not copy the same war to multiple copies with different names?

Arne

 

[rpnz]

Usually it is 1 war = 1 context.

Why not copy the same war to multiple copies with different names?

Arne

We supply library software to schools and usually each school gets an
installation of jetty and 1 war = 1 context.
The war is NOT unpacked.
But in this case we have a group of schools that are administered by 1
organisation and they want to have all their schools running on the
same web server.
My first thought was to add several entries in the jetty.xml file
pointing to the same war file but with different contexts.
<Call name="addWebApplication">
<Arg>/OneContext</Arg>
<Arg>path_to_war</Arg>
</Call>
<Call name="addWebApplication">
<Arg>/TwoContext</Arg>
<Arg>path_to_war</Arg>
</Call>

But alternatively we could copy the war and rename it.
Our biggest concern is to how each war will read a unique ini file for
that school.
In tomcat I could add a context.xml file for each context, and then
get these initial parameters in the ServletContextListener i.e
<Context path="/OneContext" docBase="path_to_war" >

<Parameter name="inifile" value="path_to_ini_file"
override="false"/>

</Context>

Raj

 

[Lew]

I faced the same issue years ago (jboss 3 with tomcat) and solved it
that way. May be not so elegant, but I found it straightforward and
preferable to having to mess around with sepcific appserver deployment
specs (always a somewhat obscure topic). Just duplicate/rename not just
the war, but also the application name, unique (i.e., not shareable)
services, data sources if need be, etc. You can easily add this step to
your release build script which wil produce, say, 5 wars instead of one
(plus one with shareable stuff, maybe) from one single source, and
forget about it. Of course, you will have to adapt whatever clients to
have them look for the appropiate context or service, but it's my guess
that you would want to do that anyway.

Thinking outside the box, you could put an Apache Web Server (httpd) front end
on that puppy, and use its reverse-proxy capabilities to serve up different
apps under the ostensibly same context name.

I forget the details, but we did something like this at a project I was on a
few years ago. The different clients were "Developer", "Tester" and
"Customer" (or equivalent), each with its own version of the application, but
the reverse proxy gave all three a consistent way to access their individual
versions.

 

[rpnz]

Thinking outside the box, you could put an Apache Web Server (httpd) front end
on that puppy, and use its reverse-proxy capabilities to serve up different
apps under the ostensibly same context name.

I forget the details, but we did something like this at a project I was on a
few years ago.  The different clients were "Developer", "Tester" and
"Customer" (or equivalent), each with its own version of the application, but
the reverse proxy gave all three a consistent way to access their individual
versions.

Thought I found a solution using webdefault.xml as the
defaultsDescriptor, and then creating some context parameters.
Only problem is that images are not showing up on the web app. The
request log states a 404 when requesting the image. ie

127.0.0.1 - - [07/Apr/2010:11:16:22 +1200] "GET /ais/gfx/menubtn/
MenuBtn_advanced.png HTTP/1.1" 404 0

Any ideas ?