How to: implement singleton EJB in JBoss

As promised in the rant post – here is the simple and elegant way of creating a singleton bean in JBoss.

public class MySingletonBean implements MySingletonLocal {
  private Object sharedData = new Object();  

  public void workOnSharedData() {
    // TODO do your things here


As you can see, it’s really simple and it looks exactly the same as the @Stateless bean definition except that you replace it with @Service annotation. In order for this to compile you must link with jboss-ejb3-ext-api.jar (found at JBOSS_HOME/common/lib/ directory) during compilation because that annotation is proprietary for JBoss.

Ok, we have the bean – but how we can use it? Well, that’s even easier – just use @EJB annotation the same way you would use it for any regular stateless bean.

public class SingletonUserBean implements SingletonUser {

    @PersistenceContext private EntityManager em;
    @EJB private MySingletonLocal mySingleton;

     // ..... the rest of it


And that’s it – everything will be properly injected for you by the container.

I’ve tested this solution in the JBoss 5.0.1GA – it is supposed to work with older versions as well, but you should try it yourself.

One last note – starting from EJB3.1 spec they are adding @Singleton annotation which is going to be the standard solution for these types of problems. One of the nicer things about it is that they are also adding synchronization support with annotations so we wouldn’t have to deal with it manually (the hard part of singleton beans like that is handling the concurrency issues since it’s shared for all application). And even though it is not part of the spec it is assumed that the new @Singleton beans will be shared in the cluster – so if you have few application servers for high availability or load balancing, you will be able to use this technology to share state between them (for example counting requests for the cluster and not just sinlge server). See more details here.


April 7, 2009 at 7:59 am 1 comment

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

Art of Organizational Refactoring

I am doing some thinking about what it takes to implement Scrum in an organization that is not used to or even familiar with agile concepts, let alone Scrum. When you start a new team or a new company implementing new methodology is rather easy – you select people based on what you believe the required roles and functions are, there is no legacy to overcome and everybody is open to whatever process you are installing. There is no inertia, there is no resistance and there is no conflicting interests you need to account for.

Of course the exact opposite is true when you are attempting to implement Scrum (or whatever else) in an organization with strong waterfall culture. It’s not just about telling people about how in Scrum you do so and so, go to this meetings, here is how product backlog should look like – and then you are done. It is much more challenging because of “that’s not how we are used to do things around here” – so not only you have to be able to teach what Scrum is, but also be able to overcome years of practise of doing something else.

And that is not the hardest part. It is impossible to make all the changes overnight – this stuff takes a long time to get absorbed and interned and used to. So there is going to be some time where organization is not going to be very “organized” for the lack of better word. And yet, there are customers and sales and support and contracts that need to be taken care of, and that cannot be “pushed back” until we can figure out how to do the Scrum stuff properly.

And this brings me to the concept of refactoring. In software engineering, refactoring is the art of taking an existing piece of software that maybe is using some old technology that is a bit obsolete by now, or maybe it is written in somewhat inefficient way and taking that piece of software and rewriting it in such a way that from the outside it keeps looking exactly the same, performs exactly the same function (but better) while inside it gets completely overhauled and made more efficient, with less bugs and easier to maintain. And I call it an art because yes there are some practices and tricks which help you do that refactoring, but in the end, every software is different and what might have worked on a previous project wouldn’t work on the next one, so to be able to do this and succeed requires some flexibility and creativity.

And I think similar art form should be developed for implementing Scrum in organizations that are currently stuck in the old ways. The similar challenges apply – keep the outside interface, support clients, make the sales, while in the same time transforming the entire organization to much more efficient, flexible and adaptive proceses. And yes, even though some techniques are probable shareable, in the end every organization is different and it will take each one a unique path on its road to agile success.

April 5, 2009 at 8:08 am 3 comments

Relative Creativity

I read this post by Seth Godin and it is a really interesting and different way of looking at the creative process.

Seth describes creativity as something that is done on the edges of a comfort zone. The real interesting part of it though is that a comfort zone is very personal and individual thing – nobody can have experience in everything in this world, so for every one of us we have our areas of comfort where we have a lot of experience and knowledge and huge space of unknown around it. Which means that what I consider extremely creative may be extremely boring “more of the same” stuff for someone else, and vice versa. I am a Java application person professionally so when people around me talk about embedded programming it seems very fresh and strange and exciting – and it probably is the same way the other way around.

The practical advice out of this is that it is important to try to expand your comfort zone beyond what is considered “standard” for your job description. If you are a J2EE person try to learn some Groovy. Or Lisp. Or automatic tests. Or whatever else. You may not become world’s leading expert on X, but that’s is not the goal anyway. You can become a relative expert, “Best Y and X” person, and that is extremely valuable. At the very least it will get you some insights and ideas which will help you become more creative in your field.

February 9, 2009 at 7:34 am 1 comment

Conflicting levels of interest

As you may know, the company I work for was acquired by one of our American competitors.

So last week we had a marketing team arriving from US, in order to interview all the different projects we have right now and decide whether they are interested in them or not. We had some early “intelligence” saying they were really interested only in a couple of projects, because there is a lot of overlap between what we do and what they do, including the project I work for. Still, we tried our best to prepare great presentation and demo of our product. Our “angle” was that while yes, the products are superficially similar, there is a different positioning for them – like how you have Mercedes and Toyota making cars but targeting different markets.

So we met them on Thursday and what we got was more or less this:

Not Interested

Not Interested

There were 4 people on the team we met – after introduction, 2 of them immediately pulled out their smart phones and started playing with them – basically ignoring us and not participating for the full 2 hours of the meeting. Another person was on and off, showing some mild interest, and the last one was actually trying to follow and ask some questions.

Now the point of this is not to complain or whine or whatever. They are the buyers so regardless of how we feel about our projects it is their right to decide that they do not care. It maybe their loss, or they actually may be right about not caring – it does not matter.

The point is that in order to actually communicate with someone about any topic – you need to have similar “level of interest” in the topic, without which no matter what you do you won’t be able to connect. Imagine a thirsty person in a desert and someone who just drank couple of litres of water – that’s what it was like in that room. We were very interested in the outcome and our project – they could not care less and were more interested in getting that over with. No matter what we or they were saying we could not get any connection. I mean even if Steve Jobs was presenting our stuff I don’t think he would have any success.

So I guess the lesson for me was that it is important to understand the ‘level of interest’ in the topic of other person when trying to talk about it. And if those levels do not match – there is no chance you can succeed. We weren’t able to create or find any interest in those people at that meeting – and thus no amout of cool demoing could change their mind. You won’t sell the refrigerator to the eskimo – unless you realize it’s warmer inside 😉

January 10, 2009 at 12:06 pm 1 comment

Merger fun

The company I am working for was just acquired by one of our competitors. Not too many details are known for now, except that in a few days an integration team from the new owners will come over and start “the integration process” that will lead eventually (couple of months time frame) to the restructuring and merger.

Naturally, everyone right now is trying to find ways to “market” themselves to this integration team. For my team, one of the issues is that we are using Scrum, while according to rumors the new owners are hardcore waterfall people. Having worked with waterfall before I am sure I wouldnt want to repeat that experience. On the other hand, perhaps there is an opportunity here to interest the new guys in this wonderful world of agile.

I am wondering if anyone have experienced such a situation before, and if so, if there are some strategy that should be employed. I would appreciate any advice and/or tips on how the best to handle this. In any case, I will update this blog once we know more (and if it’s not confidential). For now, it’s time to go work on the “integration backlog”.

Happy new year everyone 🙂

December 31, 2008 at 7:15 am Leave a comment

The original agilist

Back in 1991 this message was posted to comp.os.minix USENET board:

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.  This has been brewing
since april, and is starting to get ready.  I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want.  Any suggestions
are welcome, but I won't promise I'll implement them :-)

               Linus (

PS.  Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

For me, it showcases all agile values in just one short message. People and collaboration are more important than process, working software is more important than documentation, customer collaboration, reacting to changes rather than planning ahead.

Why this specific message? Well, some of you probably recognized or guessed it already, but for those that have not seen it before: this is the original announcement of Linux operating system back in 1991 (taken from here). Yeah, THAT Linux.

So, don’t beleive the gurus or agile trainers. Look at the source. Learn from its success. Decide for yourself.

November 27, 2008 at 7:44 am 1 comment

Older Posts Newer Posts


  • Blogroll

  • Feeds