Can I having the server-directory somewhere else?

[1]

Hi,

I just installed jboss 4.0.0 for developing and testing. As far as I understand all configurations are in the server-subdirectory all other directories will not be touched by the application developer.

So I want to modify my installation in that way, that I have the jboss directory (without the server-subdirectory) somewhere centralized and readonly on my computer. The sever directory I want to have where I do my development, and this can be on multiple locations for several projects.

I will never have jboss running more than once on a machine, but how do I tell him on startup, which of those many server-directories he should take. Are there any environmentvariables which I need to set?

My machine runs WindowsNT/2000/XP.

Regards
Thomas

[raja05]

You can set the jboss.server.home (not sure of this variable name, check the startup logs to double check) when you start jboss to a different directory. This would then serve as your server home directory which by default is <JBOSS_DIST>/server.

[1]

Thank you. In the meanwhile I found out, that most of jboss is in the server-subdirectory, so there does not seem to be a distinction between the parts that come with the server and what the developer contributes. Many files like jboss-j2ee.jar I find three times. I expected them in some central directory instead and only the configuration files and developer contributed parts in a separate directory tree.

So when I split jboss like I wanted, I have to copy 80% anyway...

I installed quite a few software in the past, but jboss seems to me a little bit disorganized. I wonder wether it is easily possible to exchange jboss against a newer version. I thought I just unzip a new version, change JBOSS_HOME and then test it against my project. But this seems not to be possible, because you have to change the project file by file.

Maybe I find another way to achieve this goal without modifying the projects conf-files but by only changing one or to global vars.

Regards
Thomas

[raja05]

Not sure if i really understand your whole needs but if you want to split out the files that the developer codes Vs. the files that JBoss provides, you can provide a different deploy directory where you can have the developer related EAR/SAR/JAR/WARs. Take a look at the jboss-service.xml in the conf folder where you can specify this. This lets you switch between multiple versions of JBoss with a single change to the jboss-service.xml that says where to find the deployable entries.
As to why jboss-j2ee.jar is deployed three times, i believe there are 3 different configurations that come by default with jboss - default, all and minimal. You can delete any of them, they are just examples so you could start out with. So in reality, for our deployments, we have a custom server directory where we have componetns and jars that we need and remove the rest .

[1]

"raja05" wrote:
Not sure if i really understand your whole needs but ...

I can imagine that. See "Background" at the end.

"raja05" wrote:
As to why jboss-j2ee.jar is deployed three times, i believe there are 3 different configurations that come by default with jboss - default, all and minimal. You can delete any of them, they are just examples ...

Though those are only three example configurations they illustrate very nicely the problem. JBoss does not distinguish between its configuration files and the application files but it stores them at the same place. I would expect those jar-files at a more central place in the directory-tree so that all configurations could make use of them if necessary. When coding java they have a word for something like this: reuse.

I show you how I expected the directory-layout to be, it is not very different:

1: /jboss/bin
2: /jboss/docs
3: /jboss/client
4: /jboss/server
5: /jboss/lib
6: /jboss/conf

1,2,3,5, stay the way they are.
4: contains all those files you find now in /jboss/server//lib/
6: contains all you find in one of the current conf-directorys except that the lib-subdirectory is empty. This is for files the user will add.

After that, there will be still duplicated files in /jboss/client and /jboss/server and maybe /jboss/lib would be a better place for them.

This leads to the following advantages:

1. The /jboss/conf only contains those files, which are expected to be changed by the user and its size will be in the range of kilobytes and much easier to oversee, esp. for beginners.

2. All other directories only contain those files, which will not be changed by the user.

3. The distribution-zip-file of JBoss is much smaller (about 1/3).

4. The configuration and deployment directories must not be under /jboss as long as you tell jboss at startup, where he finds them.

/jboss/bin/run -c /my/conf

This has the advantage, that you can easily replace jboss by a newer version without removing the old one and without moving the configurations: Just install the new jboss into a new direcory and start it:

/newjboss/bin/run -c /my/conf

Or just start jboss with another project you are developing:

/jboss/bin/run -c /my/other/conf

I wonder wether this is already possible by just moving the files of jboss. After your help, I will try this out next. Thanks again.

Background:
Why did I come accross that topic?

I am maintainig a little personal project called BlueHat, which collects free software for Windows. The software must fullfill the following requirements:

1. it must install in a single directory.
2. it must not do any changes to the registry or at least must not depend on them.
3. if you plain copy the applications directory to another machine, it must run there out of the box.
4. it must not store its configuration in the applications directory. It should honor HOME or its own environment variable for finding its configuration.
5. they must feel home on Windows (no cygwin)

Meanwhile I have collected about 1GB or more of software which resides in one directory tree and is only bound together by environment variables. It is used from a shell like 4NT.

When I start the shell, it determines its location and then sets all the environment variables for all applications relative to this path. This makes it possible to put all of this onto a DVD and it runs out of the box, no matter what drive letter the dvd-drive has. So when I have to use a new computer I can easily take all my software with me by only copying the BlueHat-directory. Doing this with setup-routines would take me days. This even works over a network with several users on different machines using it.

But BlueHat is only for command line junkies and it mostly contains development tools like java, perl, python, ruby, Apache, PHP, MySQL, Firefox, Thunderbird, XEmacs, Eclipse and a lot more.

e.g. WAMP (Windows/Apache/Mysql/PHP):

A simple script generates a directory tree with all configurations just where you type it and within 2 seconds you can start developing another WAMP-project on a running system. The applications are not copied.

Another advantage is: You can have several versions of the same software and can switch between them just by one command.

Normally before I start working with a new piece of software - like JBoss - I try integrating it into BlueHat. With Software, which comes from the Unix or Java-world, this almost ever works very well.


Regards
Thomas

[darranl]

Though those are only three example configurations they illustrate very nicely the problem. JBoss does not distinguish between its configuration files and the application files but it stores them at the same place.

There is actually a reason for JBoss being organised in this way, it isn't random or 'a little bit disorganized'.

The JBoss server is based on a JMX microkernel so the files contained in the folders within the top level JBoss home folder are the files required just to get the JBoss microkernel started. On its own this really just gives the opportunity to deploy additonal services to add further functionalty to the server. There is no need to add all of the jars at this level that are used to provide J2EE functionality as this is not required for the JMX side of things.

Although the folders contained in the server folder are referred to as configuration file sets they contain the libraries that are referred to by the configuration files. If a configuration file is added to define EJB functionality the jar files are added at this level as that is where they are required.

As Raja said the redeundant configurations can be removed if you require. If you has decided that all you needed was the functionality provided by the minimal configuration you can remove the other 2 or 3 configurations and you will have also removed all of the jars that you do not require, if these jars were moved up to the top level then they would still be part of the installation even though they are not required.

If anything it may be appropriate to split up the client folder for the different configurations so that a client can easily see the jars required to make use of a specific configuration.

JBoss does already give the developer the possibility to use a different deploy folder for the components that they are providing, you can configure the deployment scanner to search other folders so you can keep your files seperate from the JBoss deployment files.

[1]

Yes, I see the point, but what you cannot do is this

[conf and deploy on computer a] -uses-> [jboss distribution files on computer x] <-uses- [totally different conf and different deploy on computer b]

except you copy most of jboss.

You come from the point of view of a production server, and there it really does not matter how the layout of the directories are, though for an update to a newer version you will have more to do then necessary. I come from the point of view of a service provider who wants to provide the users jboss in a single directory which I maintain and where the users decide where they want to put their configurations and how many they want to have.

e.g. my database server does not store its configurations and databases in the same directory tree where itself resides, which makes it very simple to replace it to a newer version without moving around the datadirectory or the serverdirectory at all. I just stop the old one and then start the new one. Try this with jboss without moving a single file.

Regards
Thomas