Nelz's Blog » Java

Project Begets Love for AppEngine and Python at Java’s Expense

nelz9999 — Thu, 28 Oct 2010 07:33:58 +0000

The Project

For the past year or two I’ve had an ongoing side project where I post to the Twitter account @bman_countdown. It started out as just a simple countdown, but I realized I could use it as an opportunity to provide more information about the event, so I started to tack on links to relevant content on the BurningMan.com website.

Over time I’ve increased the functionality from being a static set of links, to mixing in the most recent blog post from the Burning Blog. (Actually, this functionality just went live today.)

This has been a great ‘toy’ project that I use to experiment with different technologies.

The Environment

For the first couple of iterations it was a Ruby script that I ran off of my ‘media server’ (a Mac Mini which I had set up as recommended by MacMiniColo). To emulate cron functionality, I used launchd to run the script once a day.

Predictably, this setup caused some hiccups in the continuity of the service: when my ISP service went out; when my router borked; when the hard drive failed; when I moved; etc. (Yay for providing non-mission-critical projects!)

Around the time of the 2010 Burning Man event, Twitter removed the ability to use Basic Auth, which is what the library I used relied upon. I decided the service could take a break right after the event while I figured out what I was going to do with it.

I had done some minor playing with Google AppEngine in Java, so I was familiar with the basic services GAE provides. (I love AppEngine’s first-class cron support. And the TaskQueue concept ecourages truly asynchronous and scalable design.) But, since this project is what I use to experiment with stuff, I figured I’d try out Python.

Meeting Python

First, I had to get up to speed on Python itself. So, I got the book Programming in Python 3. I studied several chapters of this book and did a couple of the ‘programming assignments’ (which I thought was a great idea), until I felt I was familiar enough with the language to take a poke at upgrading the countdown.

I came to realize that the process of developing in Python is so easy! (Even more so in GAE, as the development server environment that you get is great, and shit just works: just save the changes to the file and you can hit the page, and you get instant feedback.)

I know I’m a latecomer and I am treading dangerously close to Programming Language War territory here, but I have to say that I am entirely fed up with the edit/build/deploy cycle that leaks time and energy in Java projects. Do you realize that in big Java shops, there are engineers whose entire function is to iterate on the build process? Remember that whole “Google App Engine in Maven + IntelliJ” blog post that I made? In Python, the build-cycle-via-build-tool process doesn’t exist. Imagine a future where you don’t need to wrestle through Maven’s bullshit to get stuff done. I can see this future in Python, and it gives me tingles in my naughty bits!

Sure, I’ve got rose-colored glasses on here. I am a native speaker of high-protocol Java (my kingdom for a native “?” operator!), who is currently a tourist in a strange land speaking a stilted pidgin version of Python. Admittedly, I have an incomplete grasp on what the costs and benefits are when moving from a compiled language to an interpreted one. But it sure seems easier so far.

Future of Java

I was originally pulling for the Java ecosystem, whether that comes from a selfish (it’s where my bread gets buttered) or a philanthropic (because I’ve seen so much good Open Source stuff come out of it) point of view, I’m not sure. I was happy when some very smart people talked about ways that at least the JVM could stay relevant by embracing more dynamic languages built on top of it.

But then there was last weeks announcement that Mac OS X would deprecate support for Java. This generated a lot of excellent discussion. My favorite post both described why this is a death knell for Java, while also outlining a strategy for ensuring Java could continue to function (by breaking up it’s fairly monolithic API into discrete modules).

Alas, because of a very specific interaction I had, I fear Chris Adamson’s cogent post will probably be ignored by Oracle. Back when the news came out that Oracle was buying Sun and therefore Java and MySQL, I spoke to a friend of mine who worked for Oracle. I told him I didn’t care if Oracle owned Java and MySQL as long as they didn’t fuck it up. His response: “Don’t worry. We’ll fuck it up.”

The mere fact that I heard this kind of pessimism coming from an employee within Oracle makes me think Java will be viewed more and more as a legacy system in the months and years to come.

TestNG vs JUnit4

nelz9999 — Wed, 06 Oct 2010 21:06:16 +0000

JUnit has done huge things for the programming community. It really helped to usher “The Age of Testing” into being. I will always say that. However, I have to say that when starting a new Java project, using TestNG is the right choice.

Here is how I see things happening:

Project starts. Choose the ‘industry standard’ JUnit. Heck, let’s even go with JUnit 4 because it supports Java 5 Annotations.
JUnit works great for unit tests.
Hey, we want to write an integration test (talking to a db? setting up a Spring ApplicationContext?) as well. We’re already using JUnit, so let’s keep using it for the new integration tests too.
Let’s write a second (and third; and more) integration test within JUnit just like that first one we wrote.
Hey, why is the build taking so long? Oh, hey, JUnit is causing us to do some heavyweight operations for each individual tests. Is there some way to only do the heavy operations once per a suite of tests?
Blogosphere says: “JUnit is a unit testing framework, it’s not meant for integration testing”; “You are doing it wrong”; “Sure you can do that, here’s the horrible atrocity of code that you need to implement to make it possible”.
Find that TestNG has a richer lifecycle and can help with this integration test scenario, while still being easy to use for unit tests. Shake your fist at the air in impotent rage that you didn’t just start with TestNG.

I’ve personally seen this happen in at least 2 large projects.

I am currently in the “impotent rage” phase of the cycle. My original impetus to write this blog post was to say that someone(*) should write the class that combines the org.junit.runners.Suite functionality and Spring’s AbstractTransactionalJUnit4SpringContextTests.

Here’s the straight scoop: You are probably going to want to do some integration testing in addition to unit testing. TestNG may only be a bit different from JUnit, but it is just enough different in all the right ways to make it the tool you want to use.

(*) I know I should consider doing it. I will add it directly to the top of my “Things That Should Get Done But Won’t Ever See the Light of Day” list.

More Maven Angst

nelz9999 — Tue, 19 Jan 2010 22:20:28 +0000

I don’t want to just jump on Maven-bashing bandwagon here, but a casual perusal of my previous posts will show that I talk about Maven a lot. This is going to be another one of those posts.

I’ve been starting to play with Google App Engine, both for personal projects and at work. Since most of my environments are Maven-based, I thought I’d go out and find a Maven Archetype or some kind of a POM file to bring these projects into my environment. I did find several blog posts trying to help: here, here, etc… The annoying thing you’ll notice on those blog posts is that Brian Fox ((formerly?) of Sonatype) posts a comment pointing towards Jason van Zyl’s post describing his efforts to Maven-ize the GAE SDK.

That would be all well and good if things had actually progressed. If you look at JvZ’s post, you’ll see he ends with “hopefully I’ll be able to get this out for Maven users by the end of the week!” What happens after that? Bupkis, nil, nothing, NADA!

There’s comments as late as Dec ’09 expressing interest to use and/or help with the effort. But, there is NO RESPONSE from anyone at Sonatype.

I just find it galling that Sonatype would go on an all-out publicity spree talking people out of working on their own because JvZ himself was going to bring his skills to bear on the problem, only to completely fizzle out. I suspect the community at large would have been better off if those 4 or 5 early Maven + GAE adopters had continued on their own path, even if JvZ had succeeded.

Again: my patience with Maven/JvZ is waning. I’m eager to see what comes along next to take its place.

Precompile JSPs for Tomcat 6

nelz9999 — Tue, 20 Oct 2009 23:34:11 +0000

At the day job, we are working to upgrade our Tomcat from 5.5.X to 6.0.Y. The biggest problem I found when running our app against Tomcat 6 was that a bunch of JSPs used some quote escaping patterns that the later version of the compile considered to be syntax errors.

To get a feel for how many of these problems existed (after I just-in-time fixed the individual JSPs that crossed my path), the boss wanted me to run a precompile against our whole JSP codebase.

I found the instructions on the Tomcat site, which proved to be incomplete and/or incorrect (of course).

Here is what I ended up with:

The real stroke of luck is this piece:

             compilerTargetVM="1.5"
             compilerSourceVM="1.5"

Their document said stuff about adding some parameters (source="1.5" target="1.5") to the “javac” target, but they neglected the “jasper” target. The error messages complained about the above two parameters being set to 1.4, so as an experiment I plugged them into the ANT target with 1.5′s and the compilation ran correctly!

Another word of note, the “showSuccess” directive did not work as their documentation states, but the “failOnError” directive does.

I hope this helps others!

Maven Tomcat Plugin

nelz9999 — Thu, 20 Aug 2009 17:28:25 +0000

Maven. It is both fantastic, and stress-inducing. And more than just Maven itself, there is a whole community of Maven plugins which are just as frustrating.

Take the Maven Tomcat Plugin for example. It sounds so nice to just type “mvn tomcat:run” in your webapp module, and have it automagically run, dynamically loading any JSP changes. But, if you have a non-trivial webapp, you probably need to send in some system properties.

Let’s pretend that I require the following command-line parameters passed to Tomcat on the command line:

-Dexample.value.1=alpha -Dexample.value.2=beta

How would I send that in to the Tomcat plugin? Well, the documentation says there is a “systemProperties” element where you can sent them in. But what is the format?

Is the format perhaps like the Surefire Plugin?


  
    example.value.1
    alpha
  
  
    example.value.2
    beta

Or perhaps the format is like that of the Jetty Plugin?


  
    example.value.1
    alpha
  
  
    example.value.2
    beta

Nope. The format is like neither of those. It’s like this:


  alpha
  beta

I’ll admit that this format is a bit less verbose. But why, in the name of all that is holy, does it have to have it’s own 1-off syntax?!? And can you find this documented anywhere else? I was sure challenged finding it.

This is the kind of non-documentation and irregularity that gives Maven a bad name and keeps my blood pressure high.

UPDATE (1 Nov 09): As she says in the comments, Kathy actually took the time to submit a ticket to the Maven Tomcat Plugin maintainers, rather than going with my tactic of passively bitching. And today I get notified by herion that the suggestion was taken and there is now public documentation added about these properties.

Maven, TestNG, and SeleniumRC

nelz9999 — Fri, 31 Jul 2009 06:01:45 +0000

Today, I set up a Maven module to run SeleniumRC (Java) tests via TestNG. It wasn’t a straightforward or easy task, so I thought I’d share some of what I found with you.

We opt to have all of our modules stay in lock-step version-wise, so we keep a pretty large structure in our SVN trunk. We include/exclude modules for compilation by using Maven profiles, so we don’t have to build the whole structure if we are only changing one small component. Our top-level pom.xml file looks similar to this:


  ...
  ...
  ...
  pom
  
    baseModule
  
  
    
      all
      
        otherModule
        ...
        web-test
      
    
    
      web-test
      
        web-test

As you can see, running “mvn clean install” at this top level would only end up building the baseModule. To get all the modules, we run “mvn clean install -Pall” which builds baseModule along with otherModule and web-test and anything else as represented by the ellipse. The web-test module is the one we will be interested in.

For our heavy-weight tests (non-unit tests, like functional or web testing), we like to have the module compile, but not run unless we specifically trigger the tests. To achieve this, we create a pom.xml (for the web-test module) that looks something like this:


  ...
  web-test
  pom
  
    src/it/java
    
      
        src/it/resources
      
    
    
      
        org.apache.maven.plugins
        maven-compiler-plugin
        2.0.2
        
          1.5
          1.5
        
        
          
            
              testCompile
            
          
        
      
      
        org.apache.maven.plugins
        maven-surefire-plugin
        2.4.2
        
          src/it/java
          web-test
        
        
          
            integration-test
            
              test

This pom has several features:

It sets up src/it/java as the location holding the source code for the tests
It sets the surefire plugin (which runs your tests) to only run at the integration-test part of the Maven lifecycle
It says to ignore any tests in the TestNG “web-test” group
Note the packaging says this module is of the type “pom”. I found that if this is set to “jar”, the tests run twice for some unknown reason

Now, if you had tests in src/it/java (that were all annotated as “web-test”) and you ran “mvn clean install”, you’d see that zero tests ran. This is what we want! Now, we have to get the tests running if we pass a specific profile in. To achieve this, I added the following profile definition to the web-test pom.xml.


    
      run-web-test
      
        
          
            org.apache.maven.plugins
            maven-surefire-plugin
            2.4.2
            
              
                src/it/resources/testng.xml
              
              
              
            
            
              
                integration-test
                
                  test

This profile is invoked when you run “mvn clean install -Prun-web-test”. There are several things I’d like to point out here:

At runtime, this overrides the previously-declared surefire plugin configuration, but only when invoking the profile.
Originally, I was mostly getting stuff to work without the section, but with the and sections… But it was running every single test class as it’s own TestSuite.
To fix the multiple TestSuite (and @Before*, @After* problems that I’ll discuss later), I ended creating my own testng.xml file. Having this file and using the element made things a whole lot easier for configuring my TestNG executions than trying to configure the tests through the clumsy interference of the surefire plugin.
As much as I like Maven, I have to say that the lack of documentation and general obfuscation that happens when using their plugins can really drive a person BATTY!

Now, I need to start integrating the stuff I need for using SeleniumRC. I found some decent help on how to start up and shut down the selenium-server, however I disagree with using a post-integration-test phase to shut down the server, because if the tests fail in the integration-test, Maven won’t progress to the next phase and you’ll be left with a spuriously running selenium-server. The client API’s do have access to the command that the was being run to shut the server down, so it is just a matter of having some TestNG @AfterSuite or @AfterGroup method issue the Selenium.shutDownSeleniumServer() command.

This brings me to some of the TestNG wonkiness I saw. I decided to use a Singleton Data Provider (named SeleniumFactory) to deliver the Selenium objects to the individual tests. (Selenium objects are time-expensive to create, so I wanted to only create 1 for the duration of the entire test suite.) I wanted to initialize the SeleniumFactory object in a @BeforeGroup method, deliver the Selenium object as a Data Provider, and then tear the SeleniumFactory down in a @AfterGroup method. (At first, I was fighting Maven’s handling of each test as its own test suite which was giving me sequence issues, which is why I ended up defining my own testng.xml file, as I stated above.) Let me start with some code to show you what I mean:

public class SequenceEndsTest {
    @BeforeGroups(groups = {"web-test"})
    public void startupSelenium() {
        System.out.println("-- > Called startup.");
    }
    @AfterGroups(groups = {"web-test"}, alwaysRun = true)
    public void cleanupSelenium() {
        System.out.println("-- > Called cleanup.");
    }
}
public class SeleniumFactory {
    @DataProvider(name = "selenium")
    public static Object[][] getSelenium() {
        System.out.println("-- > Called data provider.");
        return new Object[][] { new Object[] {null}};
    }
}
public class SequenceTest {
    @Test(groups={"web-test"},
            dataProvider = "selenium", dataProviderClass = SeleniumFactory.class)
    public void testSomething(final Selenium selenium) {
        System.out.println("-- > Called test.");
    }
}

This is what I expected to see after running this code:

-- > Called startup.
-- > Called data provider.
-- > Called test.
-- > Called cleanup.

But this is what I *actually* saw:

-- > Called data provider.
-- > Called startup.
-- > Called test.
-- > Called cleanup.

I would have assumed that an @BeforeGroup method got called before a data provider method, but I guess my assumption is wrong, eh? After I figured out this order-of-method-calls business, I was able to adapt my SeleniumFactory accordingly.

… And that is my story. To summarize: each of these tools could be better documented, but at the end of the day I was able to get a Maven module up and running SeleniumRC tests via TestNG. Now, on to the test-writing!

The Life of a boolean

nelz9999 — Thu, 28 May 2009 23:59:46 +0000

Java booleans came up in conversation today, and I wanted to point out a couple of things that I’ve noticed.

Firstly, when talking about (capital ‘B’) Booleans, it is possible to achieve a trinary state object: TRUE/FALSE/null. However, it is not recommended. In fact, I’d go so far as to recommend breaking the fingers of anyone who tried to perpetrate this horrible pattern in your code.

Secondly, I’d like to discuss booleans in your model objects. I agree that it frequently seems like a good idea to include one in your model object. However, I have seen so many occurrences where, over time, it becomes necessary to add a third (or fourth, or fifth) state. Even the RDBMSes are hedging their bets by storing boolean flags as TINYINTs. I would suggest that you seriously consider using an Enum to represent your two states as they exist at the beginning of their lifecycle… This way you won’t get stuck with a bunch of isXXX() accessors that all have to be refactored as soon as you add a third state.

JDK 1.6 on OS X

nelz9999 — Wed, 13 May 2009 15:32:54 +0000

For Widgetbox I was recently tasked with investigating a new Java memcached client called xmemcached.

Things were going smoothly (except that the xmemcached documentation is written mostly in Chinese)… But then I hit a bump in the road: the xmemcached JAR file was compiled for JDK 1.6.

Up until this point, all our code was using JDK 1.5, and we had only vague plans to eventually upgrade to JDK 1.6. Upon discussion, I’m just gonna work on the 1.6 stuff in a branch until we get the rest of the development team and operating environments up to a JDK 1.6 standard.

So, I went about upping my chosen JDK via the "Java Preferences" dialog.

Now, I saw something like this:

$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)

Awesome. That’s exactly what I wanted!

But hold the phone, I was also getting this:

$ mvn -v
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix"

So, I did some digging. With some hints, I found that the executable /usr/bin/mvn uses the symlink "CurrentJDK" to figure out which JDK to run, and the "Java Preferences" panel doesn’t update that when you change JDKs. (Dumb!)

So, here’s how I fixed it:

$ cd /System/Library/Frameworks/JavaVM.framework/Versions/
$ ls -la
...
lrwxr-xr-x   1 root  wheel    5 Sep 29  2008 1.5 -> 1.5.0
drwxr-xr-x   8 root  wheel  272 Feb 21  2008 1.5.0
lrwxr-xr-x   1 root  wheel    5 Sep 29  2008 1.6 -> 1.6.0
drwxr-xr-x   8 root  wheel  272 May  6  2008 1.6.0
lrwxr-xr-x   1 root  wheel    3 May 12 18:18 CurrentJDK -> 1.5
...
$ sudo rm CurrentJDK
$ sudo ln -s 1.6 CurrentJDK

Now, I am seeing the environment I want:

$ ls -la
...
lrwxr-xr-x   1 root  wheel    5 Sep 29  2008 1.5 -> 1.5.0
drwxr-xr-x   8 root  wheel  272 Feb 21  2008 1.5.0
lrwxr-xr-x   1 root  wheel    5 Sep 29  2008 1.6 -> 1.6.0
drwxr-xr-x   8 root  wheel  272 May  6  2008 1.6.0
lrwxr-xr-x   1 root  wheel    3 May 12 18:18 CurrentJDK -> 1.6
...
$ mvn -v
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.6" arch: "x86_64" Family: "mac"

Java 5 Auto-Unbox Is Not NULL Safe

nelz9999 — Wed, 25 Mar 2009 16:03:21 +0000

Yuck!

I am kinda getting fed up with the way the language implementers of Java continually add all these conveniences, but leave them 1/2 baked.

Example:

01public class UnboxTest {
02    @Test
03    public void testUnbox() {
04        final Integer a = Integer.valueOf(10);
05        final Integer b = null;
06        unboxIt(a);
07        unboxIt(b);
08    }
09    void unboxIt(final int value) {
10        System.out.println("Value: " + value);
11    }
12}

Guess what happens when you run this code?

A big, fat NullPointerException on line 7.

Oh yeah… Autoboxing is supposed to be soo helpful, but they can’t default a frigging null to the default value of an int. (I.e. 0)

See my previous post for similar problems in the Java 5 foreach syntax.

SeleniumRC and FireFox3

nelz9999 — Fri, 09 Jan 2009 14:21:29 +0000

We have started playing with Selenium for some automated testing at my day job. (I’ve been a proponent of Selenium, but I haven’t played with it directly for a bit.)

I ran into a problem, as described by the Space Vatican. Luckily, he also had the solution to the problem.

I took his command-line instructions and created two scripts to run those command on a given file (‘cuz my file was named differently than the one in his script). Here are the contents of the script:

jar xf $1 customProfileDirCUSTFFCHROME/extensions/readystate@openqa.org/install.rdf
jar xf $1 customProfileDirCUSTFFCHROME/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
jar xf $1 customProfileDirCUSTFFCHROME/extensions/\{503A0CD4-EDC8-489b-853B-19E0BAA8F0A4\}/install.rdf
jar xf $1 customProfileDirCUSTFF/extensions/readystate\@openqa.org/install.rdf
jar xf $1 customProfileDirCUSTFF/extensions/\{538F0036-F358-4f84-A764-89FB437166B4\}/install.rdf

jar uf $1 customProfileDirCUSTFFCHROME/extensions/readystate@openqa.org/install.rdf
jar uf $1 customProfileDirCUSTFFCHROME/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
jar uf $1 customProfileDirCUSTFFCHROME/extensions/\{503A0CD4-EDC8-489b-853B-19E0BAA8F0A4\}/install.rdf
jar uf $1 customProfileDirCUSTFF/extensions/readystate\@openqa.org/install.rdf
jar uf $1 customProfileDirCUSTFF/extensions/\{538F0036-F358-4f84-A764-89FB437166B4\}/install.rdf

And if you’d like, and feel like trusting me, here is the resultant, FF3-friendly, jar file : selenium-server-1.0-beta-1.jar

Compile-Time Dependencies

nelz9999 — Sat, 18 Oct 2008 11:57:38 +0000

When building out your architecture, I would encourage you to break out your APIs as first-class modules. (Sorry, a ‘module’ is Maven speak for the parts of a project that create their own artifacts such as JAR or WAR files.)

For an example of a simple suggested structure, look at the following image. (Arrows denote compile-time dependencies.):

In some of my recent projects I received some push-back on breaking out the APIs. The concern was that breaking them out as modules would add overhead to the build process. I do understand that concern, but I think it is a minimized threat if you are using a fairly sophisticated build system.

I acquiesced at the time, and now we have a structure that looks similar to the next image. (Can you see the problem already?):

The black arrow indicates just one of the weaknesses of this model. Here, you can see that a UI component can (at the least offensive) access the DAO API as well as (at the most offensive) access the concrete DAO implementations.

When you have a structure like this, the question is not if, but when will one of your fellow engineers take advantage of this and circumvent the nice functional striations that you have taken so much time to isolate?

XMLUnit and TestNG

nelz9999 — Tue, 14 Oct 2008 17:50:12 +0000

Our entire testing system is based on TestNG, but one of our developers recently invoked XMLUnit to test some of the XML he was producing.

Now, XMLUnit is built to be used with JUnit (old JUnit… like 3.8.1 style JUnit…), which at first glance doesn’t seem to play well with TestNG test runners. (We were having some build timeouts and other mysterious behavior when trying to run these tests.)

To give you an idea, here is a snippet from the examples:

package net.nelz.test.xmlunit;
import org.custommonkey.xmlunit.XMLTestCase;
public class MyXMLTestCase extends XMLTestCase {
public MyXMLTestCase(String name) {
super(name);
}
public void testForEquality() throws Exception {
String myControlXML = "0x00435A8C";
String myTestXML = "2376";
assertXMLEqual("comparing test xml to control xml", myControlXML, myTestXML);
assertXMLNotEqual("test xml not similar to control xml", myControlXML, myTestXML);
}
}

If you look at that example, the only methods that seem to add any value are assertXMLEqual(...) and assertXMLNotEqual(...).

If you look at the source code for those methods, you’ll realize that they just delegate to parallel static methods in the class XMLAssert:

...
public void assertXMLEqual(String control, String test)
throws SAXException, IOException {
XMLAssert.assertXMLEqual(control, test);
}
...

What this all means is that XMLUnit already is TestNG friendly. Here’s what that snippet from XMLUnit’s example code would look like if it were rewritten to target TestNG.:

package net.nelz.test.xmlunit;
import org.custommonkey.xmlunit.XMLAssert;
import org.testng.annotations.Test;
public class MyXMLTestCase {
@Test
public void testForEquality() throws Exception {
String myControlXML = "0x00435A8C";
String myTestXML = "2376";
XMLAssert.assertXMLEqual("comparing test xml to control xml", myControlXML, myTestXML);
XMLAssert.assertXMLNotEqual("test xml not similar to control xml", myControlXML, myTestXML);
}
}

Spring JMX Challenges

nelz9999 — Fri, 10 Oct 2008 13:33:21 +0000

Yesterday I started to do some clean-up work around how we are using Spring and JMX in some of our webapps.

We started off with a very basic configuration:

...




...



...

By default, this exposes all public methods for management, which is overkill for us. So I wanted to use the Java 5 Annotation capabilities to expose only those methods that are appropriate for management. This brought us to the following configuration:

...





...







...

This worked for most of the beans, but when I tried to port this one bean to the new Annotation-based interface definition, I kept getting a nasty stack-trace upon startup, the root of which says "MetadataMBeanInfoAssembler does not support JDK dynamic proxies - export the target beans directly or use CGLIB proxies instead".

I couldn’t figure out for the life of me what the structural difference was between this one bean, and all the others… I tried changing around the other annotations in the class, substituting other beans from the same layer, everything. I couldn’t figure it out.

After a bit, I decided to give up on adding the Annotations to that one bean, but I still wanted to expose the bean. I couldn’t find documentation on this, but it turns out that you are completely able to have multiple "exporters" invoked in your Spring configuration files. This gave me a configuration like this:

...





...














...

Great. This worked. I was able to manage the problem bean, and I was able to define the interface to all the other beans via the Annotations. But, when I went to manage the problem bean via the JMX console, there were all sort of dynamic proxy methods exposed…

This got me thinking back to the stack trace:

~MetadataMBeanInfoAssembler does not support JDK dynamic proxies - export the target beans directly or use CGLIB proxies instead

… I definitely see other traces of dynamic proxying in the JMX interface itself.

Then it hit me: AOP. The one thing that was different between the problem bean and all the other beans is that the problem bean is being AOP’ed.

Doing some research on that stack trace error message, I found this discussion. They seem to have figured out there’s a conflict with the MetadataMBeanInfoAssembler and dynamically proxied classes, but I’m still unclear (until further testing) if the suggestion to "set the proxyTargetClass property of your ProxyFactoryBean to true" will work.

In summation, here are the learnings:

MetadataMBeanInfoAssembler is challenged with defining an interface based on Annotations of an AOP’ed class.
It is trivial to define multiple MBeanExporter‘s with different configurations if you need to.

Back in Action!

nelz9999 — Tue, 09 Sep 2008 20:11:02 +0000

I am now back from Burning Man, and having a fairly smooth re-adjustment to this so called real world.

Spring AOP and Internal Method Calls

When using AspectJ with Spring’s AOP framework, I didn’t realize that there were challenges getting AOP to work when a member method calls to a sibling method.

Here’s an example I’ve borrowed from some discussion of this phenomenon:

public class MyService {
public methodA()
{
//do something
methodB();
//do something
}
public methodB()
{
//do something else
}
}

Now both the method in the service have been AOPed, and when I call the methodA() on the proxied instance, the methodA() will have the benefit of the aspect, but when the methodB() gets called from methodA(), it would not get that benefit of AOP.

Used strategically, I think this can be a benefit. When I came upon this problem, I basically used it as an opportunity to refactor "methodB" (and it’s associated overhead) into a new stand-alone class. This may not always solve your specific problem, but it worked in my one case so far.

Applying the Java Keyword ‘final’ To Classes

nelz9999 — Wed, 21 May 2008 18:11:26 +0000

I was ponderin’ the usages of the final keyword as applied to classes in Java.

I have heard before that all classes should be defined as final by default. The theory goes that unless you are specifically designing (and testing) your classes as potentially extensible, the final class modifier is a nice ‘pertinent negative’.

In practice, this theory falls apart.

If you are exposing your concrete classes to other clients, a final class can neuter the consumer’s ability to mock your class for testing purposes. (I ran into this at one point when using Lucene at work, and tried to mock out a class.)

Another problem that arises, even if you have hidden all your concrete classes behind a nice API, is that final classes are not accessible by AOP. (At least, not in the framework that I looked into.)

Revelation of the Day

nelz9999 — Tue, 13 May 2008 23:36:28 +0000

This revelation hit me (and my coworkers) today: Caching is a cross-cutting concern…

You many not understand the implications of that phrase, but it leads to some interesting stuff…

Tomcat ROOT Context

nelz9999 — Sun, 11 May 2008 11:04:07 +0000

I’ve been fighting with Tomcat a bunch this week.

My specific challenges have been around configuring a webapp to have the context root of "/", without having to name it ROOT.war…

The documentation page on context configuration says that "Context elements may be explicitly defined":

in the $CATALINA_HOME/conf/context.xml file- the Context element information will be loaded by all webapps
in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file- the Context element information will be loaded by all webapps of that host
in individual files (with a .xml extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml.
if the previous file was not found for this application, in an individual file at /META-INF/context.xml inside the application files
inside a Host element in the main conf/server.xml

In my experience this week, the option of creating the file $CATALINA_HOME/conf/[enginename]/[hostname]/ROOT.xml didn’t work for me.

But, one of my coworkers (Chris) found some other resource somewhere that said you could create a $CATALINA_HOME/webapps/ROOT.xml that looked like this:

Chris tried this setup, and it seemed to work for him. Here’s my caveats:

I haven’t verified this myself yet.
I’m not sure if it has to be an exploded WAR file structure, or if it can be a WAR file itself.

I will update if I find that this actually does work.

Helpful Maven Command: “mvn dependency:tree”

nelz9999 — Wed, 30 Apr 2008 23:49:05 +0000

Sometimes you need to peruse the dependencies (and transitive dependencies) within your Maven project. The "mvn site" command generates a pretty nice version of this in HTML. (Example: Jetty Maven Plugin – Depenencies Report.)

Well, the good news is that you don’t need to go through the whole "mvn site" generation to find out this information, as the "dependency" plugin can provide this information to you via the command-line.

% mvn dependency:tree

Here is (a part) of the output from one of the projects I’m working on:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SomeCompany :: Main Webapp
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree]
[INFO] com.somecompany:somecompany:war:1.0-SNAPSHOT
[INFO] +- com.somecompany:backend:jar:1.0-SNAPSHOT:compile
[INFO] |  +- mysql:mysql-connector-java:jar:5.0.4:runtime
[INFO] |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  +- commons-codec:commons-codec:jar:1.3:compile
[INFO] |  +- commons-dbcp:commons-dbcp:jar:1.2.1:compile
[INFO] |  |  \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  +- commons-httpclient:commons-httpclient:jar:3.0:compile
[INFO] |  |  \- junit:junit:jar:3.8.1:compile
[INFO] |  +- commons-lang:commons-lang:jar:2.3:compile
[INFO] |  +- commons-logging:commons-logging:jar:1.0.4:compile
[INFO] |  +- commons-pool:commons-pool:jar:1.3:compile
[INFO] |  +- dom4j:dom4j:jar:1.6:compile
[INFO] |  +- net.sf.ehcache:ehcache:jar:1.4.0:compile
[INFO] |  |  +- net.sf.jsr107cache:jsr107cache:jar:1.0:compile
[INFO] |  |  \- backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[INFO] |  +- org.hibernate:hibernate-annotations:jar:3.2.0.ga:compile
[INFO] |  |  +- org.hibernate:hibernate:jar:3.2.0.ga:compile
[INFO] |  |  |  +- javax.transaction:jta:jar:1.0.1B:compile
[INFO] |  |  |  +- asm:asm-attrs:jar:1.5.3:compile
[INFO] |  |  |  +- cglib:cglib:jar:2.1_3:compile
[INFO] |  |  |  \- asm:asm:jar:1.5.3:compile
[INFO] |  |  \- javax.persistence:persistence-api:jar:1.0:compile
[INFO] |  +- jdom:jdom:jar:1.0:compile
[INFO] |  +- ognl:ognl:jar:2.6.7:compile
[INFO] |  +- rome:rome:jar:0.9:compile
[INFO] |  +- org.springframework:spring:jar:1.2.7:compile
[INFO] |  +- net.sourceforge.stripes:stripes:jar:1.4.3:compile
[INFO] |  +- velocity:velocity:jar:1.5:compile
[INFO] |  |  \- oro:oro:jar:2.0.8:compile
[INFO] |  +- org.json:json:jar:20070829:compile
[INFO] |  +- org.htmlparser:htmlparser:jar:1.6:compile
[INFO] |  +- javax.mail:mail:jar:1.4:compile
[INFO] |  |  \- javax.activation:activation:jar:1.1:compile
[INFO] |  \- org.safehaus:jug:jar:2.0.0:compile
[INFO] +- javax.servlet:jstl:jar:1.1.2:compile
[INFO] +- taglibs:standard:jar:1.1.2:compile
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- com.oreilly.servlet:cos:jar:1.0:compile
[INFO] +- c3p0:c3p0:jar:0.9.1.2:compile
[INFO] +- jaxen:jaxen:jar:1.1-beta-7:compile
[INFO] |  +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] |  +- xerces:xercesImpl:jar:2.6.2:compile
[INFO] |  \- xom:xom:jar:1.0b3:compile
[INFO] |     +- com.ibm.icu:icu4j:jar:2.6.1:compile
[INFO] |     +- xalan:xalan:jar:2.6.0:compile
[INFO] |     \- org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7:compile
[INFO] +- javax.sql:jdbc-stdext:jar:2.0:compile
[INFO] +- org.apache.lucene:lucene-core:jar:1.9.1:compile
[INFO] +- quartz:quartz:jar:1.5.1:compile
[INFO] +- commons-collections:commons-collections:jar:3.2:compile
[INFO] +- org.apache.avalon.logkit:avalon-logkit:jar:2.2.1:compile
[INFO] +- jgroups:jgroups-all:jar:2.6.1:compile
[INFO] \- log4j:log4j:jar:1.2.11:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Wed Apr 30 16:40:42 PDT 2008
[INFO] Final Memory: 12M/508M
[INFO] ------------------------------------------------------------------------

Java 5 FOREACH Syntax

nelz9999 — Wed, 16 Apr 2008 21:35:50 +0000

For those that don’t currently use the new Java 5 "foreach" syntax, you are missing out.

I got to a point today where I wanted to verify that the construct is doing the intelligent thing, so I wrote the following unit test:

@Test
public void forEachLoop() {
for (String str : doHeavyWeigthMethod()) {
System.out.println(str);
}
}
private List doHeavyWeigthMethod() {
System.out.println("heavyMethod");
final List results = new ArrayList();
results.add("one");
results.add("two");
results.add("three");
return results;
}

I was psyched to see the output:

heavyMethod
one
two
three

Basically, this shows that the foreach construct only evaluates the collection once and caches the value to be used in each iteration.

However, the construct is not without some pitfalls. I would have expected the new construct to be programmed more defensively, but it is still susceptible to NullPointerException. Running the following throws the NPE:

@Test
public void forEachLoop() {
for (String str : doHeavyWeigthMethod()) {
System.out.println(str);
}
}
private List doHeavyWeigthMethod() {
return null;
}

So, unless you know you are in control of the method you are calling in the expression part of the "foreach" construct, you still need to defensively check for null. And, we all know how much I love that, right?

Heavyweight Syntax

nelz9999 — Fri, 11 Apr 2008 11:33:08 +0000

Method chaining seems like such a good idea. And Java supports it, always has. However, if you have been bitten in the butt too often by code you can’t (or don’t) control, you learn the value of defensive programming.

Whereas, I want to write code like this:

public String getDeepString(ComplexObjectA a) {
return a.getComplexObjectB().toString();
}

… I can’t. Or at least it’s not a good idea to write it like that. To protect myself, or classes that utilize my method, I have to write it like this:

public String getDeepString(ComplexObjectA a) {
String result = null;
if (a != null) {
ComplexObjectB b = a.getComplexObjectB();
if (b != null) {
result = b.toString();
}
}
return result;
}

Wash. Rinse. Repeat. Over and over and over, I’m checking for null. And, I’m getting kind of tired of it.

But wait, what light over yon hill breaks? Is it Groovy?!? Groovy provides a fantastic "?." construct, which can reduce the above noisy code to nearly what I was hoping for in my first example:

public String getDeepString(ComplexObjectA a) {
return a?.getComplexObjectB()?.toString();
}

I showed the "Unadulterated Java is so groovy" post to some of my coworkers, and the "?." construct is the single most talked about benefit of potentially adopting Groovy.

No, we haven’t adopted Groovy yet. We’ve got some work to do, including moving toward a Maven (2) build system. But from what I hear the Groovy plugins to Maven and IntelliJ make dropping in Groovy transparent and easy. We may become a Groovy shop yet!