Prev: trustAnchors parameter must be non-empty
Next: Splash screen
From: rpnz on 29 Mar 2010 17:58
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
From: Arne Vajhøj on 29 Mar 2010 20:32
On 29-03-2010 17:58, rpnz wrote:
> 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
From: rpnz on 30 Mar 2010 16:08
On Mar 30, 12:32 pm, Arne Vajhøj <a...(a)vajhoej.dk> wrote:
> On 29-03-2010 17:58, rpnz wrote:
>
> > 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

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

From: znôrt on 31 Mar 2010 09:51
On Tue, 30 Mar 2010 23:08:23 +0300, rpnz <rajpnz(a)gmail.com> wrote:

> 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.

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.
From: Lew on 31 Mar 2010 18:54
znôrt wrote:
> On Tue, 30 Mar 2010 23:08:23 +0300, rpnz <rajpnz(a)gmail.com> wrote:
>
>> 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.
>
> 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.

--
Lew
 |  Next  |  Last
Pages: 1 2
Prev: trustAnchors parameter must be non-empty
Next: Splash screen