Jetty 5.1 Multiple Contexts with 1 war

Discussion in 'Java' started by rpnz, Mar 29, 2010.

  1. rpnz

    rpnz Guest

    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
    rpnz, Mar 29, 2010
    #1
    1. Advertising

  2. rpnz

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Mar 30, 2010
    #2
    1. Advertising

  3. rpnz

    rpnz Guest

    On Mar 30, 12:32 pm, Arne Vajhøj <> 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
    rpnz, Mar 30, 2010
    #3
  4. rpnz

    Lew Guest

    znôrt wrote:
    > On Tue, 30 Mar 2010 23:08:23 +0300, rpnz <> 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
    Lew, Mar 31, 2010
    #4
  5. rpnz

    rpnz Guest

    On Apr 1, 10:54 am, Lew <> wrote:
    > znôrt wrote:
    > > On Tue, 30 Mar 2010 23:08:23 +0300, rpnz <> 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


    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 ?
    rpnz, Apr 7, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Albretch
    Replies:
    0
    Views:
    405
    Albretch
    Aug 5, 2003
  2. newbie29

    Tomcat Many contexts

    newbie29, Apr 25, 2005, in forum: Java
    Replies:
    1
    Views:
    412
    Juha Laiho
    Apr 26, 2005
  3. Tristan
    Replies:
    2
    Views:
    356
    Attila Feher
    Aug 15, 2003
  4. Replies:
    5
    Views:
    311
    Peter Nilsson
    Nov 6, 2007
  5. jstorta
    Replies:
    1
    Views:
    518
    Arne Vajhøj
    Nov 18, 2007
Loading...

Share This Page