The morning after

Piclens

2007-12-29T13:47:00.000-08:00

I just stumbled upon a nifty cool plugin for Firefox, it's called Piclens and it gives you a great way of browsing photo albums as found on Google, Picasa, Flickr, Yahoo, Facebook, etc...
I recommend visiting their website, unfortunately there currently isn't a plugin for Firefox on Linux yet, but Apple and Windows users should have no problem installing it, including Internet Explorer and Safari!

Here's a small video I found on Youtube, it features the CoolIris guys:

Recovering Ubuntu after a Windows installation

2007-12-25T09:05:00.000-08:00

what follows is a small step-by-step guide on how to recover the ability to boot your Ubuntu partition after a new Windows installation

problem: Windows overwrites the Master Boot Record (MBR), effectively destroying any LILO or GRUB setup you might have had; contrary to what several websites claim: just setting the proper partition active will NOT fix the problem

why: I've had this problem several times in the past and I've used different ways of being able to recover my dual-boot capability, I Googled for a solution each time again, this time I hope to win some time by keeping track of what I did the last time

solution: reinstall LILO or GRUB

how: we'll be reinstalling GRUB so that the original boot screen is shown again at startup

pop-in your Ubuntu Live CD and wait for Ubuntu to have loaded
open a terminal
type sudo grub and hit enter, this will open a new interactive context within your terminal
now type find /boot/grub/stage1 and hit enter, this will print a string in the console, in my case it printed (hd0,2), we'll be using this string in the following steps .. if something else is printed in your console then substitute my string in what follows
type root (hd0,2) and hit enter
type setup (hd0) and hit enter again
finally type quit and hit enter to exit the GRUB console

at this point the GRUB information should have been written to the proper partition (just as it was before the Windows installation), restart your system and make sure the Ubuntu Live CD is ejected before the system actually reboots

I had to reboot twice for everything to properly work, for some reason Ubuntu presented a black screen with a blinking cursor the first time

mvn site:deploy and SSH

2006-12-13T05:40:00.000-08:00

Recently I've been going in deep at work using the Maven2 release plugin, I have to say this plugin does the job really well, updating all pom.xml files with the new version references, including the SCM urls and dependencies, there's even excellent SVN integration in that it knows about trunk/tags/branches when updating to the next release .. taking care of this manually would quickly become very cumbersome.

Anyway, I got stuck actually deploying the new release to the server, this is done by calling release:perform by executing the deploy:deploy and site:deploy goals. The former goal works fine, although it's slow as heck, but the latter one simply does not work.

I was able to trace it back to issue MDEPLOY-9, which is supposed to be fixed in the next stable release (which is going to be 2.0). So I tried to build the 2.0-SNAPSHOT myself (the ones found here are way too old so they had the same problem), without success .. apparently it requires Maven 2.1-SNAPSHOT, but if you disable this requirement the build will fail on the maven reporting api (again version 2.1-SNAPSHOT is needed, which you would need to build yourself too).

So I abandoned this and went looking for another solution, and I found one, an easy one which will help me in other areas too: ssh-agent. The problem was that deploy:site is attempting to call ssh in batch mode in order to work on the host server, but since the settings.xml is ignored it won't be able to pass in the password in order to access your private key. Running Putty's PAGEANT won't work either because you would need to have deploy:site read the settings.xml in that case.

Fortunately there's a solution when you are running Linux (or Cygwin), just run the ssh-agent (which is similar to PAGEANT) and add your key, it will prompt you for the password only once, from that point on the password will no longer be asked, effectively allowing the deploy:site goal to continue. I've found good instructions here.

This is basically what I did:
1. called ssh-agent and copy the output in my ~/.bashrc
2. called ssh-add
3. entered the password I was prompted for
4. made sure the key was property collected by calling ssh-agent -l

That's it .. when I was finished I was able to execute site:deploy without any further issues.

SessionFactory.getCurrentSession()

2006-08-24T04:55:00.000-07:00

I recently refactored the data-access code in my current project. I noticed the Spring 2.0 Javadoc as well as the Hibernate 3.x Javadoc to recommend using SessionFactory.getCurrentSession() from now on.

For Spring users this means that extending HibernateDaoSupport should be avoided in favor of writing plain Hibernate code directly. When putting this in practice it feels like a natural evolution as there's no more need for the typical use of the callback mechanism in this approach.

A thing to note though, and I feel the current documentation does not stress this enough, is that this new approach requires a transactional context. Basically this means that a transaction interceptor must have been triggered prior to a call to SessionFactory.getCurrentSession(), otherwise a nasty exception will be thrown, saying no Hibernate session is bound to the current thread.
The documentation mentions this here.

What I did to make sure stuff would work as before is to intercept DAOs with both the HibernateInterceptor and a TransactionInterceptor, for the transaction interceptor I am using TransactionAspectSupport
which is able to detect transaction demarcation using Java5 annotations. This is nice since no further Spring configuration is required, just demarcate transactions on the DAOs and you're done.

All DAO methods are required to propagate the transaction (in order to make sure there is one, we need this to guarantee a reference to the current context in the session factory), finders are flagged with readOnly.

This all looks pretty innocent but I bothered to write this down here nevertheless, I've spent several hours figuring out what was going wrong, just to learn the Javadoc documentation wasn't mentioning any of this. My problems started when unit tests were failing because I was testing my DAOs (handwritten DAOs, not generated by AndroMDA) and I didn't have any transactional context at that point.

Networking IO and Threading

2006-08-08T22:25:00.000-07:00

Recently I had to write a software component capable of dealing with a non-Java service, it was actually pretty straightforward is I only needed to handle lines of text over a TCP socket. I needed both the send and receive data over the socket, this included commands with replies as well as support for notifications. For the sake of testing I also wrote a small mock server instance.

It's clear that when dealing with incoming data over a network or file system you'll want to wait for the next chunk in another thread, otherwise you'll block the application thread and most of the time this is undesired. Sounds not too hard, I was able to write it in a rather short time frame, tests were all passing ... all was good.

When I ran the tests in another environment I noticed they consistently failed, I quickly realized this was due to the multi-processor architecture the machine was using. I tested on a few other platforms and I could indeed confirm the failures only to occur on multi-processor machines. Mind you, it worked well on Ubuntu Linux using Pentium 4 with hyper-threading but not on Ubuntu using a dual core (Dell D-820).

Since our production environment features multi-processor machines too it was a big must to have this issue fixed, especially since another collegue of mine also wrote some threading code and it showed the same problem.

First I thought it was due to the Maven2 Surefire plugin somehow forking tests in parallel (the error I was getting was saying that the server socket I was trying to create was already in use, the well-known JVM_BIND error), however, that was not the case .. tests were being executing sequentially, the problem was that the code I wrote for both the client-side and server-side threads was not bulletproof, I could see in the log file that some threads would never die.

Now you will probably say "yeah, learn how to work with threads and do it right", and to a certain extent you're right :-) but my case involved a feature which made it a bit special: when a client connection was broken it should automatically attempt to reconnect to it, effectively creating another thread, this required a bit more synchronization and a clear and solid way of starting and stopping threads.

By following the rules of thumb below I was able to easily write stable threading code:

it is good for client threads to rely on the socket throwing a SocketException when blocked in a read operation on the socket's inputstream, when the server socket closes this is what will happen

have two global variables: 'closing' and 'closed'

define a method which can close the thread, this method should set 'closing' to true

at the end of the thread's run method 'closed' must be set to true, take care of any exceptions; synchronize this method

the thread's run method should check whether 'closing' is set to true, in case it is true the thread should break out of any loop it's currently in

after calling the thread's close method from another thread (!) it's generally a good idea to also call the join method, this will synchronize this thread with the current one by waiting for it to die

By using the two global variables above and relying on the SocketException when blocked in an IO operation I was sure to be able to handle any situation where the thread would need to be closed. The thread calling the close method would ideally wait for the thread to finish, this can be done using the join method mentioned above. Following these rules your thread will be closed once the close method returns.

I use two variables because I also provide an 'isClosed' method which will only return true when the thread has actually finished completely.

Code generation and Annotations

2006-06-20T14:47:00.000-07:00

This post will be about code generation and JDK5 annotations. If you are one of the lucky ones being able to make use of the latest JDK features at work you'll surely have benefit from the many improvements such as the templating capabilities, the simplified for-loop, specialized overloading, ... and maybe even the newly introduced annotations.

For people not familiar with this concept: annotations are specific sets of meta-data used to attach more information to specific parts of a class definition such as a member field. Annotations are becoming increasingly more popular in combination with middleware such as Spring and Hibernate. If you have used XDoclet or AndroMDA before you are already familiar with annotations (albeit in another form). I will be giving examples shortly anyway.

The interesting thing with annotations, and this is what makes them complementary to regular class information, is that they do not convey class information but rather meta-information, information about information, and this is typically what you would do when modeling a class diagram in UML.

Meta-data and UML

Most people use UML to describe a static part of their domain, typically the object model. This model features classes, inheritance, associations, attributes, and so on. So far nothing special, it gets interesting when using the more advanced features such as <<stereotypes>>, @tagged.values or even the more common features such as changeability, multiplicity, query-flag, etc...

Let's, for the sake of simplicity, take a small persistable POJO with a few attributes, it could be described as follows:


Class : "Person"
Attribute id : Long
Attribute name : String
Attribute phone : String

We can now give additional information to further complete the "Person" class:

id is required

name is required

phone is optional and there can be many numbers per person

the class can be persisted

Let's see how this can be modeled using UML:


Class : "Person" @persistable
Attribute id : Long [multiplicity=1]
Attribute name : String [multiplicity=1]
Attribute phone : String [multiplicity=0..*]

As you can see this is probably the most efficient way of expressing our information, it is complete yet does not contain anything extra. The corresponding Java code, on the other hand, is a little more verbose (most of the time you'll write accessors to your member fields).

For those meta-data features that are not supported by UML (you might want to create your own sets of meta-data) you can always resort to the use of tagged values.

Unfortunately not all UML tools support tagged values that well, they should be supported on ANY possible model element.

AndroMDA

When using AndroMDA for code generation it becomes very easy to benefit from these UML features: a simple Velocity (or Freemarker) template can transform the Person class from UML to actual Java code. This is basically a one-on-one transformation, a no-brainer.

The idea of using AndroMDA with UML is to be able to most efficiently translate the business domain into a binary form, next it can be processed and more code can be produced that could be fed to a compiler or interpreter. It appears the use of annotations extends this smoothly concept.

In reality

Why would you want to make use of such features ? Well, let me give you some examples where I'm applying the stuff I explained above:

My problem domain asks for some kind of administration GUI which can be connected to the back-end in order to perform operations on the object model. We would like to write as little code as possible for this GUI and therefore we like to have it auto-detect specific meta-data from the individual object types.

When the GUI client deserializes class instances received from the server it can introspect them in order to detect this meta-data, it could for instance detect an attribute is mandatory or needs to adhere to some specific format in order to present the user the proper validation logic.

Objects in the domain model often have attributes that do not need persistence, we call these types of objects operational data, what the persistence framework is concerned these attributes are transient.

The AndroMDA templates have been updated to render a specific annotation for these attributes so they are treated differently on the server: all operational data is cached for performance and reused when an the same instance is loaded in a separate session.

I'm sure you could come up with your own specific applications, the usage is so natural one wonders why it took so long for this feature to be available in the Java programming language.

Rich domain models: Immutability

2006-06-18T05:31:00.000-07:00

Something which works well with rich domain models is immutability: don't allow client code to update an object instance, in other words: don't use any public setters on your domain objects (I recommend not using any setters at all, set your fields directly).

I've been thinking about this since a long time but I never dared to implement it because I somehow thought I would run into problems with this approach. When I attended SpringOne last week I saw a presentation where the speaker what advocating the same approach, this gave me the courage to go out and give it a try. I must say I was surprised how simple things were once I refactored all JUnit tests etc..

No setters ? Then what do I do when I want to update something ?

Well basically you would model a business operation returning a new object instance which has been constructed with the members set to the proper state. That way you don't update the current instance but simply copy (some of) its members over into a new one.

Note that you don't need such business operation for each member field, you should model an operation per use-case: if your application requires you to always change 3 fields at the same time then model a single operation which takes 3 arguments!

Tip: make sure you have a constructor taking the required properties and another constructor taking all properties so that it is easy for users to instantiate objects in a call.

Can my persistence engine handle objects without setters ?

It most likely can. In the case of Hibernate you can configure the access level in the mapping file, or by using the @AccessType annotation on your POJO (set it to 'field' instead of the default 'property'). Also: don't forget to have a (non-public) default constructor so that Hibernate can instantiate your POJOs.

Okay, my objects are immutable, now what ?

When using them you'll quickly see that working with immutable objects is actually simpler because you are sure client code cannot alter their state. This makes them thread-safe and avoids unnecessary validation checks throughout your code. Give it a try and see how it's more clear to work with them. Granted, you can't reuse an instance and call Session.update() (Hibernate) but you can still copy over the updated fields using Session.merge().

In my personal experience they are not simply straightforward but they also point out possible flaws in your architecture (too long to go into that right now, maybe in another post sometime), it seems that updating objects is more dangerous that one would think.

What about support for JavaBeans in other tools/APIs ?

You won't always be able to make use of them since they often rely on the explicit presence of paired getter/setter accessors. On the other hand, GUI frameworks such as JIDE support alternative implementations when using their bean forms, I've actually once worked with Map-based beans (no direct accessors, just getProperty(String) and setProperty(String,Object)) and adding support was as simple as implementing their Property interface and make sure it is used instead of their default BeanProperty implementation.

Rich domain models: Intro

2006-06-18T04:52:00.000-07:00

This topic will be a quite controversial one in the Java community in the near future, if not already.

I'm not 100% sure myself what to think about it, but here goes:

When people talk about rich domain models they are referring to an object model in which the participating objects are not simply data holders but also carry a lot of business logic which would 'normally' go into a service. In the current JEE project landscape most developers make use of what is known as anemic domain models in which objects are simply there to carry data back and forth, mainly for usage by a persistence engine such as Hibernate.

Now this sure sounds interesting but some issues quickly come to mind, I'll discuss them here.

What's wrong with anemic domain models ?

In my personal opinion it is not that bad to treat your object model as plain data holders, most people currently work that way by making use of the JavaBean convention where each field member has getter and setter accessors.

The advantage here is that you can treat the object model as a sort of API, the service layer can then act as a coarse-grain abstraction providing an interface to the business use-cases. Since the objects themselves have no specific business logic they can be reused by different service layers (in most cases you'll never need to share an domain model between different service layers, but the project I currently work on will require this).

The problem is more on a conceptual level where the objects would better reflect the real world if they would actually have specific behavior and knowledge of business logic. Bear in mind that moving service logic into objects will require you to significantly think (!) about your design, more specifically you'll have to become an expert in the business domain as well as a skilled modeler, here's where your analytic skills come into play.

On the other hand what does it mean to have something like Basket.add(Dvd) ? Technically it is not the basket adding the DVD, it is a human putting the DVD into the basket .. What do we do with this ? Is this an example a corner case ?

Will I be merging my service layer with my persistence layer ?

Yes and no. Business logic will obviously be moved from the service layer but surely not all of it, you will still need a service layer, it'll just be more lightweight.

There's a catch though. A business domain model implementing business logic is fine as long as you are navigating over the domain model itself, remember we are working with POJO objects, there are by default no dependencies outside of the domain!

Now take the case where a specific business operation needs to count the number of objects in the datastore, you'll not want to pass this number as an argument into the operation but rather you'll want the method itself to discover this. When you have a reference to the datastore available somehow the problem will be solved, but we don't have such reference!
This problem could be overcome by making using of AOP and having dependencies to external resources such as a datastore injected for you, this is quite elegant and can easily be done by making use of the runtime AspectJ support in Spring AOP.

What will I gain ?

First of all your service layer will be more light-weight and the object model will more naturally encapsulate the system's behavior. This opens the door to several alternatives.

With Java 6 around the corner support for scripting will be added, these scripts will be able to access the domain model directly, having business logic executed without any additional effort, that's beautiful, no ? (I'm actually using Drools at the moment, they are definitely more readable and lighter when working with a rich domain model).

Secondly you'll be able to better express yourself, this quickly becomes clear when writing unit tests, these tests typically are easier to understand and have less dependencies to external resources.

More on this topic later...

Code generation and AOP

2006-06-18T04:23:00.000-07:00

In most, if not all, of my projects I am making use of AndroMDA in order to get the boilerplate code generated for me, this works great but sometimes I'll find myself customizing the cartridges to fit the architecture/design, in this entry I will give an simple example replacing AndroMDA-generated logic with AOP using AspectJ.

As an example take the case of the Hibernate entities: AndroMDA generates an abstract base class and a concrete subclass suited for implementation. The subclass will be generated only once so that you can safely add your implementation for business operations without the generation process overwriting it each time you run AndroMDA.

This is an example of an abstract base class:


  public abstract class Entity
  {
      ...
      public abstract void myOperation(String value);
      ...
  }

And here is an example of an implementation:


  public class EntityImpl extends Entity
  {
      ...
      public void myOperation(String value)
      {
          // todo: implement
          throw new UnsupportedOperationException("EntityImpl.myOperation");
      }
      ...
  }

This means, however, that when you are making use of Hibernate inheritance the hierarchy can get rather deep, it would be nice if this could be avoided.. And it can!

The trick is to make use of AspectJ, with this it is possible to only have the base class as a concrete class and not generating the *Impl class; the business operations still throw an exception as shown above but this behavior can be overridden by an aspect advice.


  public aspect EntityAspect
  {
      void around(String value, Entity entity) : 
        execution(* Entity.myOperation(String)) && this(entity) && args(value)
      {
          // here you can implement the new logic
          //   value = the argument passed in
          //   entity = 'this'
      }
  }

Having such an aspect woven in will replace the generated method implementation entirely (without removing it though), thus effectively annulling the exception. As far as I know this can only be achieved as elegantly as presented here by making use of the around() advice.

Note that it is still possible to call the original implementation by making use of proceed()

Considering the different possibilities for merging in your own code in generated code somehow (protected sections, inheritance, etc..) I think this is a nice alternative. One could argue that it is more interesting to have such implementation inside the generated .java file but trying to enforce this will result in not-so-elegant situations considering you'll want to regenerate the class each time while retaining you're custom implementation.

SpringOne

2006-06-18T02:37:00.000-07:00

I just got back from the SpringOne conference in Antwerp (Belgium), it was a joined effort of Interface21 and BeJUG, the Belgian Java User Group.

It was a pretty good conference, but not great as most of the talks were rather superficial and sometimes even shameless plugs for commercial tools, I guess that's more or less normal since these kind of events use sponsors to keep the price down but still bring some cash for the organizing parties, ah well..

These are the presentations I attended:

Practical Quick Start with Acegi Security: very good presentation by Ben Alex, concise and to the point
Guaranteeing Spring Application Performance: this presentation should have been called "let me show you what my Symantec profiler can do", the word "Spring" was not uttered once; I was hoping to learn about some of the pitfalls and design decisions when using Spring which could affect application performance, I wasted my time on this one
Spring RCP: RCP stands for Rich-Client Project which is an attempt to make Java Swing more accessible and maintainable in applications, I've been using Spring RCP since 6 months so I wasn't really hearing anything new, good presentation by Keith Donald though
Pragmatic Spring: two guys quickly threw together a presentation about how they abuse Spring at work, nothing to learn here about applying Spring in a pragmatic manner
Practical Rich Domain Models: presentation by a local guy, pretty good actually, but a little too dogmatic, and suffering a bit from the Martin Fowler/thought leader syndrome; I hope to discuss the subject of rich domain model later on
The art of domain modeling: I was hoping Keith would have a bit more tips and best practices for us when modeling the problem domain, as a heavy user of UML/MDA this would have been very interested; on a side note: I got the impression Keith himself wasn't really convinced of the stuff he was presenting
Embeddable lightweight Messaging: pretty good presentation on an open-source JMS alternative, targeted at a novice audience but interesting nevertheless; the idea behind the project presented here (called MantaRay) is to no longer have a JMS broker but have the distributed endpoint/nodes copy the information such as topics and queues, Spring is able to make an abstraction out of this (just configure the connection factory for the JMS template and you're good)
Spring Patterns: presentation about how to integrate your own technology into the spring framework by following certain conventions at the same time, mildly interesting as I won't be doing that kind of stuff
Core features of Spring 2.0: Kinda weird to have this presentation at the very end of the conference; Adrian Colyer did a good job though, seems Spring 2.x features scripting support, simplified configuration, reloadable beans (very interesting when you have Drools rules that could be hot-deployed, like I'm doing in my current project), some improvements in the JMS area etc..

So overall I enjoyed being there, I'll be reflecting on the domain model stuff in the next couple of days, I'll make sure to post my findings/conclusions...