Adrian Cole wrote: That's interesting, i always thought JOPR was for administering the servers. Wasn't aware that it could be used as an installer. -Jaikiran

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&gt; To: jpai(a)redhat.com, "JBoss.org development list" <jboss-development(a)lists.jboss.org&gt; 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

Jaikiran Pai wrote: Make sure you look at updates as well. The worse devil can be there. We have started an appliance configuration tool for thincrust (www.thincrust.org) which is puppet driven. It is not a slam dunk for you, but it may provide some ideas around recipe driven installation. Also.. look at how tools like install shield, bitrock, and others approach the problem. It tends to be a combination of built in tools + custom scripts which can be driven by cli, windows, text ui, and rpm/deb/package_manager_of_choice. -- bk

We use IzPack http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html... -thomas On 07/07/2009 02:39 PM, mr.vikash wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss, a division of Red Hat 2009 Red Hat Summit and JBoss World. Chicago. September 1-4, 2009. http://www.redhat.com/summit http://www.jbossworld.com xxxxxxxxxxxxxxxxxxxxxxxxxxxx