Yes We Code !

AS7 provides the JNDI functionnaly through the naming subsystem. If you take a look at the corresponding schema ($AS7_HOME/docs/schema/jboss-as-naming_1_1.xsd, you will see that its configuration has only a few options.

What does this XML schema description says ? It says that the configuraiton of the naming subsystem is composed of “binding” elements. Each of this element can be:

A simple type: Basically, these are the common number types (int, long, BigDecimal, etc…) or String.

a lookup type: This only a kind of JNDI name alias. Which you can use to have two different names for the same resource

An object-factory type: A class which implements javax.naming.spi.ObjectFactory, instantiated once per declared resource and responsible of the instantiation of a custom object.

As you can see, the simple type is quite limited, but I hope that this may evolve depending on needs. So, our last chance to register custom types is to use the object-factory.

Create an URLResourceFactory

To avoid creating one factory class every time you need to bind one URL, the factory will get the value attached to a system property having the same name as the JNDI resource to create URL.Here is what the ResourceURLFactory may look like (some additional checks may help) :

The content of the module.xml file must be the following lines. The dependency to javax.api is required cause the classes of the jar uses this API, so it has to be loaded otherwise, you gill get ClassNotFoundExceptions.

Today is the official annoucement of JBoss EAP6 (based on AS7.1), so I was thinkig that it was a good day to write a blog on AS5/EAP5.
Probably, not the most read article, but it will probably help someone…

Why would you disable session replication ?

Believe it or not, but everything has a cost. My grand-mother used to say: “Only the scorpion gives for free”. And this is of course the case for session replication. It has a cost that could be adjusted using several techniques: Buddy replication, change granularity replication or synchronous/asynchronous replication mode.
In some rare cases, because your organisation is not ready yet, because your applications does not supports it, or because you simply don’t want it, you may want to disable session replication, while still having other clustering features available on JBoss like automatic cluster configuration, farm deployment, HA JNDI, HA Singleton, etc…

The easy way: Do not set your application distributable

The easies way to disable (HTTP and statefull session beans) sessions replication is simply to NOT set the tag in your web.xml file.

The good point of this solution is that your JBoss configuration will remain untouched and fully standard. However, you are not protected against an application having a distributable tag. This of course will trigger session replication and that may have an unexpected impact on your overall cluster performance

The efficient way: Disable session replication on JBoss AS 5

To prevent JBoss from replicating sessions whatever the deployed application, you have to modify the way that JBossCache replicates HTTP sessions and SFSB Sessions. To do so, just edit the file $JBOSS_HOME/server//deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml and set the cacheMode parameter to LOCAL for the caches named StandardSessionCacheConfig, FieldSessionCacheConfig and StandardSFSBCacheConfig.

LOCAL

The default value for these parameters are: REPL_ASYNC which mean that the cache replication is triggered and does not wait synchronously for the cache write confirmation.
The LOCAL value prevents the replication message to be sent and this blocks session replication when set on the relevant caches configuration.

The subject of this post may be misinterprated….or not.
To help search engines to find it more easily, the subject here is to give some tricks while using the puppet tool from www.puppetlabs.org which used to automatically administer large systems by allowing automated installations and configurations drifts detection.

These functionnalities are also available on some other tools, among them JBoss Operation Network (the drift feature is available since version 3.0), however puppet seems to gather of a larger adoption among the community.

While working at a customer, I met a sponsor so we decided to give it a large try.

Corporate customers often rely on a enterprise Linux distribution, and RHEL 5 is often a common guest in the party. Unfortunately, puppet is not a part of the distribution and you have to rely on the EPEL (Extra Packages for Enterprise Linux) repository to make it available for installation.
To do so, simply add /etc/yum.repos.d/epel.repo with the following content:

There are some interesting blog posts on how to do load tests of seam applications with JMeter. Since a few days, I had to train a customer in doing load tests. We had a pilot project, that already had a testable application with its own JMeter tests scripts, however, because of lack of time, the application was not ready, and I had to fallback on another solution.

My favorite demo application is Seam Booking application which is a “bogus” Hotel Reservation Web Application developed with Seam (using JSF, Seam and Hibernate). The application is pretty and nice to use. It uses Ajax and just like all JSF applications it rely on javax.faces.viewState’s that are exchanged along pages. Because it uses Seam, there is also a “Conversation ID” that is hold from pages to others.