My Cloner and Visage projects, available over at github, were picked up by Softpedia in late February. Thanks for the recognition!

comment |ˈkämˌent|
noun
a remark expressing an opinion or reaction : you asked for comments on the new proposals.
• discussion, esp. of a critical nature, of an issue or event : the plans were not sent to the council for comment.
• an indirect expression of the views of the creator of an artistic work : their second single is a comment on the commercial nature of raves.
• an explanatory note in a book or other written text.
• archaic a written explanation or commentary.
• Computing a piece of specially tagged text placed within a program to help other users to understand it, which the computer ignores when running the program.

No where is a comment defined as a device by which logic is selectively hidden from the compiler in hopes that in the future it will be included into the code base.

The lesson here is trust yourself; you are an engineer. Commented logic is like litter on the sidewalk next to a waste receptacle– so close to being where it belongs, in the garbage, yet stands out in your peripheral. “But I’ve already written the logic that does something I’ll want in a month or so…” you might say. Commented logic doesn’t really save you from rewriting anything. Chances are when you are ready to use said logic you will have thought of a better way to write it or the code will no longer be relevant.

Not convinced? I propose an experiment. Instead of commenting out your logic to hide it from the compiler, store your snippet outside of your codebase until you are ready to use it; Evernote would work perfectly for this. See what percentage of the snippets you keep you actually use verbatim.

Description:

Cloner is designed to be a simple, extensible, quick, and safe Java Cloning framework. Cloner provides facets for both shallow and deep cloning of object. However, unlike deep cloning operations of other “cloning” frameworks, the IndieBrain Cloner does NOT user object serialization. This makes the IndieBrain Cloner much more safe and faster than these other “cloning” frameworks.

Some major benefits of the IndieBrain Cloner are:

1.) Like some other cloning frameworks, IndieBrain Cloner can handle shallow and deep cloning operations for objects even if they do not implement the java.lang.Cloneable interface. However, since IndieBrain Cloner does not use object serialization to deep clone objects, it is NOT a requirement that Objects passed in for cloning operations implement the java.lang.Serializable interface either. This frees up consumers of this library to implement their domain code independently of their cloning framework; IE Clients of the IndieBrain cloning framework are NOT required to write glue code to gain the benefits of the framework.

2.) Since the IndieBrain Cloner does NOT use object serialization when creating object clones, the framework tends to operate on orders of magnitude faster than cloning strategies that DO use object serialization.

The Cloner source is available in my github repository: IndieBrain Cloner

I recently ran into an issue while backing up some old software disks of mine. I tried to use OS X’s disk utility to create a Master image of my software to then place in storage for safe keeping. I was saddened when the Disk Utility pumped out a .cdr image of my backed up software. I was really hoping for an ISO.

So I got to work on this little Ruby script which will scan a directory for .cdr images and convert them to ISOs. You can obtain a copy of this script from my github repository.

README:

Visage is a simple utility to convert
CD/DVD master images created from
OS X’s disk utility (.cdr) into .iso format.

usage: ./visage.rb [options] [path_to_dir]

OPTIONS:
-s -S -source Specifies the directory in which Visage will look for .cdr images.
If this option is not set, visage will look in the directory from which the script was lunched by default.
-u|-U|-usage Displays usage information/examples

At work, I’ve been part of the development of the new version of our flagship product. The previous version of our system’s UI was extremely outdated and stylistically challenged. As a result we were tasked with researching and selecting a framework which would improve our end-user experience. Long story short we decided to use ICEFaces– an extension of Sun’s JSF implementation.

It became apparent from the very beginning that JSF does not deal well with exceptional situations. We quickly came to find that sometimes the UI would seem to jump the rails and behave in very erratic ways with no warning or output which would suggest that something had gone wrong on the server-side. We spent a few frustrated hours trying to figure out what was happening with our application. In the end we found that some application code was responsible for kicking off the whole chain of events.

Our application code would explicitly throw some business exception if certain conditions were not met. This exception bubbled up into the JSF cloud. We expected a redirect to our error handling page since we had included the requisite error-page configuration in our deployment descriptor:

<error-page>
   <exception-type>java.lang.Exception</exception-type>
   <location>/path/to/error/page</location>
</error-page>

This was not the case. It appeared that sometime after the exception left our backing bean the JSF framework simply consumed our exception. Therefore our backing bean’s state was invalid to continue processing user requests. This caused the erratic behavior we observed.

Disappointed, we quickly scrambled to find a solution to the mysterious vanishing exception problem. I tried more than a handful of ideas myself, but none of the initial solutions I came up with was complete, in the sense it worked in every situation, or functional, some of the ideas simply broke the JSF framework.

I will outline some of the more common approaches here and try to explain their shortcomings.

Mediate FacesServlet:

This was the first thing I tried. I basically wrote an extension of HTTPServlet class which delegated to an instance of a FacesServlet. This seemed to be the simplest approach at solving the problem, however extending or delegating to the faces servlet caused all sorts of look-up and class-loading errors for JSF and ICEFaces specific servlets  at deploy time. I would learn in time that, in general, fudging with the FacesServlet is not recommended; especially in an ICEFaces environment.

Extend ActionListener:

This seemed like a good idea for a few minutes. The approach would be very simple and have minimal code impact. I would extend the ActionListener class and wrap the processAction method in my exception navigation logic, Then register my custom ActionListener in the faces-config.xml. This works, as long as the exception occurs in the InvokeApplication phase of the JSF life-cycle. The problem is JSF can circumvent phases of the life-cycle based on output from the current phase. This happened to be the case with our situation; the InvokeApplication phase was simply skipped and our exception was consumed by the JSF cloud.

Another issue, this change only works with objects in the ActionEvent class hierarchy. Therefore, methods which process ValueChangeEvents are not covered by this approach.

These are just a few of the ideas I prototyped to observe their viability.

In the end, it was apparent that the simplest way to deal with this problem was to intercept exceptions before they are passed from my backing beans to the JSF framework. I achieved this by using the facilities of AOP; AspectJ compile-time weaving to be more precise.

I wrote a piece of advice which is attached by a pointcut definition to all of the methods in my backing beans which can be used by the page to execute some server-side operation. This piece of advice uses the AfterThrows advice type to inject my exception page navigation logic into a try/catch construct around these methods. This solution has seen many revisions as we learn to how to use the AspectJ framework more efficiently, however the concept has remained constant since it was first implemented over a year ago.

For a code example of the topics discussed in this article please see http://github.com/indiebrain/jsferrorhandling

Welcome to IndieBrain!

First, a little about myself. My name is Aaron Kuehler. I am a an Application Engineer for Oracle and I’ve been writing enterprise applications in the insurance sector for the past 3 years.

This site will primarily be an outlet for ideas and opinions on topics realted to software engineering and development. I often find that “good ideas” are lost in the chaos of work and home life. This site will hopefully help extend the lifetime and provide an open forum for crtitical analysis of these types of thoughts.