Java

Struts 2 and JSTL EL Quirk

This is quite an odd one. Struts 2 comes with it’s own tag library for accessing properties of actions but I thought it would be interesting to see if you can access it via JSTL EL instead. In the Hello World example I naively tried ${name} and ${requestScope.name}. Result: nada, as might be expected.

However if you reload the page (and repost the request) then suddenly the EL is populated! I presume that this is some artefact of re-executing the Action but it is very strange!

Update: this page set me right on how to mix JSTL EL and the Struts 2 Value Stack but I am still slightly mystified by what appears in which scope when the Result is returned.

Standard
Java, Software, Web Applications

Learning Struts 2

I have been trying to get to grips with Struts 2 recently. Lesson one: very little of your Struts 1 knowledge will carry over. Lesson two: documentation is skimpy and much less coherent that Struts 1.

My first experience was an hour and a half of bafflement until I saw that I had put the config file (called struts.xml now to avoid clashing with the original framework I suppose) under the web application initialisation folder instead of the root of the classpath (i.e. under WEB_INF rather than WEB_INF/classes). Because Struts 2 is all about the defaults I could not see any issue with what I was deploying until I realised that my application would generate the same error message (Action not in namespace) whether my xml config was valid or not.

This is a problem with XML-driven configuration in general but is also a specific defaulting issue. If the framework is defaulting it should say so rather than just silently defaulting everything. The alternative is to explicitly say what packages are being loaded from config but I think not finding a config file is more likely to be an error situation, after all what application is going to be deployed in the default state if you cannot interact with it? Even if the config file is empty you are still expecting there to be one…

Like most web frameworks the learning curve on Struts 2 is initially smooth as you put together Hello World before hitting a vertical climb when you want to do anything serious. Struts 2 relies a lot on injection via marker interfaces and interceptors in stacks; none of which really map to the Struts 1 world.

The goal of Struts 2 is to have a POJO based framework that is more unit-testable and less linked to the Servlet spec. I think it is successful in this and it is what has kept me perserving with the framework. However to do so it has made a lot of things very abstract and in terms of testing there is has been some headscratching as again a lot of Struts 1 testing strategies (which focus on mocking the various objects) do not really apply.

For example when trying to test whether an Action was correctly setting something in the Session Context I was stumped for a while and ended up using Action Context (something that the documentation on the web described as preferred and depreciated in different sources).

This solution didn’t sit well; after a bit of rethinking I finally got to the point where I decided to implement the SessionAware interface (which provides a Map parameterised setSession method) which worked when deployed but failed unit testing because I couldn’t figure out how to access the value of the session on the exit of the Action’s execute method.

The answer is easy, trivial almost but reflects the different way of thinking the new methodology requires. Since the injection engine will add the Session Context attribute map what goes into the setSession method is actually the container’s Session bound variables. Therefore when unit testing you just create a suitable map (Struts 2 doesn’t seem Generics aware but I presume the type is <String, ? extends Object>) pass it to the action via setSession but then retain a reference and test the content of the Map after the execute method of the Action has been called. It is easy but it is not easy to start thinking like this after Struts 1.

Standard
Java, Software, Work

Eclipse 3.3 M6

So I had a coding assignment to do the other day (it’s job seeking time again unfortunately) and I decided to to take the opportunity to test drive Eclipse 3.3M6 and Ant 1.7. Trying out software while also trying to make a good coding impression is probably a dumb idea and I don’t think I’ll be doing it again but still there’s never any better time than the present.

NetBeans has overtaken Eclipse as far as I am concerned, simply because Sun has managed to live up to the cross-platform hype with their Swing interface and seems to have lots of different interfaces to projects from other IDEs and various deployment platforms.

On the other hand I wouldn’t try and corral a legacy project into NetBeans. Eclipse is still my fave for that (and while things like the Web Tools project can be a mare to install and get running they do bring Enterprise functionality to an IDE that previously made you pay for it). So then is it worth getting excited about Eclipse Europa?

Sadly the answer seems to be no. There are a couple of nice tweaks to the interface but nothing major. In fact although I’ve used M6 at home a couple of times now I’m hard pressed to bring to mind what exactly is different (the refactoring dialog is a bit better for example). Stranger still, some aspects actually seem worse. Code Intelligence and Completion used to be Eclipse piece de resistance with NetBeans being a distinct second. This time though I had exactly the same issues with Eclipse as I did with NetBeans, wacky suggestions from obscure packages rather than the more obvious choices from, say, java.util or even the project I was working on. The good news is that Eclipse seems to learn quickly from previous choices and after an evening of coding was back to it’s usual self. Only some of the code templating seems to still be quirky.

Overall though after a years worth of feverish competition between NetBeans and Eclipse I was disappointed that Eclipse seems to be running out of steam or perhaps new ideas. Now my first thought was that perhaps there are only so many features that an IDE needs and perhaps we’re getting close to completion on them. That seems disappointing unambitious though and if there was nothing else to do I would say that some of the basics could do with a thorough revamping. Eclipse’s text editors are nothing to write home about with a lack of features that are standard in normal programmer’s editors (drag and drop seems particularly weird although there might be progress in 3.3) and options for the editors are still accessed via the labyrinthine preference menu rather than the intuitive right-clicking of the editor tab.

I’m not sure where Eclipse is going at the moment but I would be disappointed to see it just stand still, that’s good for no-one. Oh and before NetBeans gets all the love I do have to say that I was completely baffled by some Swing programming I was doing the other day in the NetBeans (not via Matisse), the problem turned out to be that I was running my class rather than the project and one rebuilds the application jar while the other doesn’t. There’s probably some logic in that but I don’t quite see it (probably because it’s tucked away in the run profile somewhere).

Standard
Uncategorized

TalkTalk Freakout

I use TalkTalk Broadband, partly because I used to work for Carphone Warehouse. The TalkTalk service is cheap but when you’re paying peanuts you do get monkeys. The most common problem I have with the broadband is that it suddenly gives up the ghost or that it runs slow and then stops seeing certain domains.

The answer to these solutions is simple and slightly embarassing in the light of the IT Crowd‘s catchphrase. Simply turn your router off and then back on again. If TalkTalk just put this simple instruction on the front of their support pages I would have only had to contact them once in the last six months.

Of course if that doesn’t work you’re going to have to find something else to do for half an hour while the TalkTalk engineers try and bring the system back up.

Standard
Java, Software, Work

Transfer Objects versus Value Objects

What are Transfer Objects and what are Value Objects? This is a question that has plagued me since I started Enterprise Java Programming. While Transfer Objects actually have a nice definition in the J2EE Design Patterns Value Objects are a different beast and various companies, individuals and organisations seem to have different ideas about what they are.

Some are naturally pretty hilarious (as are the implementations of most nebulous ideas in IT) the most ridiculous so far is that a Value Object is a collection of public fields. Pretty much like a struct in C. I think that came from a misunderstanding of the blueprint definition that states: the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods. Of course you still need to make the fields final if the object is to be immutable and a value object by definition is immutable.

Now though I feel I have enough of a working understand of the ideas to offer the following definitions.

Firstly a Value Object must be immutable, serializable and it’s content must be publicly accessible.  The content of a Value Object can be accessible via public final fields but to avoid the internal data becoming part of the public interface access should ideally be abstracted via getter methods. A value object should always be initialised entirely via its constructor; nesting value objects if necessary to avoid excessively long constructors.

A Value Object can only be changed and persisted by the creation of a new Value Object based on the values of the original Value Object obtained.

A Transfer Object while similar in most respects is mutable. In addition there is a reasonable expectation that the Transfer Object will be persisted if it is returned to the originating layer. So for example if a Session Bean provides a Transfer Object as the return value of one of its methods it is reasonable to expect the API to also provide a method that accepts an instance of the same Transfer Object. Any changes communicated to the Bean will be persisted and consistent so that if the original method that obtained the instance is called again it returns the values that have been returned to the layer and not the original object.

In this respect a Transfer Object is more the statement of expected behaviour on a Java Bean. I went to a talk about EJB3 where the speaker mentioned the detached object anti-pattern and I couldn’t agree more. Value Objects and Transfer Objects are really only useful in situations where the recipient layer is not really going to modify the objects that much. As soon as you allow POJO clones of entities to change value during a user transaction then you tend to get into all kinds of problems. It is exactly this kind of situation that ORMs and Hibernate clones tend to fall apart. They are great at obtaining Value Lists and dreadful at the kind of heavy lifting that is actually difficult and is where Entity Beans came a cropper in the first place.

Standard
Java, Macbook, Software, Swing

Outliners

I never really used an outliner before I got my MacBook, the Mac had a bundled copy of OmniOutliner. OmniOutliner is amazing and really blew me away. However as I’m not completely a Mac person I was looking for something that would work on more platforms. Being a Java type of guy I had a quick search of Sourceforge and Freshmeat and came up with JOE. Java Outline Editor, is a pretty nifty program that unfortunately does not seem to be being developed much at the moment. It is also oddly featured, it could be simple enough to be a single jar style application but instead the program has four or five jar dependencies for very marginal features. It’s Find/Replace and File Opener dialogs are customised and very highly featured. However the basic outline functionality is very simple.

Since it’s open source I’ve got it into Eclipse and started to hack it around abit. So far I’ve only been able to remove the XMLRPC and XP jar (as well as a couple of classes that have been replaced by Generics). The underlying model is not what I was expecting, nor is the actual implementation of the line rendering. I was also a bit surprised that the GUI elements are all built up from a XML file which was quite interesting. I was also a bit disappointed to find that JOE seems to smear preference directories in several places rather than just gathering them all under the User Home.

What I really want is a simple outliner that will work cross-platform and ideally will only be in one JAR. To that end I think the way ahead is to cut down JOE while also building from scratch a new small outliner in Java. That way, what I want will be a kind of meet-in-the-middle job.

The new outliner will be a way of understanding the Swing Event model (which I’m very hazy on) and a way to try and understand how the Application Model and the Swing components interact in a vaguely MVC way.

While looking at Outliners I also came across Jreepad which seems to be an excellent Java based replacement for my much loved JotNotes.

Standard
Software, Web Applications

Highrise

Highrise is the new product from 37signals. I use Tada List and that’s pretty good; Backpack is also good but a bit clunky to use and doesn’t generally wow people.

Highrise though is in a whole new league, on the face of it it is just a nifty web-based PIM that allows you to organise contact information. Useful and a slick as all 37Signals stuff is. However recently I started using it to keep track of the tasks and calls that I have to make as part of moving house. Suddenly the application isn’t just nifty it’s indispensable! Each note is properly dated and related to the contact information. It instantly answers the questions like: when did I call the broker about the mortgage? who do I need to follow up about income guarantees?

Another genius product!

Standard