Since ESB is a ‘mix’ of JBoss messaging, XML and UDDI components, here is the absolute minimum classpath you will need to run a client against and ESB (invoke a gateway service):

Note JBOSS_ESB_HOME points to the installation directory of your JBoss ESB server

JBOSS_ESB_HOME/lib/jboss-common.jar
JBOSS_ESB_HOME/lib/concurrent.jar
JBOSS_ESB_HOME/lib/endorsed/xercesImpl.jar
JBOSS_ESB_HOME/server/default/deploy/jboss-aop-jdk50.deployer/trove.jar
JBOSS_ESB_HOME/server/default/deploy/jboss-aop-jdk50.deployer/jboss-aop-jdk50.jar
JBOSS_ESB_HOME/server/default/deploy/jbossesb.sar/lib/juddi-client-2.0rc5.jar
JBOSS_ESB_HOME/server/default/deploy/jbossesb.sar/lib/scout-1.0rc1.jar
Hopefully that will save you some pain….

There is no silver bullet for your classloading problem. A structured approach to resolving the issue taking into account the specific needs of your application remains the best solution to dealing with these problems when they crop up. And yes, experience in dealing with them does help too!

There are a number of good resources out there to help you understand the problem domain.

• http://wiki.jboss.org/wiki/ClassLoading – This is where is all begins
• http://wiki.jboss.org/wiki/JBossClassLoadingUseCases – If you really want to understand classloading from JBoss’ perspective, then do yourself a favour – make a pot of coffee, book the night off and settle into this document. If you understand the concepts here, you are 90% of the way there.
• http://docs.jboss.org/jbossas/jboss4guide/r5/ (PDF format) – There are good sections here which describe the classloading architecture, specifically: (http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch2.chapter.html#d0e1904)

Just as important as the resources is the jmx-console. This little tool is an extremely useful mechanism for looking under the covers of the JBoss application server. Take a look at the JMImplementation:name=Default,service=LoaderRepository MBean. This MBean is basically the default UCL. Information about where the class was loaded from and which jars make up the UCL (to name but a few) are all here.

And then finally, the xml configuration files for your server. Pay particular attention to:

• jboss-service.xml of the jboss-web component (deploy/jboss-web.deployer/META-INF)
• ear-deployer.xml

There are adequate resources out there to feed your brain, and with a little time you should be able to get your head around some of the more perplexing classloading issues. If you are still stuck, well…. then its time to pick up the phone.

Cheers

• Finding out what’s going on behind the scenes – especially when first trying out a this type of technology you may want proof of what’s happening.
• Debugging queries – sometimes what you get may not be what you expect.
• Optimising queries – is your query structured in a way which makes best use of your particular database, or – sometimes more pertinent when working with an ORM framework – is your database structured in a way which makes best use of your query?
• Checking query/second level caching.

Typically there are two ways of doing this

1. Set properties in the hibernate configuration which write the queries to standard out. Queries can be formatted and hints can be included.
2. Enable logging on specific packages which when output at the correct log level, generate the SQL that is being executed.

The benefit of the second option is that we can append this information to a specific file for analysis – i.e. we don’t have to mix it up with all the other logging information that we generate.

I’ve got the hibernate ‘bible’ in front of me: Java Persistence with Hibernate. Chapter 2, section entitled ‘Enabling logging and statistics’ reads:

…
…
# Log JDBC bind parameter runtime arguments
log4j.logger.org.hibernate.type=INFO

The last category in this configuration file is especially interesting: It enables the
logging of JDBC bind parameters if you set it to DEBUG level, providing information
you usually don’t see in the ad hoc SQL console log

The first problem is that if you want type parameter logging, you need to set the value of org.hibernate.type to TRACE and not DEBUG, i.e.
log4j.logger.org.hibernate.type=TRACE

Secondly, in order to output the actual SQL statement, you need:
log4j.logger.org.hibernate.SQL=DEBUG

The combination of these two configurations will output both the SQL and the bind parameters. Note that if you are running in JBoss you cannot update the value of the org.hibernate.type value on the fly and expect to see the changes; the value of the threshold is cached at startup for performance reasons.

The error typically presents as follows:

12:49:46,251 INFO  [STDOUT] log4j:ERROR A "org.jboss.logging.util.OnlyOnceErrorHandler" object is not assignable to a "org.apache.log4j.spi.ErrorHandler" variable.
12:49:46,252 INFO  [STDOUT] log4j:ERROR The class "org.apache.log4j.spi.ErrorHandler" was loaded by
12:49:46,252 INFO  [STDOUT] log4j:ERROR [WebappClassLoader
  delegate: false
  repositories:
    /WEB-INF/classes/
----------> Parent Classloader:
java.net.FactoryURLClassLoader@ece36
] whereas object of type
12:49:46,253 INFO  [STDOUT] log4j:ERROR "org.jboss.logging.util.OnlyOnceErrorHandler" was loaded by [org.jboss.system...AnnotationURLClassLoader@183f74d].
12:49:46,299 INFO  [STDOUT] log4j:ERROR Could not create an Appender. Reported error follows.
12:49:46,300 INFO  [STDOUT] java.lang.ClassCastException: org.jboss.logging.appender.DailyRollingFileAppender

Some backround information at this point is useful.

JBoss classloading is a complex topic discussed in detail in the admin guide for the relevant versions. In fact is is to well discussed that when I read my first admin guide I took a second look to make sure that I was reading a JBoss book and not a classloading book. Read this first.
When it comes to classloading in the web container, the rules are bent slightly. JBoss defines two attributes in the META-INF/jboss-service.xml file of the web container which modify the classloading behaviour. In the 4.0.5 -> 4.2.2 product the following values are set:

<attribute name=”Java2ClassLoadingCompliance”>false</attribute>
<attribute name=”UseJBossWebLoader”>false</attribute>

Java2ClassLoadingCompliance

In the normal Java world, classes are loaded from the parent classloader first before an attempt is made to load classes from a child classloader (true). The servlet 2.3 spec states however that the web container’s classloader should be used in preference (false).

UseJBossWebLoader

If true, the JBoss classloader (read Unified Class Loader – UCL) will be used to load resources. False means that the tomcat classloader will be used.

So the default setting imply that you are going to have a tomcat classloader which loads from the web archive first.

Recommendation: Don’t mess with the default settings.

This then explains why we are getting ClassCastExceptions. A copy of commons-logging.jar was present in the web application archive (war) and is shipped by default with JBoss.
Since <class com.foo.Bar loaded by classloader x> != <class com.foo.Bar loaded by classloader y> we end up with the exception.

The simple solution in this case was to remove commons-logging.jar from the war’s WEB-INF/lib folder and rely on the version in JBOSS_HOME/server/lib.

There are of course other solutions which involve classloader scoping, but these are more advanced and need to be tailored to an individual need.

• A page is rendered to the browser directly after a POST operation and the user refreshes the page (thus re-executing the POST)
• The user hits the back button, browsing back to a page which was previously rendered by a POST operation.

Yes – a lot of browsers do warn the user that something nasty is about to happen. But do we really expect the user to work around our shortcomings in design?
The impact of the re-POST will vary depending on what you actually performed during the POST. The best case scenario is that your operation is idempotent; re-executing the operation has the same net effect as executing it once. An example of this is filling in a search form and POSTing a search. Re-submitting the POST will just re-execute the search and re-display the search results. On the other hand, an operation such as a credit transfer on an internet banking web application may result in a second credit transfer and a very unhappy internet banking client.

One very effective way to counter this is by applying the redirect after post pattern to your web application. In essence the pattern can be interpreted as ‘ALWAYS redirect your client after a POST action. NEVER render a page directly from a POST’

Every web application developer should understand the consequence and cause of this behaviour. A detailed description of this problem and solution can be found here

Depending on the web application framework that you are using, this pattern in implemented in a number of ways. Using tapestry, returning an ILink from a listener method or throwing a RedirectException has the effect of redirecting the client.

Remember that there are considerations when using this pattern. One of the trickier ones is the concept of application state. Lets take an example

A developer designs a web page and a struts action/form which handles search functionality.

1. The web form is POSTed to the web container which invokes the struts action.
2. The parameters are interpreted and the search performed, populating the view (struts form with request scope) with the search results
3. The page is rendered using the results contained within the struts form

The developer now wants to implement the redirect-after-post pattern, and redirects to the search action between 2) and 3). The results page is always blank.

The reason for this is that the application state (contained by the struts form) has been lost during the redirect and the search results are empty after redirecting. Remember. – redirecting involved a round-trip to the client and thus a new HTTP request.

There are many ways to solve this issue and most involve some transfer of state. If the underlying model (database) reflects the application state – then its a simple case of just re-reading the model. But we don’t typically save search results in the model and some form of state transfer needs to occur between the two requests. How you do that also depends on your web application framework, so I’ll leave that to you to figure out.

This is a good 2 minute overview of the product: http://labs.jboss.com/community/newsletters/2007/september/esb_qa.html

We are doing some intimate web service and rules work at the moment, and will be posting some entries on our experience in particular:

• Securing web service endpoints with certificates
• Using the jUUDI server in JBoss

I try to distill it down to the core issues.

We all know that JNDI is an abstraction to naming services, in the same way that JDBC is an abstraction to data storage services. In Java and J2EE, JNDI is used to bind programmer-friendly names to resources that may be defined in another place and time – either by another piece of code but usually by the application server itself. A good example is a datasource name – “java:/myDatasource” is what you may use to refer to your database, and at startup or deploy time JBoss has bound the details of your connection to that name.

So what about namespaces?

In J2EE there are 3 JNDI namespaces defined by the specification:

1. The global namespace (no prefix)
2. The VM namespace (java:/)
3. The component namespace (java:/comp/env)

Objects bound in (1) are available to any lookup on the same network. Remote interfaces (implemented as JBoss smart proxies) get bound by JBoss in this namespace so that anyone can do a lookup and retrieve a proxy to the object. Also, if in your code you call ctx.bind(“someName”) then your object is bound as “someName” in the global namespace.

Objects bound in (2) are available to any lookup in the same virtual machine. This is where JBoss binds resources that your web and server components may want to access, such as datasources, other jca connections, connection pools etc. If you want to bind something in this namespace, for example if you have written an MBean you want only accessible to objects in the VM, the you would traverse the JNDI tree (see the Javadoc for Context) and bind your object in the appropriate place. Remember to create a subcontext first if it does not exist.

Objects bound in (3) are available to a single object only. Even objects in the same package and application will not be able to access them. Typically these are resources or local names for already bound objects which are declared in the deployment descriptor and/or annotation for a particular object.

Don’t despair if you were used to finding what you wanted there and are now out in the cold.

The http://www.jboss.org site is the aimed-at-developers site, and it is the new place to go for downloads, webinars, developer blogs and other useful information. Just follow the “how to jboss projects fit together” link and from there you will easily find your way around.

So you decide to use or upgrade to JBoss 4.2.0, and test it locally and it works just fine. Then you go aheas and deploy to the server and you get “Connection refused” exceptions. Huh?

Before JBoss 4.2.0, the default behaviour for the JBoss Application server was to bind itself (and thus be available) on all configured network interfaces. Now it _only_ binds to “localhost” unless you tell it otherwise. So start the server up using run.sh -b <ipaddress> and all will be well again.