Revising my opinion about Spring Framework

In past, at comm.world (Germany), I worked with projects based on Spring. At that time, I built my opinion about the framework: useless. It had nothing you couldn’t do without it. Everything that came with Spring could be done in simpler ways: PicoContainer or plain constructor injection for IoC/DI, plain decorators, dynamic proxies or Servlet Filters instead of AOP for the same results, WebWork simpler than Spring MVC, …

Some time has passed and, influenced by some friends in our endless discussions about Spring, I’ve decided to give it another try and I’ve started to refactor the VRaptor Web Framework, changing it to be fully Spring-based.

After this experience, I must admit: I was a bit wrong. I am going to explain it better, but I think the best part of Spring is that it already comes with many things done, ready to be used; out of the box. Furthermore, Spring 2.5 is much, much better.

Now, I have the sense that Spring brings some complexity, compared to lightweight alternatives; but not that much. This is the cost for the benefits the framework introduces. It is extremely flexible, supporting many different programming styles and idioms. I would be able to completely rewrite VRaptor to use Spring building blocks. Most of the current frameworks could be changed to be Spring-based, with little influence in their current APIs and programming styles!

People has already (re)implemented Google Guice on top of Spring. The EJB3 programming model (@EJB, @PersistenceContext, @Stateless, @Stateful, @Resource, …) can be easily replicated on Spring applications (old – 2005 – article that may be done better nowadays). One could even provide an EJB3 implementation on top of Spring, JBoss Seam could be rewritten on top of Spring and even PicoContainer could be Spring-based.

My current opinion is that Spring is a truly framework, in its original sense, because it acts as a solid base for applications to be built on top of it, without imposing any programming model, style or idiom. You aren’t required to use XML, Spring classes and even Spring annotations. The little bureaucracy comes with a bunch of ready functionality to be used, and with the great flexibility the framework has to be extended.

Today I can say I would consider using Spring Framework for new projects. I even consider it to be a good candidate to become one or more JSRs. It is a great base for applications and other frameworks to be built on top of it. Rod Johnson is a member of Java EE 6 Expert Group, which could point things to something in this direction.

jetty_rails at RailsConf 2008

Jeremy Kemper talked about jetty_rails in his keynote at RailsConf 2008. Wow!

jetty_rails at Jeremy\'s keynote

In the same keynote, Jeremy also made the official release of Rails 2.1. Unfortunately, I couldn’t go to RailsConf this year, but I hope to be in the next!

I’m extremely excited about this. Thanks to Nick Sieger (who talked to Jeremy about jetty_rails) and Fabio Akita for the photo and great news.

JRuby and autotest (ZenTest)

JRuby 1.1.2 is going to be released (probably) today and it fixes a bug with $~ constants (Regexp.last_match), which made autotest finally work!

jruby -S gem install ZenTest
cd myproject
jruby -S autotest

I’ve previously submitted a patch to ZenTest guys. It makes the use of autotest possible with any JRuby 1.x, but now, with JRuby 1.1.2, autotest should just work out of the box!

jetty-rails 0.4 is also jetty-merb

I’ve just released a new version of the jetty-rails gem. Now, you can also run Merb applications inside JRuby and Jetty!

jruby -S gem install jetty-rails
cd mymerbapp
jruby -S jetty_merb

Unfortunately, it’s blocking my console (ctrl + c doesn’t terminate it). Has anyone suggestions on this?

I’ve also updated the basic documentation, as you can see here.

The Merb support was actually done in JRuby Rack. It was quite simple to support it. Many thanks to Nick Sieger, Dudley Flanders e cia!

jetty-rails gem – Simple JRuby On Rails Development with Servlet Containers

This is the first time I’m writing about it, but jetty-rails is already 0.3!

Most people doing JRuby on Rails development are using JMongrels1 for development and some real Java Application Server in production.

The common flow is:

$ jruby script/server 
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...

code, code, test, code, code, test, … (shouldn’t it be red-green-refactor?)

$ jruby -S warble
$ cp myapp.war $TOMCAT_HOME/webapps
$ $TOMCAT_HOME/bin/startup.sh

Sure you can automate those things with ant, rake, sake or anything else. Some people are still using the goldspike-plugin, but be warned: I suspect it won’t get much more attention.

The great Warbler from Nick Sieger is becoming the de facto standard for JRuby on Rails packaging. The Warbler’s recent move from goldspike to JRuby-Rack adapter reveals two interesting points:

  1. Goldspike is likely going to be deprecated (or merged with jruby-rack adapter?).
  2. Warbler will soon package any rack compatible application to be runned inside Java Containers. Such applications include Merb, Sinatra, Vintage, Camping ones, and growing

Although Warbler works really well, it introduces complexity in the development cycle. You can no more save code and immediately test it in your browser:

  1. change code;
  2. warble it;
  3. deploy war file;
  4. restart server; (takes long time)
  5. open browser;
  6. change code;

It breaks one of the most important rails development characteristics: instant feedback. During development, it’s very important to see changes without have to wait for server/context restarting.

JMongrel and Glassfish Gem are good candidates for JRuby on Rails development with instant feedback, but you can’t use Java (Servlet specification) specific features, such as web.xml; they aren’t complete Servlet Containers. Some things have an alternative in pure-rails as Servlet Filters and Servlet Listeners, but many haven’t. Servlet Context might be a good way to share things between rails runtimes. I know railers should “share nothing”, but -hey- sometimes it’s so good to share!

You can take the Servlet Application Context as your in-memory cache store (fragment and page caching), eliminating the need for filesystem or database overhead and even memcached, in many cases.

I had also a specific reason to share the same HttpSession between Rails and “pure Java” applications. Single sign-on wasn’t an option, so I needed to run both applications in the same context. I’m going to tell more about it soon.

Anyone can fall in cases, like mine, when you just can’t use jmongrel or glassfish_rails. Now, we fortunately have jetty-rails to rescue!

It’s a (one more) gem to run rails applications, based on the nice JRuby-Rack adapter, which I recommend you to take a look. Jetty is a very powerful Servlet Container, known for being pioneer at being embedded and at using NIO Connectors.

The gem creates a Jetty Server with two Handlers. The first is for static content and the last to serve dynamic requests using JRuby-Rack. These handlers are applied in order and request processing stops when one responds. That way, no rails code is runned to serve static content, improving response times. Take a look at the rdocs for more details.

Jetty is also very quick to start. I’ve measured (in a complete inaccurate way) some start times just for ugly2 comparison:

$ jruby -v
ruby 1.8.6 (2008-03-28 rev 6360) [i386-jruby1.1]
$ time jruby script/server
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
...
** INT signal received.
Exiting

real	0m13.947s
user	0m11.327s
sys	0m0.892s

$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
$ time ./script/server 
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
...
** INT signal received.
Exiting

real	0m6.273s
user	0m1.893s
sys	0m0.611s

With the same JRuby 1.1 (and without Charles recent speedup patch for jruby startup):

$ time jruby -S jetty_rails
2008-05-04 10:50:00.846::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
2008-05-04 10:50:01.013::INFO:  jetty-6.1.9
...
2008-05-04 10:50:02.987::INFO:  Started SelectChannelConnector@0.0.0.0:8080

real	0m7.035s
user	0m4.387s
sys	0m0.296s

As you can see, jetty_rails is very close to mongrel running in MRI, but please, don’t take those numbers so seriously.

Jetty Rails should be ready to run any rails application (tell me otherwise!) with no dependencies on extra jars. All gems used by the application must be installed in your JRuby. I’ve made some simple benchmarks with JMeter and only one thread, firing 500 consecutive requests to a simple rails blog application. All requests pointed to ‘/posts’ controller, and there was only one Post is the MySQL database.

The machine used to run all tests is a Intel Core2 Duo E4500 @ 2.20GHz, 2.0GB RAM, running Ubuntu 7.10, Ruby (MRI) 1.8.6 and JRuby 1.1.1. MRI tests were done using plain ruby activerecord-mysql-adapter and JRuby tests were done using activerecord-jdbcmysql-adapter.

Mongrel: 30.7 req/s
JMongrel: 19.1 req/s

Glassfish Gem: 17.5 req/s
dropping JVM warm time: 23.8 req/s

Jetty Rails: 18.2 req/s
dropping JVM warm time: 26.6 req/s

This is obviously a simple measure, just to feel how jetty-rails is going. But I’m very happy with the results. If we ignore the time that JVM takes to warm and JIT compile things, jetty-rails comes close to Mongrel! Impressive. I knew Jetty was always very fast, but I really didn’t expect those results.

There is much more to do. Things from the roadmap I wanted to see working soon include:

  • read warble.rb configuration files and register extra jars and public folders defined there;
  • use any custom web.xml defined in config/web.xml (or config/web.erb.xml), following Wabler conventions.
  • jetty_merb
  • jetty_camping

The source code lives in GitHub. Feel free to fork, contribute, send patches and suggestions!


  1. Can we stop calling everything that comes from Java with that damn J-at-start or with –let termination? ๐Ÿ˜‰
  2. I’ve stopped the processes (ctrl+c) as soon as I saw they were ready to respond to requests.

Word Movement in OS X Leopard Terminal.app

Word movement in OS X Leopard Terminal.app is a pain! After long time searching, I must keep the solution documented here.

I’ve been searching for a long time, how to fix home/end keys and how to jump words. In every OS X application, cmd + arrows and option + arrows would do the trick, except Terminal.app. I had once fixed it for OS X Tiger, but I couldn’t remember how…

Finally, I’ve found it. Thanks Textmate guys!

My choice is for fn + arrows (home/end) to begin/end of lines and ctrl + arrows to jump words. Fire your Terminal.app, hit cmd + , (yes, period); the alternative is Terminal -> Preferences. Go to Settings area, then Keyboard tab. Edit your combos as below:

Terminal.app keyboard settings

The trick is the code \033b. It is produced through esc (\033) + b and represents “move one word backward”. Forward movement is esc + f, home is ctrl + a (\001) and end is ctrl + e (\005).

Servlet Event Listeners: Did you know?

… you could automatically register any number of servlet event listeners (ServletContextListener, HttpSessionListener, ServletRequestListener, and more …) without any additional web.xml line?

The Java Server Pages 2.0 specification dictates that all .tld files inside META-INF directories, from jars in the web application classpath (WEB-INF/lib), must be read and parsed by the Servlet Container (JSP.7.1.9 – Event Listeners).

Fortunately, .tld files accept the <listener> element. What about creating reusable jars (web frameworks?) and do their setup inside such listeners, as Sun JSF RI (Mojarra) is doing:

<!-- jsf-impl.jar!/META-INF/jsf_core.tld -->
<taglib xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"
  version="2.1">

  <description>
    The core JavaServer Faces custom actions that are independent of
    any particular RenderKit.
  </description>
  <tlib-version>1.2</tlib-version>
  <short-name>f</short-name>
  <uri>http://java.sun.com/jsf/core</uri>

  ...

  <!--
    This ServletContextListener initializes the runtime environment
    of the JavaServer Faces Reference Implementation when a web
    application including it is initialized by the container.
  -->
  <listener>
    <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
  </listener>

  ...
</taglib>

That said, why am I still having to add <listener> from web frameworks in my web.xml?

RejectConf SP’07 and Conexao Java 2007

RejectConf SP'07

It was a great time last weekend, spending part of my holiday at RejectConf SP’07 in Brazil, “our first relevant conference”, as said by Fabio Akita.

Attendees

The lectures were really great and the coffee-break (thanks Caelum) really came on the right time. During his RSpec talk, Danilo Sato created a web application to rate the presentations. As you can see there, the coffee-break shined. It was a pleasure to meet new people from our community and to see old friends.

I talked about the most fantastic project nowadays and fortunately people seemed very interested about it. Get the slides.

RejectConf SP'07

One week before (10 Nov 2007), I was at Conexao Java 2007 and gave a mini-course (~6 hours) about JSF, Ajax and Richfaces. Great time too, thanks to all attendees!

You can get the slides and code here. More info at the Caelum Blog (pt-BR).

Comments to Gavin King about DDD and Repositories

I was replying the Gavin King’s question about Repositories and DDD, but the comment started to become really big and I wasn’t sure if the code snippets would be well formatted. So, I decided to reply it here.

I had similar questions about Repositories. I’m from Brazil and we have discussed it many times here (see at GUJ and at my post in the Caelum Blog – unfortunately – in pt-BR; perhaps, translation tools can help). I have a personal and pragmatic conclusion that may help.

I won’t discuss if DDD is good or not, but I will suppose it is. The root problem is the way that DAOs are being used. In the classic Client --@OneToMany--> Order, if it is given a client (id=1) how could we get his orders since 10/10/2006?

Almost everyone would do dao.findOrdersFor(client, since), but that is clearly procedural (actually, not always a bad thing). What I wanted to do is client.getOrdersSince(date).

Now, suppose I love DDD and really want to do client.getOrdersSince(date). The client should be able to give its orders, that’s the “DDD-way”. How could I implement it? Load all orders in memory (maybe a regular @OneToMany mapping) and then filter what I want (bleh!) isn’t an option. One option would be as below:

class Client {
  private final ClientDao dao;
  Client(ClientDao dao) {// ioc here...}
  public List getOrdersSince(Date date) {
    return this.dao.findClientOrdersSince(this, date);
  }
}

Hmm… what about separation of concerns? DAOs are related to persistence, and persistence is infrastructure, not domain (or business related).

This is what repositories try to solve. They are a domain concept, from where we can get other domain objects. To be “DDD-compliant”, I would do:

class Client {
  private final OrderRepository orderRepository;
  Client(OrderRepository repository) {// ioc here...}
  public List getOrdersSince(Date date) {
    return orderRepository.findForClientSince(this, date);
  }
}

But err… what’s the difference? Just the name? YES! But the names are important, right? ๐Ÿ˜‰

Actually, some people would rather Repositories as interfaces, and Daos might be their implementations. What really matters is that domain objects shouldn’t have to deal with infrastructure things like persistence. A Repository has nothing to do with persistence, it’s a domain concept. Lists and Maps (any container) are repositories too.

I also rate the idea to have more layers (completely agreed with you):

Client -> OrderRepository(just an interface) -> OrderDao -> Hibernate -> ...

I would just drop the indirection and make the Repository concrete:

Client -> OrderRepository -> Hibernate -> ...

Duh. You can ask: “have you just renamed the Dao?” I would say: “yes, but aren’t the names important?” ๐Ÿ˜‰

Remember why I did it. I wanted to do client.getOrdersSince(date) and the client shouldn’t know anything about persistence. He doesn’t care if the repository is just a plain list or use hibernate. Repositories are domain objects, daos aren’t.