log4p

Due to the fact that I was “optically challenged” for the past week it might have been a bit silent on my weblog. Since I’m still recovering I’m trying to keep time behind my computer as short as possible.

Normally I would have used this time to read about Leopard, and the fact that it hasn’t got Java6. Or playing around with some fancy new webframework. Today I spent some time reading about Anterior Uveitis; which is the name of the disease causing the pain in my right eye.

So, what is Uveitis? If we think of the eye as a hollow, fluid-filled, 3-layered ball, then the outer layer is the sclera, a tough coat, the innermost is the retina, the thin light-gathering layer, and the middle layer is the Uvea. The Uvea is made up of the iris, the ciliary body and the choroid (see diagram). When any part of the uvea becomes inflamed then it is called Uveitis.

And on the “anterior” part? Anterior means that it affects the front of the eye, normally the iris (iritis) or the ciliary body (iridocyclitis). Iritis, strictly speaking is an older term for Anterior Uveitis but is still used frequently. Iritis is by far the most common type of Uveitis and also the most readily treated. Having said that, iritis is something that needs quite close monitoring because complications such as raised eye pressure and cataracts can occur.

So even tough the initial inflammation is incredibly painful, and I’ll probably have blurred vision until the end of this week… I’m glad I now know exactly what it is and how it can be treated!

Yesterday the mailman brought the copy of “JBoss Seam – Simplicity and Power beyond Java EE” by Michael Juntao Yuan and Thoma Heute which I asked Finalist to order for me.

I managed to read the first two chapters. My first impression is that it’s a bit ‘jumpy’. Chapter two contains so many references to upcoming chapters that it tends to loose its’ structure.

Funny to see that the book starts of with ‘cumbersome XML base J2ee frameworks’ but quickly resorts to the shorthand notation ’spring’. I understand that people find spring to be heavy on XML, but hey… weren’t the JBoss people the ones who introduced tons of Hibernate mapping files?

Two days ago Grails reached the 1.0 milestone; the first release candidate is out. New Features inlude:

• GORM features ORM DSL for advanced Mappings
• Support for easy to use Filters
• Tag Library Improvements – Namespaces, body variables, page scope, improved tag and more
• Controllers Improvements – Multi-dimensional params object, data binding retains type conversion errors
• URL Mapping Improvements – Mapping response codes, mapping directly onto views and more
• GORM Improvements – Pessimistic locking support, session flushing control
• Config Improvements – Support for JNDI data sources, property placeholders and flexible config locations

A descriptions of the various features can be found in the releasenotes.

Personally I must say that the 0.6 release brought more interesting new features; but hey… Grails going 1.0 is great news!

After two JSF-free years (I didn’t really enjoy myfaces at that time) I decided to get my head around Seam and JSF. My next project will consist of rebuilding a Delphi application to a multiuser Seam application; so let’s have a look at where we are!

Introduction

First of all, before I get flamed, Seam is not JSF. Seam supports JSF as a view technology. Seam defines a uniform component model for all business logic in your application. A Seam component may be stateful, with the state associated with any one of several well-defined contexts, including the long-running, persistent, business process context and the conversation context, which is preserved across multiple web requests in a user interaction.

There is no distinction between presentation tier components and business logic components in Seam. You can layer your application according to whatever architecture you devise, rather than being forced to shoehorn your application logic into an “unnatural layering” scheme forced upon you by whatever combination of frameworks you’re using today.

The position of Seam in the stack is therefor depicted as follows:

The Seam documentation states:

It turns out that the combination of Seam, JSF and EJB3 is the simplest way to write a complex web application in Java. You won’t believe how little code is required!

With my previous Grails experiments I highly doubt it; but we’ll see!
Read more

Once in a while I tend to use JConsole for basic profiling of a Java process.

Somehow I always forget which flag I need to set to enable remote connections to a process. And yes, I know the option is hidden somewhere on page 3 of the documentation…

You need to add the following in the VM arguments:

-Dcom.sun.management.jmxremote

After which you can just connect JConcole to the pid of the process you’re interested in.

Various sources are reporting on Oracle putting in an offer to buy BEA for a whopping 6.7 billion dollar.

I did some projects using WebLogic, WebLogic portal and WebLogic workshop but was never really a fan of BEA. I do however like healthy appserver competition!

Somehow I feel that if Oracle actually acquires BEA, WebLogic will die a slow and silent death…. in contrary to what Oracle claims.

Still it seems the Race isn’t over; SAP is in it as well… which isn’t much of a different story…

Whatever the outcome is: I for one will just remove WebLogic (I was already thinking of doing that) from my resumé. WebLogic will be passé really soon.

– update –
The 6.7 billion dollar offer was turned down. Now let’s just wait to see if anyone puts in another offer!

Some months ago I visited Aslak Hellesøys' RSpec presentation at RubyEnRails 2007. I was really intrigued by some of the concepts introduced by RSpec.

After checking out the way testing/TDD works in Grails I just had to see if my initial interest in RSpec would stand ground.

Just to recapitulate on what RSpec is:

RSpec is a framework which provides programmers with a Domain Specific Language to describe the behavior of Ruby code with readable, executable examples that guide you in the design process and serve well as both documentation and tests.

So RSpec gives a developer the means to write tests in a form that matches specification of functional requirements dictated by the customer. They call it behavior driven design.

Conceptually I think this is a good thing. Quite often customers don't actually know what is being tested in their project. Just look at one of the basic methods most often used in testing: assertNotNull. How does a customer know what this is supposed to test? The most obvious answer to this is: documentation/comments... which to be frankly isn't something most developers excel in.

Now, what does it look like... and how do you use it?

Installing rspec and its' Rails plugin is a breeze:

After installing the plugins in your Rails project a couple of new rake tasks are available (prefixed with spec:) to create run tests for your models/views/controllers/helpers etc.

RSpec also install some generators: rspec, rspec_controller, rspec_model, rspec_scaffold. These generators are similar to the default Rails counterparts but generate corresponding RSpec tests as opposed to unittests.

Let's get started.

Say we have a really simple specification for a model: "if a new article is created its' description field should contain 'no description entered'".

So, let's start with creating a simple model:

This will give us, next to the expected model file and migration, a file called article_spec.rb in the spec directory:

Which we can run immediately:

And, we can also create a simple overview of the specifications which we test:

Cool, now let's add our specification:

Running the tests results in an error now:

Setting the default value for the description attribute of Article like this:

Results in a successful test. And running spec:doc now tells me I have a test for this specification:

Conclusion
Although this is a really basic example (and there is much more the RSpec) I think I got the point.
I really like the "behavior driven" way of thinking; it provides clear handles for writing tests and creates useful overviews of what is actually tested.

Last couple of days I was attending the JBoss Masterclass in Rome. I learned a lot and met a let of interesting people. And I enjoyed being in Italy as well.

I'll be doing a full round-up (in Dutch) on the Masterclass for the company blog but first of all I'm going to have a good time with family now.

But, I just had to share the view I've been looking at while listening to some of the JBoss gurus:

The picture was compiled from about 10 separate pictures using the evaluation version of DoubleTake (hence the watermark)

--update--
My full report can be found here (in Dutch).

A couple of days ago I wrote my first post on TDD using Grails. Now let's move on to something more interesting: testing dynamic taglibs.

In another post I showed how to create a simple tag. Which looked like this:

When generating this test using the "grails create-tag-lib" command Grails also created a skeleton for the corresponding test:

Testing calling the taglib is simple, as opposed to JspTags they don't rely on a container. You can just call the closure with the necessary attributes:

Since the textile taglib converts the given textile markup to HTML we'll need something to parse the resulting output. Enter XmlSlurper. XmlSluper is a powerful XML parser with lower overheads than XmlParser due to lazy evaluation. XmlSlurper only supports read operations. Using XmlSlurper we can actually test the output of the tag.

We'll enter something like this:

Which should result in something like this:

And here the actual implementation of the test:

Surely I should have started out with the test in first place, but hey... I first had to see how Grails taglibs work in this case! Since testing is this simple I'll actually consider doing so next time.

In my previous post I mentioned implementing the Google Collections counterpart of the commons-collections LazyList. I'll refer to the Google Collections Library as GCL from now on.

The LazyList decorates another List to create objects in the list on demand. To code below is loosly based on the code in commond-collections' lazylist counterpart. Most modifications are generics related.

Since GCL supplies a 'Forwarding' wrappers it's really easy to write a decorator for the List type. Extend from ForwardingList and override the needed methods:

As you can see I modified code from the commons-collections counterpart to use generics. I reimplemented parts of commons-collections' factory structure to use generics as well.

The next test concludes in success:

Please note that the above isn't a showcase for the features of GCL, its' a simple extension to add a LazyList implementation. Feel free to use or extend it!

full sources, test and buildfile