configuring JBoss with a script

[michaill]

What is the recommended way of configuring JBoss resources like data sources, JMS topics, etc for production?

Is it possible to install and configure the resources with a script rather than editing config files?

I have in mind something like the scripting that Weblogic has.

Mike

[jesse.hazen]

I'm not familiar with Weblogic, but you can definitely script the editing of those files. Thats what I do: I have a bash script that runs over a fresh install, and uses sed to find/replace the settings. I have different scripts for different environments. If you are using a Windows box you could install Powershell, I guess, and would probably get some similar capability.

Hope that helps.

[wdfink]

I have written a Java based installer for my company. The JBoss version depended config files are provided with special tags '@{NAME}' that will be replaced during installation.

So use of the installer is compatible across different versions and the configuration is restricted and hidden for the end-user.

Also you might violate the license if you provide a JBoss with your application.

[peterj]

I keep all of my config files under source control along with the rest of my source code. My ant build scripts deploy the configuration files as part of deploying the application.

>>Also you might violate the license if you provide a JBoss with your application.

No you won't. The LGPL allows redistribution with little hassle (you would need to also provide the source).

[jesse.hazen]

Yes, we use source control for our boxes as well. We have config files checked into a subversion server so we can just pull the files to a new box. But I have a script that makes any host-specific changes (like any hard coded IP's, hostnames, cluster name, etc).

[peterj]

I have my ant scripts make the host-secific changes. I make good use of the FilterCHains within the copy task. All of my config files contain EL-style properties references and I let the ant script replace thep roperties with host-specific settings during the copy.

Example: I have a single *-ds.xml file that I use for all databases (even for different database providers). Almost every setting is a property value, such as:

    <connection-url>${db.url.base}${db.database}</connection-url>

I then have a properties file per deployment environment that defines the various propoerties specific to that environment.

[michaill]

Also you might violate the license if you provide a JBoss with your application.

Can you elaborate on that? We are currently using the community version. (I know this is unrelated to my original questions)

[wdfink]

Peter Johnson schrieb:

>>Also you might violate the license if you provide a JBoss with your application.

No you won't. The LGPL allows redistribution with little hassle (you would need to also provide the source).

Ok, than it will only a problem with the EAP versions.

[michaill]

Thanks for replying.

What about, say, jboss-log4j.xml? Do you put your version into source control, and at installation overwrite the default one?

Also, what about custom profiles? Do you generate them as part of installation or do you copy pre-generated profiles?

>>Also you might violate the license if you provide a JBoss with your application.

     >>>No you won't. The LGPL allows redistribution with little hassle (you would need to also provide the source).

The source of my application??? I thought that's GPL. That would be a major problem for a commercial product.

[jesse.hazen]

He meant JBoss source.

Speaking for myself, we have a zipped install of JBoss custom set for each environment. The jboss-log4j settings are in source control. If we need to change it, likely we need to change it for every box (not always the case). If we do need to change it, we have always make the corrections to one file, checked it into SVN and repulled the file to each box.

For a new application/environment, we'll pull an existing zip, make all the changes, rezip it and put all those files into a new svn branch. Then each time we install a box, we use the same settings, except in special circumstances (cant think of any off the top of my head though).

[michaill]

Thanks for clarifying.

Does your zipped install include applications as well?

So, basically, you configue JBoss on one box, zip it, put it in SVN, and the installation on a production system is just unzipping that file and, if necessary, pasting in config files. Did I get that right more or less?

Thanks,

Mike

[jesse.hazen]

Yes but no config pasting. I unzip the package, run the script to change host-specific stuff, and I'm done. Applications included, already tuned and configured, released.

[michaill]

Thanks!

[ergho]

Wolf-Dieter Fink schrieb:

Peter Johnson schrieb:

>>Also you might violate the license if you provide a JBoss with your application.

No you won't. The LGPL allows redistribution with little hassle (you would need to also provide the source).

Ok, than it will only a problem with the EAP versions.

Is this really true? I think the EAP version ist still distributed under LGPL license(see http://www.redhat.com/licenses/jboss_eula.html). There are only trademark issues.

[wdfink]

I'm not sure what is the correct way to ship a community JBoss (I'm not a graduate in law), it might necessary that you have to deliver the source of your application also.

Nevertheless, the EAP version is different.

You can not ship a EAP version because (your) customer must have a subscription and must install the EAP itselve

OR

you are a reseller with a special contract with Red Hat, then you are allowed to ship an 'embedded' EAP-JBoss. In this case the JBoss must be a part of your application and the customer can not deploy other applications and you must provide the first level support.