Miscellaneous musings in beta

Yesterday I tried to add mod_python 3.3.1 to my Apache 2 installation on Ubuntu.

After a download of the mod_python source, the source needs to be configured against the apache extension tool (apxs) like so:

./configure --with-apxs=/the/path/to/apache/bin/apxs

Configure went fine. The problem started after make, that ended with the dreaded:

Command failed with rc=65536

No effort to compile after that worked. Until I found this blog. It suggests that I should download the source from SVN trunk instead like so:

svn co https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk

After that make and sudo make install went fine. I guess that some patch is not included in the official source download.

Add to httpd.conf:

LoadModule python_module  modules/mod_python.so

Apache now does Python as well.

Note: If you’re installing on a standard installation of Apache 2 on Debian or Ubuntu, then you only need to:

sudo apt-get install libapache2-mod-python

My apache 2 is not a standard installation though so I had to roll my own installation.

I got this exception yesterday, when I tried to deploy two Flex applications using Blazeds on JBoss 5.1. The first deployment went fine, but number two deployment threw this:

java.lang.RuntimeException: MessageBroker already defined from MessageBrokerServlet with init parameter messageBrokerId = '__default__'

It happens because both .ear applications were deployed in the same domain. One way of solving this is by giving the MessageBroker servlets a unique identifier. That works, but it’s probably better to create a proper class isolation by giving both apps their own domains. Read my blog about class isolation in JBoss.

The class isolation solution is simple. Just add a jboss-classloading.xml file at /EarContent/WEB-INF. The file should look like this:

<classloading xmlns="urn:jboss:classloading:1.0"
name="yourApp.war"
domain="yourAppDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>

After two redeployments the web applications should now inhabit their own domains. I use the .ear application name as the domain naming scheme.

Isolated classloading is a somewhat esoteric affair when deploying an ear in JBoss. Class conflicts are waiting to happen without a proper isolation between server and applications and between applications themselves. And without a proper isolation it is difficult for the developer to be sure of any versioning.

There’s also an argument against too much isolation. The same jars are present many times over on the server. And a ClassNotFoundException gets thrown when a class seems to be missing entirely.

This is an issue that has a lot of various solutions and also heated opinions – the classloader method alone has a long history in JBoss. JBoss classloader technology is a moving target – constantly evolving. Different versions of JBoss represent different solutions.

The really troublesome cases of class isolation happen when JBoss actually finds the class – but in a different, conflicting version. The first class conflict I encountered was like that. A small application that happened to use a version of xerxes. No dice deploying that. And the exceptions thrown were of the weirder variety. Now removing the file would solve the problem but what if you actually need the particular version of xerxes?

After a lot of trial and error and reading blogs – and a zillion restarts of JBoss, I finally found an approach that actually works on version 5.1. If you don’t want complete isolation, but instead share classes in the default domain, you need to make a jboss-classloading.xml file that looks like this:

<classloading xmlns="urn:jboss:classloading:1.0"
name="your_war.war"
domain="DefaultDomain"
parent-domain="Ignored"
export-all="NON_EMPTY"
import-all="true">
</classloading>

The sharing part is determined by the export-all and the import-all parameters. By import-all = true I include all other classes exported by other applications in the DefaultDomain. And I expose all classes to other classes by using export-all = NON_EMPTY.

Complete isolation in an own domain looks like this:

<classloading xmlns="urn:jboss:classloading:1.0"
name="your_war.war"
domain="own_domain"
export-all="NON_EMPTY"
import-all="true">
</classloading>

You can even explicit declare a parent domain while being isolated:

<classloading xmlns="urn:jboss:classloading:1.0"
name="your_war.war"
domain="own_domain"
parent-domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>

You place the file in /WebContent/WEB-INF – right next to your jboss-web.xml. After a redeployment your class conflict issues should go away.

Read more about jboss-classloading here. And here. And to get a more detailed understanding.

Installed JBoss 5.1 on my Windows box – only to have it complain about a JVM_Bind binding problem during startup. Apparently some other process is already using port 4445.

So I decided to change the port. After some running in circles on different forums, I found some documentation here.

The documentation turned out to be obsolete, but a comment at the bottom helped me. The xml file to change is bindings-jboss-beans.xml, and this file is found in \server\default\conf\bindingservice.beans\META-INF assuming that you’re using the default server profile.

Changed 4445 to 4447 (4446 is used by JBoss) and startup went without issues.

UPDATE: Same issue happed on JBoss 5.0.1. The file to change on 5.0.1 is bindings.xml in \server\default\conf\ – again assuming that you’re using the default server.

UPDATE: *sigh*. Same issue with JBoss 5.0.1 Enterprise. That changes same place as 5.1 – so some technology must have dribbled down to 5.0.1. I had to change 4445 to 4449 instead.