[Gabriele Garuglieri]

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.

With 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 <classpath> elements into
service.xml files (in particular for jboss-service.xml
run to complete the boot phase). This means that if
multiple <classpath> 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 <classpath> 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:
<classpath codebase="${jboss.server.dist.lib.url}"
archives="*"/>
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 <attribute
name="URLs"> of <mbean
code="org.jboss.deployment.scanner.URLDeploymentScanner"
name="jboss.deployment:type=DeploymentScanner,flavor=URL">
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 accounts
knows helps a lot his work.

Logged In: YES
user_id=175228

And where is the patch file?

• assigned_to: nobody --> starksm

Logged In: YES
user_id=716444

Well, may be it's my dummy head or may be Mozilla has a
problem when attaching files. It's the second time that
happens it says it has attched a file while it was not true.
(And i didn't recheck... does it look so evident i'm trying
to justify myself?)
Sorry for any inconvenience, i hope now it's ok.
Gabriele.

Logged In: YES
user_id=716444

Pls, any news?
I'm waiting to know if you will accept this patch to setup
jboss production environments.
Thanks, Gabriele.

• status: open --> open-accepted

Logged In: YES
user_id=175228

I'm evaluating the changes for integration in the next
release. I'm not sure if they will make it into the 3.2.0
release, but something similar should make it into 3.0.7 and
3.2.1 after more testing.