Notes on making a simple auth app using Wicket

Follow the instructions here and add the junk to your pom. You'll need to add a repositories element in which to put you repository. I put mine near the end, after the build

Run mvn install

I prefer JUnit 4 to 3.8, so I removed the generated "variable" ref from my class path and added Eclipse's built-in library for JUnit 4.

To keep things consistent, I modified the pom to refer to JUnit 4.. Maybe I should have let the Eclipse build reference the Maven repo rather than Eclipse for its JUnit. Hmm.

Added "variable" ref for both swarm and wasp (sheesh - why two? This is so confusing) and changed my application to extend SwarmWebApplication as described in the swarm getting started doc.

Of course, Eclipse helped me out with the stubs of the overrides of the abstract methods, so on to filling them in.

So, starting with a bare-bones app, start adding security. Hmm. Not working.

OK, so start with the kitchen-sink security demo app and begin deleting unneeded code. Hard, because I don't have a project and have to rely on reconstructing one from the war.

Aaargh! Give up on swarm. The guy's dead anyway, so who's maintaining it?

So auth-roles is the next.

Generate a project using mvn. Modify the pom to include auth-roles:

<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-auth-roles</artifactId>
<version>1.4-rc4</version>
</dependency>

Then use mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true to make the eclipse project. Import into eclipse.

Copy gibblies from the "wicket-auth-roles-example" available on Sourceforge. (It's in maven too if you know how to get it. I don't.) It has a weird structure, not like the autogenerated one with the embedded Jelly, so that's why we have to copy/paste.

A couple little syntax errors: Stuff that's presumably changed in more recent releases. An overridden constructor needs to be deleted, since the thing it overrides no longer exists. Stuff like that.

And the source needs to be reformatted. What's with all this C#-like source formatting anyway? Sheesh, this is Java, guys.

Labels: java, macos

0 comments

Bootstrapping Java on Fedora

Every time I have to bootstrap a new box with Java, it's a learning experience. I sure wish it was easy. The hardest part this time 'round was finding Java. Sun sure goes to a lot of trouble to hide it.
Found this:

[How To Install JDK 6 / Java SE 6 (+ Tomcat) in Fedora Core 6 / Fedora 7 in 5 Minutes]

There is a secret directory where you can download JDKs and just install. The end.

Labels: fedora, java

0 comments

Wicket

So I started by using the QuickStart tool to generate the correct Maven incantation. (I'm already hating Maven) and following the instructions there in my Eclipse workspace. This generated a whole tree of stuff: my new project. The artifactId I specified ended up naming the root of the tree.

Next – still following the instructions – I went into the project and did this: mvn eclipse:eclipse -DdownloadSources=true

After that, into Eclipse and tell it to create a new Java project. I gave it the name I'd already chosen (the ArtifactId) and Eclipse noticed that there was a project there to import. Cool.

Unfortunately, it uses an eclipse "variable" called M2_REPO in the classpath, so this need to be resolved. I opened my Eclipse preferences and navigated to Java > Build Path > Classpath variables and set M2_REPO to point to $HOME/.m2/repository

But Eclipse still wasn't aware that it needs to copy the .html files to the output ("target") directory. That's because the generated .project explicitly includes only .java files in the source path. To remedy, open the project properties and go to the Source tab in Java Build Path. Add an inclusion pattern for "**/*.html" to the one already there for the .java files.

Great! A working wiket app. That wasn't too bad.

So what about Wicket Bench, the Eclipse plugin? Out of date. It points to its own internal Wicket distro, which is old. Nice idea otherwise, and TDD-friendly.

Next, I tried one of the apps included in the Wicket download. There's a pom.xml there, so maybe I can get to run as a standalone app? Too many missing pieces.

At this point I am miffed. What a mess! Every other thing I touch is out of date, but as a n00b, I have no way of knowing which is the new and which is the old.

So, my latest strategy is this: Use the archetype stuff from the QuickStart tool, and then copy needed pieces in from other parts of the distro – in my case, the auth & auth sample code. We'll see how that goes.

Labels: java, wicket

0 comments

Selenium-RC

My "Mastering Selenium" tutorial has been approved at Agile2008. I am very excited about that.

Meanwhile, in preparation, I have been putting Selenium-Grid through its paces at Industrial Logic. We are formulating a high level lingua franca to use in describing executable Storytests. This is a big deal. It was the promise of FIT, but for one reason or another (and theories abound!) Customers stayed away from FIT in droves.

Our old Selenium tests had been constructed using a wiki language and template processor. This provided a powerful toolset with which to construct Stroytests, but we ran into 3 major issues:

1. Selenium Core is slow
2. With the HTML Selenium tests, there is no guaranteed tear-down as there is in xUnit
3. Our toolset, while providing a fair bit of power and reasonable readability, did not come close to the expressiveness of a language like Python, Java, or Ruby in Selenium-RC.

So we went full out for Selenium-RC, using JUnit to drive the tests against a local Selenium-server.

To get the ball rolling, we grabbed the HTML from an old Selenium test by simply firing it up in Selenium Core and grabbing the code from the browser. It's a trivial matter to translate it into one of the Selenium-RC languages - we're using Java - with the Selenium IDE. Some deft text editing massages the Java file into shape so that it fits into it's place in the class hierarchy. More about the hierarchy later. We found reworking these legacy Stroytests to be an illuminating process. It meant bottom-up - starting with a very long list of Selenese commands, and doing extract method on clumps of code. The original source file with its template language was found to be lacking in many cases. The tests had grown over time and had not been refactored. We found some very interesting issues:

• Code that verified conditions that had absolutely nothing to do with the story at hand. These were presumably checks that had been copied/pasted from some other test where those checks were relevant.
• Some tests attempted to do too much and veered off on a tangent.
• Once we put in place some decent setup and (dependable!) tear-down, the test body was short and to the point.

So what does the class hierarchy look like?

The immediate superclass of each Selenium test class contains domain-specific helper methods. Its superclass is essentially a proxy for the Selenium server (or a hub, which is in turn a proxy for the runners.) For that class, we started with the SeleneseTestCase that is provided in the download, but decided that we didn't like it for a variety of reasons. In particular, we needed to do some magic so that a new Selenium session (and hence a new browser) is only launched if none already exists for the current thread. That's because we exploit the good ol' JUnit 3.x suite and test decorators to run allow for parallelization of tests. Sure, we could have used testng but its seemed a little haphazard to us and that business of generating an intermediate xml file just doesn't seem right.

The next chunk of learning relates to just what is needed to get tests to run in parallel so that they don't stomp all over each other.

Labels: java, xp

0 comments

TDE - test-driven exploration

So I was geeking out last night, as Mike would say. I was writing some code to fix some corruption in my calendar. It's in iCalendar format, so I found an ical4j framework on SourceForge and fired up Eclipse.

The first thing I did was to copy some snippets of sample code from the ical4j docs into a JUnit test and see what happens. I did this for 2 reasons: (a) the docs for FOSS are often wrong, and (ii) I needed to get all the config set up (e.g. to make a test calendar with events in it containing the properties I was interested in.)

As I worked, my "production code" kept evolving inside my test class. When I had successfully TDD'ed a step, I extracted the code into a real production class. I could move code around with Eclipse's refactoring tools and I had solid tests to save my butt.

Nothing startling in any of this. The interesting thing for me was that I was exploring ical4j. It was something of a spike - I didn't know ahead of time if the framework would be up to the job - yet each success immediately resulted in moving the code to the production classes.

So what do you think of this approach of evolving the code in the test and moving it as soon as it's green?

Redux: Keith Ray says: It's good. I think Kent Beck or someone called these "Learning Tests"when learning an API via TDD.

Labels: java, xp

0 comments