9:30 a.m.
Jopr (note: *not* JOPR, it is not an abbreviation... the lawyers asked me to say that :)
does indeed have a built-in installer. (Jopr project page here: http://jboss.org/jopr ,
Jopr docs here: http://jopr.org/confluence/display/JOPR2/Home)
It is fairly simple. It DOES upgrade the database schema from the old to the new version
(while keeping existing data intact) but it does NOT update file-system components (like
the JBossAS server files itself, the app .ear, etc.). Here's how it works - I'm
sure a similar design could work in other apps built on top JBossAS:
1) Shutdown any server you currently have running (we will be updating the database
schema, so you shouldn't have any db clients connected to it, including the server
itself)
2) Unzip the new updated binary distribution into a new install directory. If you'd
like, delete the old server install directory and unzip the new updated binary
distribution in the same location.
3) Run the server normally (in Jopr's case, its "rhq-server.bat/sh start")
4) At this point, the "real" Jopr .ear/webapp is not started. Out-of-box after
you unzipped the binary, all but one of the internal app components are NOT deployed
because their files end with ".rej" which tells the JBoss deployer not to deploy
them. So we have a bunch of things in the deploy directory called "rhq.ear.rej",
"rhq-ds-oracle.rej", "rhq-post-installer.war.rej", etc. But the one
thing that IS deployed is an installer war (rhq-installer.war). So when the server starts,
it has a small webapp that is deployed and started. This is the webapp you will hit in the
next step and it "finishes" the Jopr installation.
5) Point browser to the server - http://localhost:7080 - this takes your browser to the
installer webapp.
6) The installer war produces a simple "installer" interface - a bunch of text
fields, radio buttons, etc. you use to customize the startup properties for the Jopr
JBossAS server. The default values are picked up from a rhq-server.properties file which
is passed to the JBossAS server when you started Jopr (it passes the file via the -P
startup command line option). This .properties files is how we configure the Jopr server
startup. The installer merely takes your input, overwrites rhq-server.properties with your
custom values (you enter your own database username, password, JDBC URL, and other Jopr
specific settings and the installer will edit your rhq-server.properties and overlay your
values over top the defaults).
7) Click the "install" button on the installer webpage. This will RENAME all the
"undeployed" files - so "rhq.ear.rej" is renamed "rhq.ear",
one of the datasource files is renamed depending on which database you selected (so if you
told the installer you want oracle, we rename "rhq-ds-oracle.rej" as
"rhq-ds.xml" and the JMS directory "rhq-jms.oracle.rej/" as
"rhq-jms/". If you want postgres, we rename "rhq-ds-postgres.rej" and
"rhq-jms.postgres.rej/" in a similar fashion).
8) We also run through our custom "dbutils" utility to update the database
schema from the old version to the new version. We have schema update rules that we
execute to move you up to the new version, thus maintaining all your old data so it
survives the upgrade. (the installer gives you the option to blow away your data and start
new if you want).
9) In the Jopr ear startup (we have a startup servlet in the ear), we turn around and
rename the installer war "rhq-installer-war.rej" so it is never deployed again.
This is a security feature - we do not want users hitting that installer again and trying
to muck with the installed settings. So the installer is disabled from then on. In its
place, we rename "rhq-postinstaller.war.rej" to
"rhq-postinstaller.war" - this guy's job is simple - anyone attempting to go
to one of our installer's URLs will get redirected to a page that simply says,
"the server is already started, click here for the real Jopr web app".
At this point, your server is started and ready to accept Jopr requests. Note that if you
changed some settings (like the bind address for the JBossAS server) you need to restart
the server because JBossAS cannot easily hot-change its bind address or other things of
that nature.
Here's where the installer Java source and webapp files are if you want to examine the
code:
http://svn.rhq-project.org/repos/rhq/trunk/modules/enterprise/gui/install...
Here's the dbutils code that upgrades the database:
http://svn.rhq-project.org/repos/rhq/trunk/modules/core/dbutils/
----- Original Message -----
From: "Adrian Cole" <adrian(a)jclouds.org>
To: jpai(a)redhat.com, "JBoss.org development list"
<jboss-development(a)lists.jboss.org>
Sent: Tuesday, July 7, 2009 9:53:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [JBoss-dev] Is it possible to create multiplatform installer for java
projects
JOPR is indeed for admin. The problem description was fairly cross-cutting, so I
wouldn't be surprised if JOPR could help the tail end of the process.
Cheers,
-Adrian
On Tue, Jul 7, 2009 at 4:22 PM, Jaikiran Pai < jpai(a)redhat.com > wrote:
Adrian Cole wrote:
I would suggest looking at ControlTier, Cargo, and JOPR projects for starters.
That's interesting, i always thought JOPR was for administering the servers.
Wasn't aware that it could be used as an installer.
-Jaikiran
Cheers,
-Adrian
http://code.google.com/p/jclouds <mailto: adrian(a)jclouds.org >
On Tue, Jul 7, 2009 at 3:39 PM, mr.vikash < vikash.srivastava(a)mctindia.co.in
<mailto: vikash.srivastava(a)mctindia.co.in >> wrote:
Hi,
I am trying to create multiplatform installer for java projects. Main
motive to create this installer are as follows
1. Install the jboss on system.
2. update the configuration information(eg. database information)
submitted
by the user on installer dialoug during installation
process.
3. Read or execute the java class file before installation complete.
4. Start the Jboss services before installation complete
Is any one have any idea, how to create such type of
installer.........
Thx in advance.
Vikash Srivastava