Geronimo First Impression

I just installed Geronimo for the first time. I wanted to run Hudson and I'm a bit tired of Tomcat for many reasons. I could have used Jetty but I really wanted to try Geronimo.

Installation was quite easy. You just decompress the installation package in a folder and they you run it. First thing first, I changed the password of the system user (the default admin user) to something other than manager. It's still amaze me, that the default installation uses a default user/password for administration purpose.

The next step was to deploy the Hudson WAR file. So I went to Geronimo admin console and I click on the Application/Deploy New. There your are presented with a simple screen asking you for an archive to deploy and a plan. The plan is optional. So I put my hudson.war in there and click Install (shouldn't it say Deploy?). Bang! I got back an error message with some stack trace. It seems like I need a deployment plan to deploy (or is it install) this application. But there is no hint whatsoever as to what I should put in there.

My guess was that I needed to specify some security-role mapping and configure one of the environment entry for Hudson.

After some search in Geronimo documentation, I found out that I needed the following deployment plan to successfully install Hudson :

<?xml version="1.0" encoding="UTF-8"?>
<web-app

xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1">

<security-realm-name>geronimo-admin</security-realm-name>
<security>

<default-principal>

<principal name="anonymous" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</default-principal>
<role-mappings>

<role role-name="admin">

<principal name="administrators" designated-run-as="true" class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
/>
<principal name="root" class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
/>

</role>

</role-mappings>

</security>

</web-app>

This is not what I call something that is obvious, especially for the <principal .../> thingy.

And by the way, there is no way to configure any <env-entry> in your wen.xml with some other value. So you have to edit your web.xml before deploying your application if you want to change these.

Now, how could this be improved? First, if the administrative console does not provide a wizard or something to specify what is needed to properly configure the application (like it is on Geronimo), then the application server should first report meaningful error messages (instead of meaningless stack trace). Another proper of handling this kind of things would be to provide a sample deployment plan with all the elements that must be specified for the application being deployed.

Even with the EJB 3.0 specification, it seems that we are far from escaping the XML configuration hell of J2EE.

Better, I believe we should reverse the roles of application servers. Instead of deploying an application on an application server, we should bundle the application server with our application and run it like any other application. I will expand this thought in a soon to be published blog entry.

So my first impression of Geronimo? It's not most difficult to install than Tomcat but could provide better error reporting when deploying application. The deployment plan should also be simpler and more intuitive or else provide a configuration wizard.

Raven + JRake == Raven

It looks like the Raven and JRake are merging! New name is... Raven. This is really good news. It looks like one of my 2007 prediction is getting shape :-D

Congratulation to Matthieu Riou and Matthew Foemmel who are merging their effort to bring us what may become the best build tool in the near future.

An Invitation to Give away Your SSN and Credit Card Number

StolenIDSearch

It looks like a new service from TrustedID came out recently. This service allows you to check if your social security or credit card number have been compromised.

I understand that many users will be interested is such a service. But I have a also some problem with it :

1. If your credit card or social security number has been stolen, there is a good chance that you will find out quite quickly. Most of the time, people who stole this information will not wait a long time to use it. So sooner than later, you will get a call from you bank of credit card company about some weird activity in your accounts.
2. This is an invitation for criminal to setup similar looking sites and send out spam to invite people to verify if their SSN or credit card number have been stolen. Victims will easily fall for it and will give their numbers to criminals.

While we may trust TrustedID not to store nor use the information we input on their site, they do have a database with all the compromised information. So if someone stole that database from them, they get more than a handful of information that can be use to steal someone identity.

I believe that these kind of services should not be available online but through you banking institution. My bank already offer me, for free, a service that notify me of any activity on my credit report. So if anyone try to get credits in my name, I will now it very soon. My bank already have these information, so I don't have to give it to someone else to benefit for such a service.

j2ee_util.rb public release

I just released my first public version of j2ee_util.rb : Simple tool to manage your J2EE archives (war, ear, jar, zip). Not long ago, I had to make quick changes in a web.xml file contained in a WAR file contained in an EAR file. To do that, I had to extract the EAR that extract the WAR then edit the file then repackage everything.

The process is a bit cumbersome and prone to errors. Yet, I never saw a command-line utility that allows one to do that. So I decided to write my own and j2ee_util.rb was born.

With this command line tool I can now type this to edit the web.xml file :

ruby j2ee_util.rb --edit my-application.ear:webapp.war:WEB-INF/web.xml

And when I exit the editor, the file is automatically repackaged in the WAR file which will be repackaged in the EAR file. The tool also only extract the specified files instead of the whole archive.

I plan to add a few features to be able to edit stuff directly from the command-line (like replacing a value in an XML file) without having to fire-off an editor.

If you use the tool and have any comment/idea/issue with it, fell free to leave a comment on this post.

Groovy Ant Builder

The other day, I was tasked to modify a Java web application. However, after checking out the source code from CVS, I found no build script. It looks like I'm expected to use WSAD to compile and package the application. This is a direct hit in my one of my software development principle: Never rely on an IDE to build an application. Anybody should be able to check out the code and build it with some non-GUI build tool.

The client already use Maven for other projects. However, the application I needed to modify did not have the Maven standard directory layout. The CVS repository also contains the library this application depends on. Because of firewall restrictions, it is not easy to use Maven dependency management (jar download are not permitted by the proxy). They run their own Maven repository but adding stuff in it is no easy task.

The easiest solution to quickly get the job done, would have to create an Ant build script. However, I did not have Ant installed and the proxy would not allow me to download it.

I did have Groovy installed on my portable hard-drive. Since Groovy comes bundled with Ant jars and the Groovy Ant Builder, this was now the fastest path to creating my build script.

And it fact, it was quite easy to get the job done. Task are easily defined and the builder syntax remove all the pain of XML build script. Here is an example of my compile task :

void compile() {

ant.mkdir(dir: "${classes_dir}")
ant.javac(destdir: "${classes_dir}",

srcdir: "${src_dir}",
classpath: "${compile_classpath}",
target: "1.4",
source: "1.4"
)

ant.copy(todir: "${classes_dir}") {

fileset(dir: "${src_dir}") {

exclude(name: "**/*.java")

}

}

}

The thing that seams to be missing is the proper declaration of task dependencies. It seems that the only way to do dependencies is to call another task from a task :

void war() {

compile()
ant.mkdir(dir: "${dist_dir}")
...

}

This seems a bit backward. And I don't know if dependencies will be called many time if they are referenced my many tasks (I will have to test it).

I did consider using Raven, but right now, it lack customization when you want to exclude stuff from the build or if you do not want to use dependencies (but prefer to specify your own compilation classpath).

I also looked at Gant but did not use it for two reason. First, I was not able to download it (proxy restriction) and second, for some reason, when I look at their example, I find them a bit ugly and it seems that you have two ways of doing stuff.

For my particular problem, Groovy Ant Builder allowed me to get the job done quickly and easily. It reminded of things I dislike about Groovy syntax like have to use def to define variable (but not to define methods) and having to specify void as a return type when my methods does not return anything. I much prefer Ruby syntax.

Sony-Ericsson PSP

Rumors abound about the next version of the Sony PSP game console...

Maybe Sony could kill the the iPhone before it launches by delivering a Sony-Ericsson PSP! Allow with a slimmer design and GSP receiver, they could put a touch screen and add GSM phone capabilities to the device.

As a PSP owner, I would be really interested is the new device!


UPDATE : It looks like there are already rumors about a Sony-Ericsson PSP.

Improving the Java Specification Request Process

The JSR process is know to take a lot of time produce an actual specification. On top of that, it often produce overly complex specifications that are way too overkill to solve the problems they intend to solve. It is also a process that is driven by the main vendors desire with little thoughts for developers.

We could probably shorten the process and increase the usefulness of JSR by bringing a bit more agility in the process. Here is what I think we could do to make things a bit better :

1. Create the reference implementation first. Then produce the specification. A working implementation offer greater value than just having a specification. It allows the community to use it and comment on real life issue. This is way better than commenting on a theoretical document.
   Groovy is a good example of creating a reference implementation before a specification. Granted, it took a lot of time (lack of resource availability) to achieve, but in the end, we have a better Groovy than if we produced a specification first and then implemented it. Once a specification is voted, there is little coming back (beside repeating the complete JSR process). Voting on a working implementation mean voting on the real thing!
   
2. Make the sponsors of the JSR provide full time resources to work on the reference implementation. There is nothing worse than only having resources working part time on a JSR. Things go slower and communication suffer when the team members have other responsibilities.
3. Make the reference implementation Open Source from day 1. Make the code public as soon as basic functionality is built in. This allow the community to participate early and provide early comments.
4. Make all communication related to the JSR public from day 1. Public forum and/or mailing list increase the diffusion of the information. Issue/feature tracking should be readily available and every decision made on issues/features should be made public. Having public communication will again increase the community involvement and at the same time decrease the sentiment that the JSR driven by the vendors secret agenda.
   
5. Have the JSR team produce workable software at regular intervals (every months for example). These content of each iteration should be determined at the beginning of the iteration based on the issue/feature backlog. Each iteration should have a specific goal to make sure that the team focus on the right thing for the iteration.
6. If the JSR address something that is already available in an Open Source project, it should review the project and base it's work on it. If something exists there is no reason to start from scratch.

Doing all of this will ensure that at even if the JSR is voted off,the community will gain working software. It will then be its choice to use it or not. But I believe that with these kind of changes, most JSR, will either fail early (which is good as less time will be spent on it) or either succeed when they attain the voting stage (aka version 1.0).

iPhone

Apple finally announced the much rumored iPhone . The device really look nice and follow the thin is in concept launched by Motorola .

What's being announced is really cool. But I wonder about what's not being announced :

• Java support : not a word on that. Granted, it run OS/X and Widgets but most phone today ships with Java. It certainly has the power to run Java,
• What kind of CPU in inside this thing. If it runs OS/X it may be an Intel or a PowerPC... XScale like many other devices uses a different instruction set than Intel Pentium CPU AFAIK. So will I be able to run any OS/X applications? Guess not. No word on CPU speed either,
• How much memory (beside storage which will be 4G or 8G)?

I also guess that the various sensors that are in the device will eventually have more uses that just dimming the screen, detecting rotation, etc. Will they be easily accessible by application developers?

I guess we will have to wait until this summer to get more details.

One last thing! Which carrier will they choose for Canada? The device is GSM which mean the only choices are Fido and Rogers (which are just two brand for the same carrier). Most of the time Rogers has the coolest phones, but I hope it will also be available on Fido.

Anyway at 499USD, I cannot say that's it's cheap. But it does seems to be a nicely done convergence device.


UPDATED: I forgot to talk about GPS functionality. Adding this would make it the ultimate convergence device. Maybe they'll announce that next year!

It is also kind of funny that they waited for the iPhone to put Bluetooth in their iPods.

It's NOT the code NOR the process, stupid!

It looks like some people think that focusing on a process and having a high level view will yield more successful projects.

I have to disagree with this statement. While a process may be a good thing, in most cases the process is the cause of failure. The reason is simple, processes are often put in place for one reason. To reduce the per resource cost. It seems that executive believes that having a process will allow them to hire less skilled individuals (this really mean cheaper) and to still be able to deliver a project on time and on budget. Since the birth of software development, we have people who champion processes to executives to reduce their costs and increase the rate of success. They will often use the quality argument to support their point of view. However, even if more people use processes, the rate of successful software projects has not increased throwout the years nor the cost has decreased.

I have yet to see a project that is so trivial that it will succeed with unskilled people using a well defined process. Choosing the appropriate technology, creating an appropriate architecture and design are no trivial tasks. No process will ever make these task easier to do or more predictive. Only having the right people for the task will increase the chance of success. A process can help them, but never will replace them.

Focusing on code or focusing on processes are both wrong. Get good people on your team and focus on what really matter... What needs to be delivered! Focus on what is going to add value for the client/user. A working application will give more value than a well defined process. A process can help in achieving this as long as it's a mean but not an end.



It's NOT the code NOR the process, stupid! It's the right people focusing on the appropriate objectives!