Posts filed under ‘Open Source’

HOWTO: Suppress EJBTHREE-1337 warning

If you are running JBoss 5.X with JBossWS there is an annoying warning that is printed each time a web service is called that looks like this:
EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

First of all, don’t get alarmed – there is no actual problem. The warning is targeted at the framework developers and not at the end users – all it means is that JBossWS is using a recently deprecated API which still works. There is nothing end user can do to fix this and it doesn’t matter anyway since everything just works.

The problem however is that the warning clutters the log file and makes debugging harder than needed. It is easy to suppress it though and I will show you how.

First, locate jboss-log4j.xml file which should be found under ${JBOSS_HOME}/server/default/conf. If you are using a runtime configuration other than default, locate the file under configuration that you actually use. This file is used to configure logging output of the JBoss.

Inside the file search for “Limit categories” – you should find a list of <category> definitions. Edit it to look something like this:

   <!-- ================ -->
   <!-- Limit categories -->
   <!-- ================ -->

   <!-- Suppress EJBTHREE-1337 warning -->
   <category name="org.jboss.ejb3.stateless.StatelessBeanContext">
     <priority value="ERROR"/>

You are basically telling JBoss to suppress any WARN or lower messages from the class that generates those warnings. Now just restart JBoss and the warning should disappear.

September 14, 2009 at 10:58 am 1 comment

HOWTO: Simple profiling with Spring AOP

As part of its AOP package, Spring has a very nice little utility class called CustomizableTraceInterceptor which can be used to easily profile and debug your application using automatic logging of method invocations, including name of the method, parameters (using toString()), return values and invocation times. It doesn’t replace proper debugger and/or profiler but it can provide you a lot of interesting data with minimal cost. It can be even used in production as it can be turned on/off easily.

So how does it work? It uses Spring AOP capabilities to wrap around beans you choose to add a little code that will output invocation data before the method is called, and will output return values and execution time after it finishes. The best practise it to apply the interceptor on client facing beans – in other words entry points of your server so you can easily monitor what is called, when it’s called and how long did it take.

So how to add it? First thing you need to define a subclass of CustomizableTraceInterceptor like this:

public class MyTraceInterceptor extends CustomizableTraceInterceptor {

  protected void writeToLog(Log logger, String message, Throwable ex) {
    if (ex != null) {, ex);
    } else {;

 protected boolean isInterceptorEnabled(MethodInvocation invocation, Log logger) {
   return true;

By overriding writeToLog() method you control output severity and destination. Overriding isInterceptorEnabled() allows you to finely control when tracing should happen – you could for example decide not to trace methods that start with “foo*”. Simply returning true means trace always.

Now that you have your interceptor defined it’s time to apply it to your beans. Add this to your spring.xml

    <bean name="traceInterceptor" class="MyTraceInterceptor" dependency-check="none">
        <property name="enterMessage" value="ENTER: $&#91;targetClassShortName&#93;.$&#91;methodName&#93;($&#91;arguments&#93;)"/>
        <property name="exitMessage"
                  value="EXIT: $&#91;targetClassShortName&#93;.$&#91;methodName&#93;() : $&#91;invocationTime&#93;ms : $&#91;returnValue&#93;"/>

    <bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator" dependency-check="none">
        <property name="beanNames" value="*RequestListener,*Notifier"/>
        <property name="proxyTargetClass" value="true"/>
        <property name="interceptorNames">

        <property name="order" value="2"/>

First definition instantiates the interceptor and defines format of the trace messages.

Second bean applies the interceptor to your beans using “beanNames” to select the beans with the wild card. If you use “*” it will mean it will wrap all your beans, so you probably want to input something meaningful here.

And that’s it. Rerun your app, call some methods and open up log files. You will see the traces there.

September 2, 2009 at 8:48 am Leave a comment

HOWTO: Run tests with Embedded JBoss

I’ve needed to create an environment for running unit tests on EJB3 JBoss application this week. There were few GOTCHAs so for the benefit of future generations here is a simple recipe for running your unit tests on Embedded JBoss.

First a link to Embedded JBoss wiki page. You can find some information there. Also download the latest version (I used beta3.SP9) from there. We are going to use Maven to get the jars but you still need the configuration files from the download.

Ok, lets setup our maven dependencies.

First define repository if you don’t have it yet:

   <name>Jboss Repo</name>

Now add actual dependencies for embedded jboss:





Now lets create a test class. It will look just like your normal test class but you need to add the following method to start and deploy JBoss

 public static void startJboss() throws Exception {
   Bootstrap bootstrap = Bootstrap.getInstance();


Two things happen here. First, bootstrap() method launches Embedded JBoss with basic configuration. With standard JBoss it would be enough since it would automatically deploy all ears. In this case though, we need to explicitly tell it what to deploy – that’s what deployResourceBase() command does.
Now that you have Embedded JBoss starting and deploying before your tests, you can write any code that tests those beans. For example:

 public void testMe() throws NamingException {
   InitialContext context = new InitialContext(); 
   MyBeanLocal bean = (MyBeanLocal)context.lookup("MyBean/local");

And now the GOTCHAs.

First for JBoss to run it needs some configuration. Remember that zip you downloaded? Open it up, find bootstrap folder inside and then copy entire contents of that folder into test/resources folder of your maven module. That’s the basic configuration. If you want something additional, like your own datasource, you can add it into the test/resources/deploy folder as you would normally add it to deploy folder of standard JBoss.

We are not done yet. If you are running on Java 6 and the chances are that you are, it will still not work. You must add the following JVM property to your unit test configuration to force JVM to run in Java 5 compatible mode: -Dsun.lang.ClassLoader.allowArraySyntax=true

And the last thing –  if you are running from IDE you are probably deploying from exploded classes folder and not from packager jar/ear. If so, there is a good chance that Embedded JBoss will fail because it won’t have enough file handles to properly deploy your classes. To fix it on Linux use ‘ulimit -n <some large number>’ to increase the number of file handles. On windows look up your own solution.

And that’s it. You now have working Embedded JBoss test environment. Congratulations 🙂

public void testMe() throws NamingException {
InitialContext context = new InitialContext();
MyBeanLocal bean = (MyBeanLocal)context.lookup(“MyBean/local”);

August 20, 2009 at 9:03 am 6 comments

The five minute rule

It seems sometimes people just completely miss the point, even the brightest of them. Yesterday I was doing some prototyping for some new project I am working on which is based on JBoss EJB3 implementation, and since most of my background comes from Spring based project, I was looking for some answers. Nothing too complicated, mind you, I just needed some way to have one of the EJB beans to hold some shared state for all the application, something that is really straightforward in Spring, and something that I assume most of the applications out there today need at one point or another.

So, since I am no JBoss expert (yet :)) I did the sensible thing and tried to google it. Well, simple queries didn’t find anything for me (“jboss service”, “jboss singleton”, “jboss ejb singleton” etc), but in the end I stumbled upon something called @Service annotation which is a proprietary annotation of JBoss and can be used for this kind of stuff. Which is documented in this page. Which is while it is couple of pages long and have some code examples lacks one very basic thing – it doesn’t show how to use the thing in the simplest and most common use case, the one I was actually looking for. So instead of just copying and pasting the sample into my code and just running it and continuing to some other stuff I had to spend about an hour trying to figure this stuff out. (BTW the solution turned out extremely simple, elegant and it doesn’t require any of the stuff that is printed on that “help” page – I will put it in a separate post for others to reuse)

Which is why I think some people just don’t get it. I mean they are great developers and the eventual solution is really great and working flawlessly – but they miss the most  important point. Open source frameworks and projects that provide infrastructure are just tools that allow us developers to solve some common problems. The reason these things are actually used (and not reimplemented in house) is that they provide solutions without the need to really go deep and understand all the implementation issues. When I write some application for an end user any time spent on figuring out some stuff that should have been in the manual is time not spent on providing value to my customer.

And this is my main point – you must know who your customer is. It just doesn’t work otherwise. And if you develop open source project that is going to be used by other developers – your customers are  those other developers, usually the ones working on end user oriented software.  This is not about who got the coolest implementation or the tightest algorithm or the most generic platform. This is about providing simple solutions to most common problems. And the reason why you should care is that even though we are not the ones paying your bills  – your success and success of your project is directly proportional to its adoption rate. And guess where that adoption rate comes from.

Here is an example of project that does get it – Terracotta. It will take you less than 5 minutes to understand what it does and what problems it solves. And if you decide to try it out, it will take you less than 5 mintues to download and run an interactive sample of the technology (which is very cool by the way). Compare that site with site for JBoss Microcontainer which is the core of the new JBoss 5 release. I assume it is really good piece of technology but try to spend only 5 minutes on their site and try to understand what it does and whether is solves any of your problems. I couldn’t. And if I was really evaluating it I would just discard it at that point and go look at the next thing. Because there is always another thing (competition is great isn’t it?).

So here is my 5 minute rule – make sure your site and documentation can provide some initial idea of what problems you solve in less than 5 minutes. Make sure that for the most common problems the solution (including examples or better yet cookbook style recipe) is no father than 5 minutes away. Otherwise you are just not competitive with the projects (which by the way may be less technologically advanced) that do provide those answers. Take a look at the success of Spring Framework. Take a look at the success of Ruby on Rails when they took the world by storm using that video of creating a blog application in under 15 minutes. They did it despite the many technological problems that they had (like native threads and performance). This is really fast world. Help yourself by helping me quickly. Otherwise no one will care.

April 7, 2009 at 6:12 am 5 comments


April 2017
« Sep    

Posts by Month

Posts by Category