Tuesday, November 5, 2013

The demise of Glassfish is a great opportunity...for you to discover Dropwizard

Perusing through my Java RSS feed this morning, I saw a couple of posts about the death of Glassfish since Oracle has removed commercial support for it. And the predictable lament of how Oracle is hurting the Java community.

The reality is that this is a good thing.

In 2013, no new Java server-side project should use a stand-alone servlet container or application server.  You should all be using Dropwizard instead:

http://dropwizard.io

If you need to wrap your app in a WAR file and drop it somewhere else to be run, then you are doing the wrong thing.

Node.js programmers don't wrap their servers in any sort of WAR file equivalent. Neither does Go (all of Google Downloads runs directly of the Go standard net/http library), nor Python (Twisted/Tornado, etc). They all run their web apps directly, running production grade HTTP libraries. Nothing stops Java programmers from doing the same...and Dropwizard makes it happen.

We have been using Dropwizard for all of our applications for about a year now. Our apps restart instantly while coding (none of this compile to WAR, redeploy WAR nonsense any more).

The productivity boost is huge. Dropwizard adoption has spread like wildfire at my company, pretty much every team that has been exposed to it has ditched their stand-alone Tomcat instance and started converting.

I've prepared a simple set of slides (for a talk I've given at the JUG and the Houston TechFest 2013) on why Dropwizard is the greatest thing to happen to Java since Lombok and Lambdas:

http://www.slideshare.net/JacekFurmankiewicz/dropwizard-spring

I also have a sample app that shows how to integrate Dropwizard, Spring, Spring Security, test it with Cucumber BDDs and wrap it in RPMs or DEBs to easily deploy as daemons on Linux:

https://github.com/jacek99/dropwizard-spring-di-security-onejar-example


Leave the legacy of WAR behind...once you try Dropwizard, you will never go back.

It is the future of Java server side development...today.


Wednesday, May 8, 2013

Fixing menu editing in XFCE on Fedora 18

Having recently switched to Fedora on one of my machines, I installed the XFCE remix. It works wonderful with Compiz and restores Linux desktop to its proper traditional glory :-)

However, the 'Edit Main Menu' functionality is broken, since it relies on a GNOME package that is not installed by default. If you press on 'Add New Item' in the menu editor nothing happens...but this error shows up in the logs

  File "/usr/lib/python2.7/site-packages/Alacarte/MainWindow.py", line 276, in on_new_item_button_clicked
    process = subprocess.Popen(['gnome-desktop-item-edit', file_path], env=os.environ)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
All you have to do is to symlink the missing GNOME app to its XFCE equivalent and everything works again
cd /usr/bin
sudo ln -s exo-desktop-item-edit gnome-desktop-item-edit
And everything works again. Alacarte will now open the XFCE menu editor for menu items.

I can add my favorite IDE directly into main menu again :-)