Today we tried to access our EJBs through a remote client. Unfortunately we were not able to connect because the lookup always failed with a NameNotFoundException error. Of course we were sure that those EJBs were bound because our webapp were able to access them. After some time of investigation we finally found the cause: in our jboss.xml file we set the JNDI name to java:/<ejb>. It seems that java:/ is visible inside the JVM only. After we changed the JNDI name to simply <ejb> everything worked fine.

So here's a snippet from our jboss.xml file before:
[code] UserManagement java:/UserManagement [/code]
And this is a snippet afterwards: [code] UserManagement UserManagement [/code]

Some days ago I've installed Gentoo 1.4 on my Dell box because I was sick of the RPM hell. The good thing is that Gentoo is up-to-date concerning system software packages. The bad thing is that Gentoo is up-to-date concerning system software packages? Err? Well, in case you are able to compile the sources on your own ... fine! But commercial software very often requires old system packages, mostly older versions of the GLIBC. IBM's WebSphere 4.0 is such a candiate (in fact the bundled JVM is affected) and therefore it requires some tweaking in order to run on Gentoo 1.4. After some investigation I found out that WebSphere 4.0 requires a GLIBC with kernel 2.2.5 support. Fortunately the GLIBC which comes with Gentoo 1.4 can support this feature. It is, however, disabled by default and therefore you must recompile the GLIBC. The following steps are required: [code] 1. Change into the directory /usr/portage/sys-kernel/linux-headers 2. Emerge linux-headers-2.2.20.ebuild 3. Drink some coffee 4. Change into the directory /usr/portage/sys-libs/glibc 5. Emerge glibc-2.3.2-r1.ebuild 6. Drink lots of coffee or take a walk [/code] Make sure that you do not have "ntpl" in your USE variable before rebuilding the GLIBC. Afterwards WebSphere 4.0 should run fine =)

I have extended my custom RequestProcessor once again. With the help of Jakarta's Commons Digester it was very easy to create a simple XML based configuration file. Then I decided to move the IoC stuff from the RequestProcessor into an interceptor called ComponentInterceptor. Not only it shows that my interceptor extension does work but the code looks much cleaner now. I hope to release my work under Open Source soon. But before that I must set up an infrastructure first ...