dhis lite

[bobj (Bob Jolliffe)]

I've just committed a (very rough and ready) version of a dhis2-lite,
aimed at being suitable for running on smaller machines with no
tomcat, and no windows service and the beginnings of a user interface.

bzr checkout lp:~dhis2-devs/dhis2/sandbox

DO READ THE README FILE.

Hopefully after more testing we can say with no mysql and postgres as well.

Cheers
Bob

[Lars (Lars Øverland)]

Hey Bob,

this sounds nice. I have contributed some hacking myself:

• Updated versions of jetty and jetty-util in the lite POM to the latest (and existing:) ones in the mvn central repo.

• Regarding the assembly gotcha, I added a dependency to dhis-web-portal in the lite POM. To me it looks as if the portal DHIS 2 WAR file now gets merged into the lite JAR after doing assembly:assembly. Could you have a look and see if its OK? Obviously, this requires you to have the dhis-web-portal project installed in your local m2 repo. Also, it looks as if the WebAppServer is hardcoded to the “webapp” folder, is this something we could avoid now?

• Upgraded to the latest h2 database version in DHIS 2, will test it more regarding production use.

• Could we have a Compiz-enabled 3D animation of the status? Just kidding.

Lars

···

On Fri, Mar 27, 2009 at 6:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I’ve just committed a (very rough and ready) version of a dhis2-lite,

aimed at being suitable for running on smaller machines with no

tomcat, and no windows service and the beginnings of a user interface.

bzr checkout lp:~dhis2-devs/dhis2/sandbox

DO READ THE README FILE.

Hopefully after more testing we can say with no mysql and postgres as well.

Cheers

Bob

[bobj (Bob Jolliffe)]

Hi Lars

Thanks for checking this out. I was wondering if it was in a void ...

Hey Bob,

this sounds nice. I have contributed some hacking myself:

- Updated versions of jetty and jetty-util in the lite POM to the latest
(and existing:) ones in the mvn central repo.

Great thanks. I was only finding ver 6.0.X so I installed in my local
repository. This is better.

- Regarding the assembly gotcha, I added a dependency to dhis-web-portal in
the lite POM. To me it looks as if the portal DHIS 2 WAR file now gets
merged into the lite JAR after doing assembly:assembly. Could you have a
look and see if its OK? Obviously, this requires you to have the
dhis-web-portal project installed in your local m2 repo. Also, it looks as
if the WebAppServer is hardcoded to the "webapp" folder, is this something
we could avoid now?

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.

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

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

Cheers
Bob

···

2009/3/30 Lars Helge Øverland <larshelge@gmail.com>:

Lars

[Lars (Lars Øverland)]

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.

[bobj (Bob Jolliffe)]

Hi

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

···

2009/3/30 Lars Helge Øverland <larshelge@gmail.com>:

[Lars (Lars Øverland)]

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.

Hm sorry you are right, I overlooked the ~ in my connection url. It’s relative to the current working directory, which is actually more useful for us.

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.

Looks sensible.

So what you say is that we set the connection url to something like jdbc:h2:/database/dhis2, keep the hardcoded “webapp” folder in WebAppServer since we can control the folder name, and zip everything into an archive. Then the installation process would simply be to unzip the archive and click the exe jar?

[bobj (Bob Jolliffe)]

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

Hm sorry you are right, I overlooked the ~ in my connection url. It's
relative to the current working directory, which is actually more useful for
us.

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.

Looks sensible.

So what you say is that we set the connection url to something like
jdbc:h2:/database/dhis2,

Or maybe jdbc:h2:./database/dhis2 (see the little dot - to make the
url relative). I think I'd still use a hibernate.properties file,
probably alongside the jar, to allow some flexibility. Still have to
puzzle how best to deal with the DHIS2_HOME env variable. I don't
think Java has a native setEnv() or getCwd() which would have been
useful.

keep the hardcoded "webapp" folder in WebAppServer

slightly different as webapp would now point to directory resource
outside of the jar, but yes, still some hardcoded default.

Alternatively (maybe this is better) have a dhis2config.xml file
inline with the jar ...

since we can control the folder name, and zip everything into an archive.
Then the installation process would simply be to unzip the archive and click
the exe jar?

Pretty much. Unless we want to make shortcuts or program menu items.

···

2009/3/30 Lars Helge Øverland <larshelge@gmail.com>:

[Lars (Lars Øverland)]

Or maybe jdbc:h2:./database/dhis2 (see the little dot - to make the

url relative).

You are right again.

I think I’d still use a hibernate.properties file,

probably alongside the jar, to allow some flexibility. Still have to

puzzle how best to deal with the DHIS2_HOME env variable. I don’t

think Java has a native setEnv() or getCwd() which would have been

useful.

keep the hardcoded “webapp” folder in WebAppServer

slightly different as webapp would now point to directory resource

outside of the jar, but yes, still some hardcoded default.

Alternatively (maybe this is better) have a dhis2config.xml file

inline with the jar …

What do you think about simply reading in the hibernate.properties file with a FileInputStream from the executable JAR? A FileInputStreamwill look in the current folder if you pass just a filename as parameter, something like:

Properties props = new Properties();
props.load( new FileInputStream( “hibernate.properties” ) );

···

[Lars (Lars Øverland)]

Sorry obviously that won’t be enough. DHIS 2 looks for config file in this

order: 1) default properties file in dhis-support-hibernate 2) Classpath in

the WAR 3) DHIS2_HOME env variable, where the last one gets precedence. We

could read in a hibernate.properties file and overwrite a file on the

classpath inside the WAR. But that won’t be extremely elegant. Alternatively

we could modify DHIS 2 to look for a system property dhis2.home and use the

get/setProperty methods.

I think a system property (eg dhis2.home) is an excellent idea - much

prefer them to environment variables. It might also provide some

flexibility for those who are deploying multiple dhis2 applications on

a single server machine as we saw in India. I’m pretty sure we could

then put the properties file in the jar though it seems reasonable to

have the configurable bits outside and easily editable. Though a mixed

blessing I know …

OK. I think we need to keep the environment variable in addition since

• system properties are Java-specific and I guess the only way to set it outside Java is through -D options to the java command line (?) for use with standard databases.

• we would have to update all existing installations if we remove it…

I wonder if we might make a slight improvement to startup time while

we’re at it. Currently it seems the DHIS hibernate sub-system looks

for all those locations before finally deciding to use the latter.

Can we do the search in the reverse order - ie if dhis2.home property

is set, check for hibernate.properties, use that and get straight on

with the rest of the busy tasks of initialisation. On my system that

will shave off 2 or 3 seconds.

A problem with this is that it’s handy to have the files overriding each other as the default properties contains more information than what the “DHIS2_HOME one” usually does, like connection pooling and caching. But we could say that if the DHIS2 system property is set, we could skip looking for the DHIS2 environment variable?

System.getProperty( “user.dir” ) will give you the current working directory.

So we have a hibernate.properties in or inline with the exe jar which looks up its cwr, sets a dhis2.home system property with this value, starts the webapp and lets dhis2 read it in…?

[bobj (Bob Jolliffe)]

Hi

> Sorry obviously that won't be enough. DHIS 2 looks for config file in
> this
> order: 1) default properties file in dhis-support-hibernate 2) Classpath
> in
> the WAR 3) DHIS2_HOME env variable, where the last one gets precedence.
> We
> could read in a hibernate.properties file and overwrite a file on the
> classpath inside the WAR. But that won't be extremely elegant.
> Alternatively
> we could modify DHIS 2 to look for a system property dhis2.home and use
> the
> get/setProperty methods.
>

I think a system property (eg dhis2.home) is an excellent idea - much
prefer them to environment variables. It might also provide some
flexibility for those who are deploying multiple dhis2 applications on
a single server machine as we saw in India. I'm pretty sure we could
then put the properties file in the jar though it seems reasonable to
have the configurable bits outside and easily editable. Though a mixed
blessing I know ...

OK. I think we need to keep the environment variable in addition since

- system properties are Java-specific and I guess the only way to set it
outside Java is through -D options to the java command line (?) for use with
standard databases.
- we would have to update all existing installations if we remove it...

You are right. I wouldn't suggest removing it at all.

I wonder if we might make a slight improvement to startup time while
we're at it. Currently it seems the DHIS hibernate sub-system looks
for all those locations before finally deciding to use the latter.
Can we do the search in the reverse order - ie if dhis2.home property
is set, check for hibernate.properties, use that and get straight on
with the rest of the busy tasks of initialisation. On my system that
will shave off 2 or 3 seconds.

A problem with this is that it's handy to have the files overriding each
other as the default properties contains more information than what the
"DHIS2_HOME one" usually does, like connection pooling and caching. But we
could say that if the DHIS2 system property is set, we could skip looking
for the DHIS2 environment variable?

System.getProperty( "user.dir" ) will give you the current working
directory.

So we have a hibernate.properties in or inline with the exe jar which looks
up its cwr, sets a dhis2.home system property with this value, starts the
webapp and lets dhis2 read it in...?

That sounds like the ticket.

Cheers
bob

···

2009/3/31 Lars Helge Øverland <larshelge@gmail.com>:

[Lars (Lars Øverland)]

That sounds like the ticket.

OK I will work on the webapp side. I’ll look for a hibernate.properties outside the JAR for now if thats ok with you.

[bobj (Bob Jolliffe)]

Hi

> Sorry obviously that won't be enough. DHIS 2 looks for config file in
> this
> order: 1) default properties file in dhis-support-hibernate 2) Classpath
> in
> the WAR 3) DHIS2_HOME env variable, where the last one gets precedence.
> We
> could read in a hibernate.properties file and overwrite a file on the
> classpath inside the WAR. But that won't be extremely elegant.
> Alternatively
> we could modify DHIS 2 to look for a system property dhis2.home and use
> the
> get/setProperty methods.
>

I think a system property (eg dhis2.home) is an excellent idea - much
prefer them to environment variables. It might also provide some
flexibility for those who are deploying multiple dhis2 applications on
a single server machine as we saw in India. I'm pretty sure we could
then put the properties file in the jar though it seems reasonable to
have the configurable bits outside and easily editable. Though a mixed
blessing I know ...

OK. I think we need to keep the environment variable in addition since

- system properties are Java-specific and I guess the only way to set it
outside Java is through -D options to the java command line (?) for use with
standard databases.
- we would have to update all existing installations if we remove it...

I wonder if we might make a slight improvement to startup time while
we're at it. Currently it seems the DHIS hibernate sub-system looks
for all those locations before finally deciding to use the latter.
Can we do the search in the reverse order - ie if dhis2.home property
is set, check for hibernate.properties, use that and get straight on
with the rest of the busy tasks of initialisation. On my system that
will shave off 2 or 3 seconds.

A problem with this is that it's handy to have the files overriding each
other as the default properties contains more information than what the
"DHIS2_HOME one" usually does, like connection pooling and caching. But we
could say that if the DHIS2 system property is set, we could skip looking
for the DHIS2 environment variable?

System.getProperty( "user.dir" ) will give you the current working
directory.

OK. That works! I'm currently still using DHIS2_HOME for finding
hibernate.properties, but I have:
System.setProperty("dhis2.home", System.getProperty("user.dir"));
in the startup code, so the env variable is there for when you can use it.

So we have a hibernate.properties in or inline with the exe jar which looks
up its cwr, sets a dhis2.home system property with this value, starts the
webapp and lets dhis2 read it in...?

I've finally got rid of all the pesky System.err.println() statements
and am using Jetty's Log class. Haven't figured out yet how to tie it
in with the commons logging in the webapp and log to a file (other
than stderr). That's the next challenge ... priority 1.

However it does give me the chance to make some observations on
startup time (with an empty database). Total startup time on my XP
virtual machine is 35s. I'm going to put XP on my little asus for a
realistic low power scenario and will measure again. But particularly
for dhis2-lite it would be good to reduce this.

1. Of this, 10s is being used to unpack the war.
2..About 10s being used since finding final hibernate.properties and
starting startup routine 1
3. About 5 seconds doing startup routine 1
4. About 5 seconds initialising Spring

If we are going to slim down the startup time this is where we should
look. Not much can be done about 4. About 1 I think it will be a
huge improvement (30%) to deploy the exploded war and not let jetty
make a temporary copy. The only benefit of having it do its default
behaviour is to allow for hot (re)deployment which is not a concern
here. I'll work on persuading jetty to oblige. priority 2.

I'm not sure what is going on at 2 yet. Probably not much can be
done about the startup routines either.

I'll aim for a 20-25s startup. Already we are an improvement with no
mysql to start and a much lighter baby-jetty to start than fully
fledged tomcat. And having some visual feedback of the status of the
app on starting up is already useful. Can make this even more user
friendly in time.

Cheers
Bob

···

2009/3/31 Lars Helge Øverland <larshelge@gmail.com>:

[Knut_Staring]

Can’t you just not use a war?

Knut

···

2009/4/1 Bob Jolliffe bobjolliffe@gmail.com

However it does give me the chance to make some observations on

startup time (with an empty database). Total startup time on my XP

virtual machine is 35s. I’m going to put XP on my little asus for a

realistic low power scenario and will measure again. But particularly

for dhis2-lite it would be good to reduce this.

1. Of this, 10s is being used to unpack the war.

[bobj (Bob Jolliffe)]

However it does give me the chance to make some observations on
startup time (with an empty database). Total startup time on my XP
virtual machine is 35s. I'm going to put XP on my little asus for a
realistic low power scenario and will measure again. But particularly
for dhis2-lite it would be good to reduce this.

1. Of this, 10s is being used to unpack the war.

Can't you just not use a war?

Yes that is the plan. Shame in a way coz its convenient to just drop
in the war. But adding 30% to startup is too much to pay ..

···

2009/4/1 Knut Staring <knutst@gmail.com>:

2009/4/1 Bob Jolliffe <bobjolliffe@gmail.com>

Knut

[bobj (Bob Jolliffe)]

Cool. startup now betwen 19 and 25 seconds total. And using 65M Ram.

···

2009/4/1 Bob Jolliffe <bobjolliffe@gmail.com>:

2009/4/1 Knut Staring <knutst@gmail.com>:

2009/4/1 Bob Jolliffe <bobjolliffe@gmail.com>

However it does give me the chance to make some observations on
startup time (with an empty database). Total startup time on my XP
virtual machine is 35s. I'm going to put XP on my little asus for a
realistic low power scenario and will measure again. But particularly
for dhis2-lite it would be good to reduce this.

1. Of this, 10s is being used to unpack the war.

Can't you just not use a war?

Yes that is the plan. Shame in a way coz its convenient to just drop
in the war. But adding 30% to startup is too much to pay ..

Knut

[Lars (Lars Øverland)]

I’ve finally got rid of all the pesky System.err.println() statements

and am using Jetty’s Log class. Haven’t figured out yet how to tie it

in with the commons logging in the webapp and log to a file (other

than stderr). That’s the next challenge … priority 1.

I have changed the logging to how its done in DHIS 2. Might help, if you don’t like it go ahead and revert it.

Copying in some contents for a log4j properties file that works at least for DHIS 2, have a look if you like, simply change rootcategory from console to file:

···

---

Log to file setup

log4j.appender.file = org.apache.log4j.RollingFileAppender
log4j.appender.file.File = dhis.log
log4j.appender.file.MaxFileSize = 100KB
log4j.appender.file.MaxBackupIndex = 3

log4j.appender.file.layout = org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern = * %-5p %d{ABSOLUTE} %m (%F [%t])%n

Log to console setup

log4j.appender.console = org.apache.log4j.ConsoleAppender

log4j.appender.console.layout = org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern = * %-5p %d{ABSOLUTE} %m (%F [%t])%n

Categories (order: DEBUG, INFO, WARN, ERROR, FATAL)

log4j.rootCategory = WARN, console

log4j.category.org.hisp.dhis = INFO

[bobj (Bob Jolliffe)]

Looks good. Will take a proper look later. Got distracted with
making animated gifs in gimp ...

Cheers
Bob

···

2009/4/1 Lars Helge Øverland <larshelge@gmail.com>:

I've finally got rid of all the pesky System.err.println() statements
and am using Jetty's Log class. Haven't figured out yet how to tie it
in with the commons logging in the webapp and log to a file (other
than stderr). That's the next challenge ... priority 1.

I have changed the logging to how its done in DHIS 2. Might help, if you
don't like it go ahead and revert it.

Copying in some contents for a log4j properties file that works at least for
DHIS 2, have a look if you like, simply change rootcategory from console to
file:

-------------

# Log to file setup
log4j.appender.file = org.apache.log4j.RollingFileAppender
log4j.appender.file.File = dhis.log
log4j.appender.file.MaxFileSize = 100KB
log4j.appender.file.MaxBackupIndex = 3
log4j.appender.file.layout = org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern = * %-5p %d{ABSOLUTE} %m (%F
[%t])%n

# Log to console setup
log4j.appender.console = org.apache.log4j.ConsoleAppender
log4j.appender.console.layout = org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern = * %-5p %d{ABSOLUTE} %m (%F
[%t])%n

# Categories (order: DEBUG, INFO, WARN, ERROR, FATAL)
log4j.rootCategory = WARN, console
log4j.category.org.hisp.dhis = INFO
-----------------

[Lars (Lars Øverland)]

Haha.

···

2009/4/1 Bob Jolliffe bobjolliffe@gmail.com

Looks good. Will take a proper look later. Got distracted with

making animated gifs in gimp …

[Lars (Lars Øverland)]

I have committed a change that makes DHIS 2 to look for a system property “dhis2.home” if the environment variable “DHIS2_HOME” is not set. This should work with the executable jar…

[bobj (Bob Jolliffe)]

Great. Works like a charm. Specially on Windoze. The application is
now self referencing - just double click on the executable jar (or a
shortcut to it) and it figures out the rest from there. (Knut: In
fact it will work really well off a usb stick - no setup required).

A bit weird on linux. If you double click on the jar from gnome, the
system property (user.dir) is set to the users home directory which is
a bit annoying. Works fine if you start from the command shell in the
right directory. There is another (more convoluted) way to get at the
URL of the containing directory of the jar other than through user.dir
system property: get a reference to any resource in the jar and then
unpick the directory from that. I'm not going to bother for the moment
as I'm pretty sure 99% of the target market at the moment is Windoze,
but should fix later.

Cheers
Bob

PS. can we make it look for dhis2.home regardless of whether
DHIS2_HOME is set or not - and take precedence? Otherwise I have to
unset DHIS2_HOME. There will be no effect on applications which do
not set the dhis2.home property.

···

2009/4/2 Lars Helge Øverland <larshelge@gmail.com>:

I have committed a change that makes DHIS 2 to look for a system property
"dhis2.home" if the environment variable "DHIS2_HOME" is not set. This
should work with the executable jar...