We're trying to clean up our services at present, and as such are keen on investigating the @Configurable annotation for Spring 2.5. For those who aren't in the know, this uses aspects to allow Spring to configure new instances of an annotated class, allowing dependencies to magically appear in your new object, no factories required.

Black magic? Perhaps. Time will tell. But first we had to get it set up anyway.

In theory, this is simple. You have two choices: runtime or compile-time weaving. Compile-time means changing your build scripts. Runtime means either using a compliant classloader (WLS, for instance) or changing your JVM parameters (nasty for deployment). Given our lack of desire for deployment pain compile-time seemed the obvious choice.

As always, there was a Maven plug-in. As always, it didn't work. At least not with Spring 2.5.4. It turns out that Spring 2.5.4 broke compatibility with AspectJ 1.5.4. Worse, Spring's POMs were broken and it still depended on this incompatible version. So, task one: upgrade to Spring 2.5.5.

Secondly, the Maven plug-in still broke. So, check it out, change the version number and the AspectJ version, compile & upload to our internal repository. Task two: hack the Maven plug-in. I have a growing suspicion that this is a standard part of the Maven workflow.

Now, the easy bit - configure your POM. Except the examples need a bit of tweaking, not least because Java 5 is now old hat. Try the following:

<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjrt</artifactId>
    <version>1.6.0</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
    <version>2.5.5</version>
</dependency>

And:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <version>1.0-st</version>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>

        <showWeaveInfo>true</showWeaveInfo>
        <verbose>true</verbose>
        <proceedOnError>false</proceedOnError>

        <weaveDependencies>
            <weaveDependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
            </weaveDependency>
        </weaveDependencies>

        <aspectLibrarys>
            <aspectLibrary>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
            </aspectLibrary>
        </aspectLibrarys>
    </configuration>
</plugin>

Change the plug-in version number as required, of course.

Finally, step four: pimp your application. You'll need the following in your Spring configuration:

<context:spring-configured/>

Right, after all that you can start the @Configurable love. Create your bean:

package com.signtechno.example;

@Configurable
public class DummyBean {
    private int value;

    public void setValue(final int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

Create a Spring prototype:

<bean class=“com.signtechno.example.Dummy” scope=“prototype”>
    <property name=“value” value=“17”/>
</bean>

Create your logic:

final DummyBean dummyBean = new DummyBean();

And voila, dummyBean.getValue() == 17. Wasn't that easy?

I've just been propelled across the project barrier and into our GWT project. A project which took over 10m to compile ... and so I spent yesterday updating our Maven scripts to use the latest version of the plugin, and investigating speeding it up.

GWT generatates output based on (browsers supported) * (locales supported). Even with a single locale you're still generating HTML/JS for 6 browsers. Great for production, rubbish for development. And so, you can restrict them.

Modify your module gwt.xml to set the user.agent property. Your valid options are ie6, gecko, gecko1_8, safari and opera. You use set-property to set the first and extend-property to set extra agents, if required.

	<set-property name=“user.agent” value=“gecko1_8” />
	<extend-property name=“user.agent” values=“safari” />

And watch the build time drop! Be aware, however, that using the application in an unsupported browser will lead to some very odd errors.

Should you be using internationalisation you can also limit the supported locales in a similar manner. Just watch you don't ship the modified module!

Our client has just jumped from WLS 10.1 to 10.3. Unfortunately, Oracle have decided a point release was a great time to upgrade the required JVM to 10.6, so I'm back to struggling to get things working.

Currently, the best way seems to be:

1. Hack your JVM

WebLogic's installer won't detect the Apple JVM by default. To convince it that it's kosher, do the following as sudo:

cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
mkdir -p jre/bin
mkdir jre/lib
cd jre/bin
ln -s ../../bin/java 
cd ../lib
ln -s ../../../Classes/classes.jar rt.jar

2. Con the installer

Oracle still haven't fixed disc space detection, so you'll need to lie to the installer about your OS.

java -Dos.name=unix -jar server103_generic.jar

3. Knock your memory up a notch

You'll need to modify your <domain>/bin/setDomainEnv.sh file to increase memory settings. I use:

MEM_ARGS=“-Xms512m -Xmx1024m -XX:MaxPermSize=196m”

4. Enjoy the CPU stealing disc space crunching power of WLS

Fun for all, except your overworked laptop.

The last two days have been spent on one problem. A web service deployed on Axis 2 as an AAR module worked fine with Weblogic. It broke horribly on JBoss.

The solution turned out to be sticking the JAXB2, Activation and JMS libraries in the JBoss endorsed library directory. This is really, really bad. It's not (probably) too much of a problem for our application, as we're the only thing running on the server, but suddenly our modules are getting horribly polluted by rubbish up the tree. And since some of our older modules use JAXB1, this fast becomes painful.

Worse, before JBoss 4.0.2 there was a flat classloader. Honestly, you wouldn't even think of making this stuff up...

So at last I've found a reason to love Weblogic - the error messages are useless, but at least it gives you reasonable control over class loading.

Slowly, yet surely, J2ME is driving me completely mad. One of the nicer features of Java once write-once, run-anywhere - sure, you often need to arse around with user-interface tweaks (Swing for GTK+ and Mac OS X being prime examples), or with application server differences, but there's a decent chance your business logic will run correctly. With J2ME though, you seem to be in deeper and more dangerous waters.

Embedded devices do differ dramatically - far more than a PC differs from a Mac. So a JVM sounds like a superb idea - abstract away your hardware and run in a nice virtual environment. Except it hasn't worked out like that. While you always need to cope with differing input methods and screen sizes the problems are far more fundamental - fragmentation and just plain differing implementations.

J2ME is not one standard. It's not even two or three. Most mobiles will implement the CLDC and MIDP profiles - but which version? And which combination? What about the CDC? Will they have support for the various JSRs like web services or Bluetooth? Even vendors like Intent, who produce a VM for Windows Mobile, offer the JSRs as add-on modules, leaving it up to the OEM to decide just what the VM they supply will offer.

Secondly, the differences in implementations come back to haunt you. For instance, I have been writing a tree component. Easy in principle. Hard in practice. What worked nicely on the Sun emulator didn't draw most of the time on the MPowerPlayer emulator. This proved to be my bug - a badly placed return in the paint method - but it still doesn't show a damn thing on the Intent VM on my TyTN. Why? Who knows. Frankly, trying to debug the WM VM offers more pain that I'm interested in for a learn-J2ME project. I imagine it does keep those with products to deliver on their toes though.

Hot on the heels of Silverlight (perhaps too close to avoid calls of 'catch-up') comes JavaFX, Sun's answer to Flash and like (and hopefully solution to some of the joys of J2ME). One does, however, wonder if they've heard of brand dilution.

Unlike J2ME, however, this isn't Java but the scripting language formerly known as F3. However, the mobile part appears to be OEM-only, so we'll have to wait and see if it appears on many devices.

In other Java news, Sun are apparently starting to take the desktop seriously. There are good reasons why Swing hasn't done well: it has a steep learning curve and requires the threading of all but trivial tasks to get good performance, and in the past platform fidelity has been rubbish (the GTK+ theme is still extremely dodgy). Java 6 resolves most of the fidelity problem, and JSRs 295 and 296 should resolve some of the former. Of course, this still leaves the widespread belief that Java is rubbish on the desktop, which may be the hardest bit to overcome. All the more reason to ensure that your Swing application integrates with the desktop and thus that the user doesn't know (or care) what powers it.

Having recently acquired a Pocket PC phone with 3.5G internet, I find myself in need of a feed-reader. I use NetNewsWire on my Mac - and it is superb - and NewsGator to ensure that I need only read once across all my devices. However, NewsGator has two flaws: firstly, there is no Linux client, forcing you to use the somewhat rubbish web interface; and secondly, the Windows Mobile client is mediocre at best, not to mention pricey.

What to do? Well, write one of course. And the most tempting target would be .NET Compact Framework. It allows you to build for the PPC in a high-level language with a nice framework. Plus, it would be nice to learn some C#. But then I ran into a problem - Microsoft firmly believe that no one uses anything but Windows. Hence, all their development tools are only available for Windows.

Microsoft are daft on development tools - unlike the world of Java, where everyone and his dog offers an IDE and most are free and really rather good, Microsoft prefer to make life easy only if you buy Visual Studio. Great for corporates, for whom a MSDN subscription is a small investment. Bad for individuals, small companies and those who just want to learn. They have released a SDK for .NET Compact version 2.0, but you'll still be hunting elsewhere to find a nice environment.

But this is all beside the point for those with a Linux box or a Mac. Yes, there is Mono, although the most I could find about .NET Compact support was a comment about having to hack assemblies to get the .NET runtime to accept them. All in all, it would appear Microsoft doesn't want to make it easy to develop for their flagship mobile OS. Indeed, they seem positively desperate to ensure it stays chained to a Windows PC.

So, I've ended up falling back on J2ME. J2ME is maddening in some ways - it's very basic, it's very modular (and hence your never sure what device supports what version of what), has a very small standard library and lacks environmental integration on some platforms (such as, surprise, Pocket PC). The UI structures are extremely basic - I'm having to write my own tree control, for instance. But, on the other hand, the SDK was a 40Mb download, and I was up in running in IntelliJ in minutes. (Or, you can download NetBeans and the Mobility Pack for a free environment).

It's annoying in a way, as I've played with J2ME in the past and wanted to try something new. But at the end of the day I'd rather cut code then arse about with the basics.

I'm not chuffed. I've been working on a WS client (among other things) for the testers during some downtime, and run into a little problem: Axis 2 won't play ball with Java 6.

I'm caught between the proverbial rock and a hard place here: Axis 2 is a moderately buggy new product with a bunch of developers who don't bother checking their bug reports quite often (or suggested fixes) but that does make life very easy for those who want to handle their XML manually. As for Sun, Sun are the tits who decided that Java 6 should have the kitchen sink fitted as well. So I'm tending towards Sun for blame, for indulging that sloppy level of though that thinks optional libraries are a bad thing. So, I'm left with buggering around with endorsed libraries (for a client app?), forcing Java 5 or changing the stack (which gets more and more tempting).

This is a nasty trend. BEA do it with bloody WebLogic (the 'bloody' is usually found in conjunction with WLS). Given the tendency of XML tools to self-register and BEA to break things that can make life extremely unpleasant (BEA's StAX API is somewhat rubbish with string conversions, for instance, but replacing it is somewhat messy). And now Sun are well on board this bandwagon with Java 6, including a database, JAX-WS (which is an enterprise tool) and another XML API, StAX. Do these really need to be in the core? I think not.

One can only hope that, with the open sourcing of the JDK, this will not be the start of a slippery slope, with the move to a one-size-fits-all solution instead of a lean core and easy to use optional extensions. As frankly, some of us have work to do and the last thing I need is more classpath pain just to make the marketing people at Sun a bit happier.

At work we use the world's worst version control system (VCS). Actually I kid - we're not using Microsoft SourceSafe. As previously mentioned we're using MKS, which lacks Mac support. So I went out and purchased a copy of Parallels and sent up Ubuntu.

This proved to be harder than was expected. Firstly, because the fine people who package Ubuntu decided to use the GPL implementation of Java, which didn't work with anything useful. So after installing Sun Java I moved on to directory servers. This got worse - Sun Application Server wouldn't install, due to missing shared libraries, and so I tried Fedora Directory Server. Even with a HowTo I haven't managed to get the admin interface working, not to mention the need to track down extra packages from Ubuntu 5 and hack, hack, hack. Sigh. But, finally, a working environment. However, he thought does occur that I would have been finished much earlier had I just installed Windows.

Parallels is quite a nice beast though. It's affordable (£40) and fairly solid. The sound support is a bit spotty (or Ubuntu is, it's hard to tell) and there's no dual-head support, but it's fast enough (using the current beta) for work to get done.

On a similar note, CodeWeavers have finally released their long promised August beta of CrossOver Office. It all seems very nice - much easier to get going than Darwine, obviously - and unlike Darwine is running Steam and has almost finished installing Half-life 2. So it appears I may have to do some stress testing tonight ... oh, the sacrifices we make.

Plus, there's a nice warm geeky feeling in running Steam alongside Ubuntu under Parallels while browsing NetNewsWire...

At last I have an excuse for my tardiness in updating this so-called blog. I've spent the last two weeks avoid trivial pursuits like games and reading my book on the politics of Africa - instead I've been programming, playing with the MVC framework WebWork 2.

Why WebWork 2? Well, I've got a task to complete and I've significant expertise in Java. WebWork 2 is lined up as the basis for Struts 2, which is quite an endorsement. And while Ruby on Rails is all very neat, so in IntelliJ 6.0 (beta). So I've been mocking up a simple user management system, with the now-standard toys like adding list items without the pain of a page reload.

What's good? It's a streamlined Struts. While many of the concepts remain the same you have much more control over the workflow, more options in how the code is structured and lots more done by convention over configuration.

What's not so good? It uses the OGNL stack so it has custom tags. It doesn't make indexed properties easy, something Struts mastered in 2003. And the documentation is spotty - there are lots of gaps and quite a few contradictory areas. And given the emphasis on convention over configuration it can lead to some quite mysterious behaviour.

It is certainly a framework with a lot of promise though. My suggestions would be simple support for indexed properties - just why do I need to generate indices? - and general robustness (the validators don't handle null items in lists for instance). And, of course, clear, in-depth and accurate documentation. Maybe these things will come as part of Struts 2.0. Or I could even add them: the joys of open source. But, of course, for the free time to do it.