Expressing dependencies between services using the <depends> tag is a very handy feature of JBoss. However, there are cases where services do not conform to the JBoss lifecycle model, or even if they do, the completion of their lifecycle methods does not express the dependency we want.

The typical use-case is delaying the starting of a custom service that hits a servlet, until *after* the Tomcat connectors are active, which in turn happens only after the server has completely started. This is possible using JMX notifications (i.e. subscribe to the jboss.system:type=Server, org.jboss.system.server.started notification).

A generalization of this technique has been added to JBoss v4.0.2 with the introduction of the BarrierController service. The service makes it easy to declaratively register and use *any* combination of notifications in the system as triggering events for the starting and stopping of a secondary Barrier MBean.

Then you can use the familiar <depends> tag to make your custom service depend on the Barrier, without having to worry about complex dependency issues.

A detailed description of the service can be found in our wiki.

dimitris@jboss

To begin with, I'm a big fun of logging. In fact, I rarely use a debugger and only as a last resort. I've always believed that code is best debugged in your "head", as long as you know what you are doing. (It could be also that I'm just a louzy IDE user :)

For a long time, I admired the JBoss org.jboss.logging.Logger "wrapper" for a couple of reasons: the API is small, simple, and it only includes 5 + 1 levels of logging: ERROR, WARN, INFO, DEBUG & TRACE. (there is the FATAL level, but I doubt if it is ever used, it should be removed, really.)

Whenever you want to log something, it is almost a no-brainer to pick up the right logging level:

• ERROR - A definite problem
• WARN - Likely a problem, but can live with it
• INFO - Common notifications, lifecycle stuff
• DEBUG - Low volume debug
• TRACE - High volume debug

Then, there were those isInfoEnabled(), isDebugEnabled(), isTraceEnabled() performance enhancers that you could call in order to avoid preparing expensive logging output, that is never used. And as a sensible developer, I'd always use isDebugEnabled() whenever I would log.debug(..) any non-trivial stuff.

And all was well, until Adrian deprecated isDebugEnabled() (and isInfoEnabled()), and suddently the build bursted with ugly warnings, and eclipse started showing up those tiny yellow signs next to the slide bar. The code was not clean anymore...

Well, I could understand deprecating isInfoEnabled() (which is almost *always* enabled), but why isDebugEnabled()? Why now? Why me? That was cruel; we grew up with this method, we couldn't possibly live without it :)

Then as I started correcting warnings as I would come across them, by either removing the isDebugEnabled() statement all together, for logging messages that seemed of low-volume and of interest to the user, or turning this to a isTraceEnabled()/log.trace() combo for very detailed developer or high traffic logging messages, it all became clear: isLogDebug() was really not needed!

That was quite a revelation which brought to my mind pictures of Adrian with a "helo" hovering over his head (I've seen Richard Stallman doing this stunt wearing an "ancient" 1-foot hard disk as a helo, preaching his is Saint Ignucious, or something). Yes, Adrian, was telling the truth, and noboby listened (except Scott, of course :)

So now I'm a believer, too, and on top of that, I came to realise (or acknowledge?) that there is an ever better way to think about the log levels: INFO goes *always* to the console, DEBUG *always* to server.log, and TRACE *conditionally* to server.log. (ERROR and WARN are obvious.)

The usage of isDebugEnabled() gave the wrong impression that those debug messages may not be logged, which is rarely true. server.log is a tool primarily for the *users* of the server, to be able to troubleshoot problems and ask for help using informative log traces, from the forums (or the jboss support team of course :). In this regard, it is important that we don't log.debug() excessive information that is of no interest to the user; In other word, server.log size should always be kept relatively small or under control.

Another factor that isDebugEnabled() has been abused is due to the fact that in many cases we (developers) have used DEBUG for high traffic logging, that should really be TRACE. The reason being, we (developers) are usually lazy to enable the TRACE level in log4j.xml while developing, and we prefer to just use debug() instead, that we know it will work by default!

"If the user doesn't like this, she can turn if off", while the idea should really be, "I need to enable TRACE while I do development, and save server.log from being filled up with garbage, and the user from getting lost inside my verbose traces".

Happy Logging :)

dimitris@jboss

It comes without surprise that advanced developers routinely extend JBoss with their own MBean services to do all sorts of interesting stuff. Additionaly, it is often the case that the produced mbean code is of a generic nature, or the developer has come up with a not-so-common use-case for which mbeans are a good fit.

Unfortunately (and this is often the nature of OpenSource), we rarely hear back from them! Wouldn&apos;t be great if we could somehow share the knowledge, or even better, incorporate some of the best ideas back to the JBoss codebase?

Driven by a request from this fellow here, I created a simple entry point in the JBoss Wiki for anyone that wants to share his/her experience with MBeans, or even better, some working piece of generic MBean code.

You may also try the JBoss User -> Management, JMX/JBoss forum as a starting point for discussing your own unique mbean use-case.

See you at the forums!

dimitris@jboss

Most of the presentation slides from JBossWorld can now be found online at JBoss World Recap. There is a lot of valuable information in many of those presentation, so I would highly recommend everyone to have a look at the presentations corresponding to their subjects of interest.

I did a presentation as well, focused around the 3.x/4.x JBoss MicroContainer, under the title "Never Write A main() Again!". The original intension was to show that in most cases in which a server application needs to be created, whether it is EJB based or not, it makes perfect sense to reuse the JBoss MicroContainer (for example, start off with the "minimal" configuration) and just add your own extension in the form of MBean Services, rather than starting from scratch.

The same is true for your normal J2EE application, where you just want to add functionality to the server that is difficult to write using the "standard" J2EE tools (for example, a lightweight adapter to an external system, without the burden of creating a JCA resource).

In any case, the benefit is a very high degree of reusability of components that are really well tested and difficult to write (e.g. the unified classloading mechanism of JBoss that makes hot-deployment possible).

I've been doing MBean services with JBoss for almost 4 years now and while the whole idea is very neat and simple, it is impressive how few people actually know about the existence of this technology and its many uses. Most developers only get to learn about this in one of the JBoss trainings.

We now see the proliferation of various container-like projects coming about as the new "cool" thing, while it is true that JBoss has been doing this kind of stuff since year 2001.

In any case, I tried to distill in just a few slides the really essential stuff that you need to know in order to write your own MBean. This is not rocket science at all, and I usually need 15-20 minutes to get someone up to speed with writing her own MBeans and start extending JBoss in arbitrary ways. In fact, it is often the case that people, after they write their first MBean and see how easy it is, they want to go about and MBean-ize everything :)

Anyway, I hope you find the presentations useful.