1 Reply Latest reply on Feb 18, 2003 9:24 AM by garu

    Start and config patch

    garu

      Hi all,
      I work for a large account and I'm evaluating the possibility to introduce Jboss for our internal applications.
      To help us managing Jboss installations I'd need some little changes in its startup behaviour, so to obtain something similar (slightly better) to what I already do with BEA and Tomcat.

      Here's what I need:
      We have many applications logically divided in groups and for each group we need a different server run via a different unix user that must not have write permission to the location where Jboss is installed, but in the same time many of them use common base libraries and helper applications, so to avoid having the nightmare of carrying around copies of Jboss libraries and application libraries and ear's and war's I'd like to factorize anything common in a single place and in the same time keep at minimum the configuration effort.

      To obtain this, I thought to introduce (or reintroduce?) the concept of Jboss distribution, i.e. what is obtainded unpacking the downloaded zip file or building the source and containing all the necessary to startup a base server, and that of Jboss application server environment that would need to contain only the deploy, conf, db, log and tmp directories. The lib dir would be needed only if this application server uses some specialized libraries that cannot or must not be factorized in a common place.

      Whit this in mind I wrote a small patch that corrects/add the following things:
      · In Main the line command options are processed as first action. This allows to set any System.property, comprised jboss.home.dir and jboss.home.url from a property file. As a side effect this allows to start Jboss using run(.bat/.sh) from a distribution installation bin dir, without the need to have it in the jboss.home.dir.
      · Few new System properties related to Jboss distribution installation are introduced, in particular jboss.dist.home.dir and jboss.dist.home.url that can refere to read only Jboss installation. If none ot these are initialized, nothing changes. If initialized, the content of jboss.dist.home.url is used as base to create jboss.dist.lib.url property. So the boot libraries are looked for in the order from jboss.lib.url (if the directory exists) and jboss.dist.lib.url (nstallation dir)..
      This means that if jboss.dist.lib.url contains a valid URL pointing to jboss distribution lib dir, boot libraries and extra libraries are searched from jboss.lib.url and jboss.dist.lib.url in this order, so there is no more the need to have lib directory into jboss.home.dir and lib directory can be referred in a unique read only place from any number of servers.
      · SARDeployer now uses an ArrayList to hold the classpaths built from elements into service.xml files (in particular for jboss-service.xml run to complete the boot phase). This means that if multiple elements are present they are kept in the order they are written and you can create a hierarchical lib urls chain that allows for class override.
      · SARDeployer now allows property substitution for codebase and archives attributes of element much the same way that URLDeploymentScanner does for deploy URLs. This allows to keep most of all the absolute location references into a single property file.
      · As a side effect of the last two points if you have configured jboss.dist.home and jboss.server.dist.name to point to a valid distribution server model and you add a last classpath line of the form:

      you can omit the lib directory from within your jboss.server.home.dir. This means that many servers can refer to a single read only place for their server lib directory.
      · Again if you specify a first line like ${jboss.server.dist.home.url}deploy for of you can factorize anything common system level that needs to be deployed during the boot phase in a single read only distribution deploy dir different from single server deploy directory.

      DISCLAIMER:
      I have written the patch against the 3.0.6 source code and since to help the coding I have imported the source into a cvs repository in my notebook, all the Revision numbers into the source files were screwed up. I added a comment line in which I annotated the Revision number of the each source file on which the patch apply. Obviously the lines dealing with the comments containing revision numbers must removed from the patch.
      The patch file is the complete output from cvs diff.

      I tested the changes only on the jetty version and for sure not exaustively but the changes are so light I don’t think they should have obscure side effects.
      I hope I didn't overlooked anything, since I'm still fighting with burocracy to find a way to buy the doc, and I had to peek around in the source to understand how things were going on, and for sure I just scratched the surface of the thing.
      What I have attempted is to draw a clear line between what is to be considered system level and what is user level, thing that anybody that has experience in managing systems and applications in large acconts knows helps a lot his work.


      Confused enough? If yes I think it depends mostly on my bad english, but if you look at the patch (there are really few lines of code) anything should look cristal clear to you.

      I really hope you will adopt the patch since this would help a lot the effort of introducing Jboss into this account and reading the forums I think it could help others that have problems similar to mine.

      And, please... don't shot the pianist.

      Regards, Gabriele.


      (It looks the attach files function is a bit in loop, i post but i'm not sure the file is really attached...)