Multiple ActiveRecord connections without Rails

Here is a little trick that allows having connections to multiple databases with pure ActiveRecord.

First, a little recap. Here is the code for making a single connection:

require 'active_record'

  :adapter  => 'mysql',
  :database => $env[:db_name],
  :username => $env[:db_user],
  :password => $env[:db_pass],
  :host     => $env[:db_host])

class MyTable < ActiveRecord::Base

The nice thing with this approach is that any additional class will automatically reuse the defined connection.

However, if we need to have multiple connections the approach is a little different:

require 'active_record'

ActiveRecord::Base.configurations["db1"] = {
  :adapter  => 'mysql',
  :database => $env[:db1_name],
  :username => $env[:db1_user],
  :password => $env[:db1_pass],
  :host     => $env[:db1_host]

ActiveRecord::Base.configurations["db2"] = {
  :adapter  => 'mysql',
  :database => $env[:db2_name],
  :username => $env[:db2_user],
  :password => $env[:db2_pass],
  :host     => $env[:db2_host]

class Table1 < ActiveRecord::Base
  establish_connection "db1"

class Table2 < ActiveRecord::Base
  establish_connection "db2"

This approach allows defining any number of database connections and any number of tables on those connection. It also allows adding connections and classes dynamically based on some runtime information. The only drawback is that in each class you are required to define which connection needs to be used.


September 26, 2010 at 2:37 pm Leave a comment

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

Hit 1k reputation on StackOverflow

I’ve hit a 1000 reputation at stackoverflow (my profile here) a few days ago and it’s already up to 1129,  which puts me in about top 5%-10% bracket of users there. Yay 🙂

It’s really interesting how the reputation thing works there.

For those unfamiliar with the site, it basically allows anyone to post programming related questions and then those questions are answered by community. The cool thing about it is that anyone can answer any question, and everyone can also rate answers and questions of other people by up or down voting. Each up vote gives you some reputation, down vote reduces it (but by smaller amount). It’s a great resource as there are a lot of knowledgeable people there and most questions are answered very quickly.

Gaining reputation there is hard because it seems that there are more experts there than those seeking knowledge. It makes sense I think because if you know about that site it already means that you know some stuff about programming, and those who are really clueless won’t know or try to find out about it. Because of this over-abundance of experts finding questions to answer is hard.

There are basically two types of questions there. One is simple generic ‘what are the benefits of polymorphism’ type of question. Almost everyone thinks they can answer those so usually those questions have 5-6 answers within a minute of being posted. The site displays all answers ordered by their rating, so it’s a game of who can get the most reasonable answer fastest because after about 15 minutes no new answer has much of a chance of getting any up votes because it will buried so deep no one will bother looking at it. These questions also usually get the most up votes because many people are interested in those.

The second type of questions is the extremely specific ones – ‘When I use X with Y on Z OS, and I press A with B, I get exception E”. Sometimes those are not answered at all. But unless it’s very esoteric someone will usually know the answer within couple of days, and the answer will usually be rewarded by point or two, because not many will know about the subject to vote on it.

Starting was not easy. The only type of questions you can reasonably expect to answer when you just start there is the specific ones. I think it took me couple of weeks to just get to 100 rating. But with time you get to learn the system, and as your reputation grows you are also more likely to get upvoted so it’s sort of self reinforcing effect. As evidence, it took me couple of days to get from 1000 to 1100 without really trying to. Additionally as you get more and more answers in, you start to get a steady stream of reputation from old answers that people sometimes find.

My next target? 10k 🙂 I wonder how long that would take.

September 2, 2009 at 6:03 am Leave a comment

How to become a rock star developer?

Is it the hard work? Well yeah that helps.

Is it the constant learning? Sure why not.

Will it help to study some other peoples work? You bet it will.

But the real secret – it’s much simpler. Ask yourself…

How many rock stars don’t like playing rock music?

How many rock stars don’t enjoy listening to rock music?

Yes. Exactly.


There were a number of negative comments on DZone so I guess should have clarify what’s this post is about.

This post is a joke, a parody of sorts on all the “X things you need to do to become Y” which are all too common on various blogs. Unfortunately, since I have to explain, I guess it wasn’t too funny to begin with 🙂

Regardless, as Russians say, every joke has some truth in it.

In this case the truth is that you have to be passionate about your work, and that is IMO the most important factor in becoming great developer. When you are passionate about something everything else comes easy and effortlessly because you enjoy extra effort it’s no longer an effort but a fun. When you are passionate about something it rubs on other people too and you gain their respect, people come to you for advice and so on. So indeed one of the key elements to becoming good at anything is to be passionate about it. Perhaps it’s obvious to most of you but from my experience most of people in this business are in it for a paycheck. So by just being passionate you automatically become… well.. “a rock star”.

August 31, 2009 at 5:48 pm 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

Is eye candy underrated?

Suppose you’ve got a new customer request for a feature, or maybe some great new idea by marketing people that will certainly increase sales of your product. Whether you are working in agile or a more traditional environment you are usually going to get a bunch of functional requirements (program should do a,b and c) and sometimes some non-functional requirements (performance targets, security). Sometimes you will also talk about usability – but in my experience you are never going to get “and it must look really really good” as a requirement. Most of my experience is in management systems development, so it is an assumption, but I am willing to guess that in most “business oriented” software eye candy is not a requirement.

You are not your user

You are not your user

I have recently read a great book called “Why Software Sucks?” and the basic idea of the author is that most of the people involved in making software come from very technology oriented engineering background (he uses the word geeks but lets not go there) and so to us everything is an engineering problem. We value technology and features and prefer more functionality over everything else really. So it is more natural for us to focus on features and performance and elegant solutions and mostly ignore usability and eye candy. But there is a catch – “You are not your user“. The things we value may be not the things our users value. And when developing applications we need to focus on what users want not what we think we would want if we were users. There are a lot of examples in the book of what happens when developers do what they think is usable instead of what their users would consider usable, and it’s not pretty.

But what about visuals and eye candy? Is it possible that the same thing happens here as well? Is it possible that while we as developers often consider eye candy irrelevant and even waste of resources, our users actually value it much more?

Well, some evidence is certainly out there. Take video games for example – good looking games with tons of eye candy just sell much much more. Take Hollywood – the big budget flicks with most effects often are criticized for being too shallow – and yet they are the ones that bring the most money and most people go to watch them. And how about Apple which took eye candy to a whole new levels? I have never used macs in my life, but if you ask me which is better mac or pc in terms usability – I would go with Mac.

So good looks sell but what is even more important here is that often good visuals are even more important than actual features. Macs have less software available for them then PCs. Big budget flicks have usually much less substance than independent movies. Most of recent blockbuster video games are just remakes of existing formula with almost no actual gameplay improvement.

So, yes, I believe that eye candy alone is worth a lot more than we usually think it is, even for applications that are not mass market oriented. (quick test, which bug tracking software is better: bugzilla or jira?). It’s great for first impression and thus sales and it’s great for continuing user satisfaction and thus retaining customers and creating word of the mouth hype. Features and usability alone are not enough anymore – your users demand that it also  must look really really good.

April 13, 2009 at 9:20 am 1 comment

Older Posts


  • Blogroll

  • Feeds