dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 5 March 2010 16:17, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
>
>>
>> It may be that PG does not need a specific account if we just copy the
>> files and don't make it a service (don't remember).
>
> Postgres must be run as a user that does not have administrative privileges.
> This does not have to be the user that is logged in, but it does need to be
> a user.
>
>
>>
>>
>>>
>>> I think the real problem is the conflict-with-existing-installations one.
>>> Can we install it with a specific service name and on a specific port? And
>>> could it then co-exist with other postgres services?
>>
>> Yes - we have actually had this for years - in a long series of
>> installers...e.g. Ola has experience using the previous BitRock installer
>> without problems in Tanzania.
>
>
> This should not a big deal. It is easy to create either a random user name
> or one that is unlikely to conflict with an existing one.
> As i mentioned, the postgres installer that is packaged within the installer
> that I have been working on, is intelligent enough not to choose a port that
> is already in use. I already had postgres installed, and it changed the port
> automatically to 5433. What I have not had time to do yet, is write this to
> the hibernate.properties file, but I am saving that for the next flight to
> Dushanbe in a few hours.
>
>
> Bob, what do you think about that configuration file that the installer
> could write, to let the Live app know which JRE to use?

Hi Jason - sorry I'm half following this discussion while working on
something else.  Trying to pay attention :-)

I'll have to look at this, but as far as I can tell (and I'm not
really the world's java expert) you can't really tell the java source
code to pick which jre it wants to use.  Kind of like the adage about
children not being able to pick their parents.  By the time that code
is running its kind of too late.  I guess the only thing which can be
done (and maybe this is what you mean) is to change settings in the
launch4j config file.  But again this can't really be done at install
time ..... unless of course the launch4j packaging of the "exe" is
actually done as an install step.  I guess this might be possible but
it starts to get hairy.  Off the top of my head:
1.  launch4j would need to be bundled in the installer package by bitrock
2.  bitrock would need to be clever enough to modify launch4j config file
3.  bitrock would need to install launch4j and jre
4.  bitrock would need to run launch4j (with which jre? ca't remember
offhand but I think you need a jre) to generate the dhis2-live.exe as
a post-install step
5.  bitrock can now remove launch4j as a subsequent postinstall step.

I'm trying to understand again why we want to do this.  If we are
indeed bundling a jre then can't we set that jre as the one to be used
as part of the build process of dhis2-live.exe?  Someone remind me why
we want to do this at install time?

Regards
Bob

> Regards,
> Jason
>
>
>
>>
>>
>> Knut
>>>
>>>
>>>>
>>>> I must say though, I am still a bit confused why we are not considering
>>>> the H2 approach more? I have an installer already for this, and it works
>>>> like a charm, at least on a stock XP machine.
>
> I still think that for a typical district install, H2 should suffice. I
> hope. We need to test it, as there are some definite advantages.
>>>
>>> Well its a good point. I can only say that postgres is more proven, more
>>> people have knowledge about it, it provides better supportive applications
>>> (pgadmin), and I have experienced problems with importing large amounts of
>>> data with H2. But H2 is improving and we will definitely have "full H2
>>> compliance" as a goal.
>>>
>>>>
>>>> I have taken a look at .embedding the JRE which is simple, but it would
>>>> require a change to the DHIS2 Live app, which of course would break other
>>>> DHIS2 live installs that may not use the embedded JRE that we would package
>>>> with the installer. We could alter the Live app source code at the builder
>>>> compile time, to suit the needs of the installer. Better yet, would be a
>>>> config file for the app that we could write during the installation, which
>>>> could read the JRE location. Maybe we could use this for other properties,
>>>> like memory settings as well.
>>>>
>>>
>>> Yeah I'm sure we (Bob?) could do some magic here and the JRE is only 15
>>> mb. So I'll say we go for it.
>>> Lars
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>
>
>
> --
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+260968395190
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>