Posts Tagged ‘JBoss’

Changing the HTTP port Oracle uses

In a production environment your database server will be completely separate from your application server or at least it should be. So in theory you should never really need to change this setting unless its for your development environment.

In my case I needed to run both JBoss and Oracle on the same PC in order to test my environment. Why would I need to change the HTTP port of Oracle? Well Oracle has an HTML set of admin screens it uses as an interface to let users do DBA stuff rather than doing it from a prompt screen, on Oracle XE this is called Apex and for Oracle Enterprise, I think it’s just called Enterprise Manager or some such shit. Two different GUI’s but both  use and reserve the HTTP port on your computer. Since Oracle starts before JBoss, Apache then can’t use this port to talk to JBoss.

The easiest way around this is to set the HTTP port that Oracle uses and it’s really really simple. You’ll need to have the SYSDBA priviledges for this to work, so I’ll assume as much.

Start SQLPlus and login to your server connecting as SYSDBA. Normally by default the connection will be something like: connect SYS as SYSDBA@XE etc… where XE is your service identifier – for Enterprise it’s what ever you called it on install.

Once you’ve done this then just run this command: exec dbms_xdb.sethttpport(9090);

This sets my Oracle HTTP port to 9090, something JBoss shouldn’t be using. Now I can have everything running without conflict. Apache can now see JBoss and I can still get to Oracles admin screens.

How to Setup Debugging in Eclipse for JBoss

JBoss Debug Startup

This is really useful – only recently found out how to do this and the benefit is enormous. Basically by a small configuration on JBoss’s startup configuration and a setting in Eclipse we can toggle breakpoints in our java code so that we can see where our code gets stuck and the JBoss processes that it goes through.

It takes about 5 minutes to do and once you’ve done it, it’ll make things much easier.

Start with JBoss, you’ll need to edit its run file (/jboss/bin/ or run.bat) and un-comment line 87:


This tells JBoss which port to use to listen to for debug commands and it enables the JBoss’s remote debugging functionality.


Next we need to go to Eclipse and configure the debugger in there. If you go to the Window menu at the top and then go to Open Perspective and look for Debug (you may need to choose it from the Other menu). Once you’re in this perspective you can then setup an application profile for your debugger – look for the bug symbol on the top tool bar and select the Debug Configurations menu.


In here we choose to create a new Remote Java Application giving it a name and connection details for your JBoss server – so in my case its localhost. The port MUST be the same as the port expected in your JBoss run file, in this case by default its port 8787.


Ok thats it – debug should be setup. When you start JBoss it’ll pause waiting for you to start the debugger in Eclipse – just go back to the bug symbol and select your configuration you just made. JBoss will continue to load after this point and Eclipse should start showing you JBoss’s processes that it’s running.


Now we can add in breakpoints to our code allowing us to step through the code when its activated on JBoss – so if a user submits a form that calls in a bean which does x, y, z then we can see the logic that happens and if any issues occur – this is really useful for things like payment pipelines.


To toggle a breakpoint or to enable/ disable an existing one, just click in the left margin of your code window at the line you want to begin to step through. When this line gets processed JBoss will stop and you can then use the step through commands on the debug menu.


If you’re using the startDynamoOnJboss and run-in-place methods for your server then you can debug and fix your code theoretically very quickly and easily.

Hot Deploy Java code/ ATG components on JBoss

Pretty simple, on a production environment you start JBoss with its run file and a series of commands, which then picks up your EAR file from the deployment directory. Which is a fine process to go through, but what if you’re developing code and you don’t want to wait the several minutes for a build and deployment – on a windows system this can take well over 20 minutes to achieve if you’re running things locally.

We want to do hot deployment so that when you make small changes in your java class/ ATG component you don’t have to rebuild and restart JBoss each time and you save yourself a lot of time.

We can do this by starting JBoss in the following way:

To avoid building an EAR file each time rather than using JBoss’s run file (/JBoss/bin/run.bat or ATG provides a way to start JBoss and build the EAR on the fly from your working directory. This means that you can make changes to JSP’s etc… and see the changes instantly. To do this from your command prompt/shell go to your ATG home directory (/ATG/ATG22007.1/home/bin/) and in the bin run this file: StartDynamoOnJBoss.

In order for this to work and hot deployments to work we need to pass in a few parameters for this to work. Firstly the dynamo server to use – if you’re using one. Next set the name of the jBoss server using the -c flag. Then set the modules you want to load so your projects bin/ code source directory, ATG modules etc… and finally set the most important command -f -run-in-place which tells jBoss to compile and run the code from your projects directory rather than look for an EAR file in its deploy directory. So the start command looks like this:

startDynamoOnJBoss MY_DYNAMO_SERVER_NAME -c MY_JBOSS_SERVER_NAME -m MYPROJECT.core -f -run-in-place

And thats it. Now you can make changes to your files in Eclipse and you won’t need to restart jBoss. But there is one last thing – make sure to set your project in Eclipse to build automatically – you can set this under the project menu at the top.

Setting Database Connections in JBoss/ ATG


ATG communicates to a database via JBoss via a dynamo server setup or in your home/localconfig directory if you’re not using specific dynamo servers. In this setup you specify the JNDI connection name which will then refer to an XML file which makes up part of your JBoss server. So to summarise ATG connects via its own JNDI config file which maps to an XML file on the JBoss server. JBoss then handles the connection out to the data source via a JDBC call – this can be any type of database or repository potentially.

Here’s how to set the database connections for something like Oracle. For MySQL etc… the procedure is pretty much the same and you can find example XML configs for these in your JBoss install the only real difference is the driver used for the connection.

First start with JBoss and setup the XML. Go to your servers deploy directory: \jboss\server\MY_SERVER_NAME\deploy. If you haven’t setup a server then this will be called default – if you’ve installed ATG then there will be a server called ATG. In your deploy directory there will be XML files normally with the mention of ‘ds’ in the file name, to let us know its for a data Source. If you go to:¬† \jboss\docs\examples\jca you should find example XML connection files here.

Alternatively using the below code we can create one for Oracle called something like ATG-Oracle-DS.xml.

In this XML file we basically set the JNDI reference name, the JDBC connection URL which is the database server IP/name along with the port and the SID (Service Identifier). We then set the schema that we want to connect to and it’s password. It’s the same for any database connection, although you’ll also see that we set the driver to use for the connection (more on this after the below XML)…







OK so the XML is pretty simple – you can have as many connections in one XML file as you need but sometimes it’s easier to keep them in separate files to identify connections. You can also MIX connections, so I can have a schema on Oracle, another on MsSQL and a third on MySQL and ATG can read and use data from all of these as part of its data anywhere architecture.

Here’s the gotcha – you MUST make sure the driver/ libary jar file is installed for your server to connect to your database. So go to your server’s lib directory e.g. \jboss\server\MY_SERVER_NAME\lib and for Oracle you will need a jar called ojdbc14.jar which contains the necessary classes for JBoss to connect to your database – generally JBoss does come with most database library jars but you may need to hunt this one down on Oracles website.

So We’ve set an XML file that specifies a connection for JBoss to use, we’ve added the necessary libary files to our JBoss server so it can make the connection. Finally we need ATG to be configured to use this connection, this is the really easy part!

In ATG the sources are referenced via the Dynamo servers localconfig, so for example in: \ATG\ATG2007.1\home\servers\MY_SERVER_NAME\localconfig\atg\dynamo\service\jdbc or if you’re not using Dynamo servers then just look in home\localconfig\atg\dynamo\service\jdbc.

If you’re building an external EAR file for your deployment then include this¬† in your Dynamo servers that you export with your EAR file. Anyway in this config directory you need to make a .properties file to set the JNDI connection to use. Just add the below 2 lines – the JNDIName variable should reference the JNDI name in your XML file.


And thats it! You should be able to map any database for use with ATG replacing the Solid database that comes with ATG.

Now a word of warning – it’s fine using additional databases for ATG but if you want to completely replace the Solid database, and in a production environment this is a must, you will need to load in the tables to your database for ATG to use, but I’ll write this up in a separate post – It’s pretty easy as ATG ships with various SQL setup scripts for you to use to achieve this.

Adding and changing Mod JK JVM route, URI encoding and thread settings for JBoss

jboss jvm uri threads

In your JBoss server there is a file that can be amended to alter the URI encoding and the number of threads used by JBoss. Additionally if you’re using mod_JK to link Apache HTTP and JBoss/Tomcat you can specify a JVM route parameter here that allows Apache to route incoming requests to the correct node.

To do this we need to look at the following file:

\jboss\server\[SERVER NAME]\deploy\jbossweb-tomcat55.sar\server.xml

In here we can amend a couple of parameters and add in a few extra values. For thread numbers and URI encoding look in the file for:


We can then edit the maxThreads parameter for more threads if needed although check your applications recommended threads, for instance ATG recommends no more than 250 threads per server. We can also add in the following parameter here for URI encoding which is: URIEncoding=”UTF-8″.


For the JVM route we need to amend this line in the server.xml file:

To the below, adding the jvmRoute parameter:

Doing this should help you with your mod_JK setups and remove a few issues between Apache and JBoss.

Setting the JDK version and compiler in JBoss for JSP pages

jboss jdk

If you need to run Java 1.5 in your JSP’s in JBoss 4.0.5.GA you can do so by editing a small setting in an XML file in your server directory:

jbossserver[SERVER NAME]deployjbossweb-tomcat55.sarconfweb.xml

You can then change the compiler version by un-commenting the code below which you will find in the web.xml.


Changing this will then allow for a different JDK to be used in your JSP’s.

Running multiple instances of Jboss on one server.

jboss ports

To run multiple Jboss instances on the one server is pretty easy – but remember that if you’re running something like ATG commerce you’re going to need a few Gb of memory to run just the one JBoss instance let alone multiples. So you may want seriously consider keeping separate VM’s for each server in your production environment depending on your application requirements e.g for heavyweight commerce keep them all as separate as possible. But for quickly building a development environment this is the way to go.

Anyway, the main thing to worry about with JBoss is the network ports setting as each instance needs it’s own port range, once you’ve done this then it’s all down to your application as to which port set it needs to use. So here’s how to set multiple instances and their respective ports. You’ll see that most if not all config for JBoss is done with XML files.

First we need to create an XML file to store our port bindings, thankfully we can use a sample one which you’ll find in: jboss\docs\examples\binding-manager\sample-bindings.xml and we can create a new directory to store this, something like jboss\bindings\binding.xml

You can see below a section of the code which sets up a ports definition for our server. At most I have done 4 configurations and actively run them all at once on a machine with 3Gb memory and it worked fine for my development requirements. Also I would recommend that you only use 1 bindings file however you can create and use multiple XML’s. Also you will see that we’re using ports 8180 instead of the typical 8080, this potentially leaves you 8080 free for another server giving you 5 in total – or it leaves the ports free if you need to map in an additional server on 8080, like FatWire. Depends on your architecture really, just remember 8080 is the default port setting of JBoss.









































The ports can be incremented by 100 for each port in a new port setting, so for instance 8180 can be changed to 8280 to give you a new range. Just leave alone the section headed with:

You should be able to see the differences in the example bindings file between ports-01 and ports-02 setups and I’ve also commented each port change with so you can see which ports to change.

With that file done, next go to your JBoss install directory and then look for your server, if you’re using the default then it will be called… default. You can now duplicate this server if you need to and you’ll be able to run both at the same time with this tutorial. In here we look in the conf directory for a file called jboss-service.xml. The path to this looks something like this: \jboss\server\[SERVER NAME]\conf\jboss-service.xml

So open this file up and look in here for the following section:


We then un-comment this section, e.g. remove the ‘–>’. Then we alter the ServerName attribute to match your server’s name and the StoreURL attribute to point to your new bindings file. Repeat this step for each of your servers. The servers name you enter is used to look up the ports configuration in the binding.xml, so if you left it as the default ports-01 then this will be the server name you need to enter.

And that’s pretty much it, if you have port conflict errors onyour startup then look in these files and also check that your application is set to use the particular ports, for instance using ATG we set the dynamo server to use RMI port xxxxx etc… which maps into your JBoss ports config. One other thing – you will always be able to see the ports being used in your JBoss logs if you need to debug.