dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

2009/3/30 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>> This looks good.  I was playing with having the war in
>> /src/main/resources but it ended up getting copied in twice leading to
>> a 65M jar!  This seems to work better and follow the "maven way".  I'm
>> still in 2 minds whether I like the 33M executable jar, but more
>> thoughts below.  The webappserver has to locate the root of its webapp
>> somewhere.  I had put it up a directory to get it out of the root
>> directory of the jar.  I can easily put it back in root though will
>> have to give some thought to the implications regarding what jetty
>> might surprizingly serve up as a result.  But I suspect its ok.
>> Jettys going to look up a directory in WEB-INF anyway.  Will test it
>> right now.
>
> Sure.

OK (i) it doesn't work not having a directory (like eg webapp) and
(ii) its maybe not a great idea:

(i) The call to WebAppServer.class.getResource("/"), slightly
surprisingly for me, returns null whereas a call to
WebAppServer.class.getResource("/webapp/") succeeds.  I've tried every
permutation of dots and double dots etc etc  It just doesn't like it.
(ii) if the call were to succeed then (according to the servlet 2.5
specification) the server will attempt to serve up all the files
within that "/" directory which might include things which shouldn't
be exposed.

So if we are to package the webapp within the jar we must put it in a
directory within it.  Which of course is trivial to do but it is not
the default behaviour of the maven assembly plugin. (I could do a
Makefile in a jiffy :-) ).  I seem to remember the assembly plugin may
have some renaming options - I'll check it out.

>>
>>
>> >
>> > - Upgraded to the latest h2 database version in DHIS 2, will test it
>> > more
>> > regarding production use.
>>
>> Good.  I was going to suggest this.
>>
>> >
>> > - Could we have a Compiz-enabled 3D animation of the status? Just
>> > kidding.
>>
>> Kidding aside, I'm not too worried about the gnome stuff at all - I
>> suspect we are really targeting the windoze platforms with this.
>> Still its nice to be cross platform.  Haven't tested on KDE.
>
> OK.
>
>>
>> Some thoughts:
>> 1.  there seems no escape from having a directory configured
>> (DHIS2_HOME) for holding (a) hibernate.properties and (b) the database
>> (assuming use of H2 or javaDB).  OK we might not need
>> hibernate.properties if we change the default configuration from
>> current in-memory to file based.  But we need to have some reference
>> for where the db will be stored.
>>
>> 2.  I've been playing a bit with the idea of storing the db right back
>> in the jar again, but I'm not really sure if this makes a great deal
>> of sense.  Would require an executable self-mutating jar which is
>> probably possible and might even make sense for small db's, but I
>> think it becomes a security nitemare.
>> 3.  Given that we then require an external directory to hold some
>> state (including log files) I come back to thinking it is best to
>> place the dhis.war in there rather than bundle inside the executable
>> jar.  But for the moment we at least do know that it can be done which
>> is something :-)
>
>
> To me it sounds very acceptable to define the DHIS environment variable.
> Would it be an alternative simply to put the database file in the same
> directory as the executable JAR?

Its possible - maybe even better. Though I would love to avoid the env
variable if possible.  Its greek for non-savvy users and brings us
back to requiring an installer.  Though we probably need one anyway to
get icons onto the desktop, program menu etc.  :-(

>
> If I don't remember wrong the database file location can be defined directly
> in the connection url property both as an absolute and relative path/url.

This should be true.

> The relative one will have the OS user home as basis.

This I don't know.  Unless the URL has a '~' then might it not be
relative to the current working directory instead?  This I can check.
I think the location of the db is important enough - to enable backups
etc - that we want to be very sure where it is actually created.

If it is to be a directory fixed by either DHIS2_HOME or the CWD
(which would be nicer) then I will suggest a layout like:

<base_dir> -- dhis2-lite.jar
                 -- database
                       |
                       --- database files
                 -- webapp
                       |
                       --- dhis.war
                 -- log
                       |
                       --- log files

Of course we can keep battling to get the war into the jar in the
right place, but it is maybe of dubious value.

Cheers for now,
Bob

Cheers
Bob

>
>
>