dhis2-devs team mailing list archive

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


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

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.
The relative one will have the OS user home as basis.