dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/4/7 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> On Tue, Apr 7, 2009 at 11:01 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> Just another thought.
>>
>> DHIS2 is now also configured to pick up a system property (dhis2.home)
>> in the absence of a DHIS2_HOME environment variable.  Lars added this
>> feature so that I can deploy dhis2-lite without getting users to
>> fiddle with environment variables.
>>
>> If you are deploying multiple instances of dhis2 it would be much
>> tidier to handcraft a context for each one in context.xml, in which
>> you set a dhis2.home context parameter appropriately.  As well as
>> other useful goodies like the webapp path.  Then you don't have to go
>> poking around at the hibernate.properties inside the jar files which
>> is pretty ugly.  Mind you I don't think DHIS2 is currently configured
>> to look for context parameters but it is probably a simple
>> modification.
>>
>> Another side effect of this approach might be that you actually only
>> need to deploy one war, and the individual contexts would each specify
>> that war together with a unique path.  Something like (dreaming out
>> loud):
>>
>> <Context path="/state1" docBase="dhis2.war">
>>  <Parameter name="dhis2.home" value="/etc/dhis2/state1" />
>> </Context>
>> <Context path="/state2" docBase="dhis2.war">
>>  <Parameter name="dhis2.home" value="/etc/dhis2/state2" />
>> </Context>
>> <Context path="/state3" docBase="dhis2.war">
>>  <Parameter name="dhis2.home" value="/etc/dhis2/state3" />
>> </Context>
>>
>> Or maybe even (taking a slightly different approach):
>>
>> <Context path="/state1" docBase="dhis2.war">
>>  <Environment name="dhis2.home" value="/etc/dhis2/state1"
>> type="java.lang.String" />
>> </Context>
>> <Context path="/state2" docBase="dhis2.war">
>>  <Environment name="dhis2.home" value="/etc/dhis2/state2"
>> type="java.lang.String" />
>> </Context>
>> <Context path="/state3" docBase="dhis2.war">
>>  <Environment name="dhis2.home" value="/etc/dhis2/state3"
>> type="java.lang.String" />
>> </Context>
>>
>> In this latter case the application should be able to pick up the values
>> with:
>> try
>> {
>>  InitialContext context = new InitialContext();
>>  Object valueO = context.lookup("java:comp/env/dhis2.home");
>> }
>> catch(javax.naming.NamingException ne)
>> { /* handle gracefully */ }
>>
>> Just a thought.
>>
>> Meanwhile proceed with what you are doing.  I think it should work.
>>
>> Cheers
>> Bob
>>
>>
>> 2009/4/7 Bob Jolliffe <bobjolliffe@xxxxxxxxx>:
>> > Knut is correct.  This should work.  I'm really interested to hear.
>> >
>> > BTW on tomcat I believe you should be putting the other jars in
>> > shared/lib.  Good luck.
>> >
>> > Cheers
>> > Bob
>> >
>
> These are really good ideas. Will try to think of a way to automate this
> separation.
>

I suspect this is a bit of a fringe case - I don't know too many folk
who might want to run 11 dhis instances on one server.  But you never
know ...

Personally I like idea of being able to run identical wars for each
instance (rather than poking around the embedded hibernate
properties).  In a really large setup - like they might end up having
in India - it might then be possible to imagine a pool of application
servers (glassfish or tomcat) and a pool of contexts.  Contexts could
then be migrated fairly seemlessly and transparently between the
servers to optimize load balancing.

Of course this would be dependent on the web portal initialisation
picking up a context parameter and passing this on to hibernate in its
initialisation.  I'll have a look at how this can be done.  I know you
would do it quicker, but its a good exercise for me.

Tailoring DHIS2 for scalability from the lite to the massive ... :-)