Look below

One of my favourite HTTP-related protocols is Hessian. It's elegant, binary, free and the client lib is small. After overcoming some issues OpenJDK was having with classloading, I was stuck with one particularly strange problem:

Caused by: com.caucho.hessian.io.HessianProtocolException: '
' is an unknown code

Debugging an applet is a nasty enterprise. There's no real way to hook into the instance running inside the browser, logging is tricky and OpenJDK still doesn't come around with a decent console, so I've got to work with starting Firefox from the console (where I got the stack trace from).

So what does the exception mean? Hessian might be a binary protocol, but still goes through HTTP. So pulling out a packet sniffer and having a look at the response, it becomes clear what happened: The response is not a binary stream from the server side, but looks rather like the index page. Obviously, the server didn't recognise the session ID and responded with a login. And the first character of that page? A line feed. That would be the one from the exception...

Under Control

After all this work, it was about time to set up proper version control. Central VCS are out, it's all about DVCS these days. So there are the big two, Mercurial and Git. This comprehensive comparison here aligns Git with McGyver, which makes it instantly interesting for me as a die-hard fan. Yet, it's not the 80s and I'm not in highschool anymore, having unlimited time to play around with things. So I go for James Bond, aka Mercurial. The hosting choice for that is BitBucket - nice enough, it's free for my use. Setting up an account is painless.

Ok, now what... using Eclipse, there should be a plugin for that. I've heared rumors that the tool support for Mercurial is not as good as for Subversion. Now the tool support for Subversion, at least in Eclipse, is... abysmal, broken, fubar. So it can only get better, can't it?
At least this time, there's only one plugin around. And after convincing it that I don't want a commercial tools suite and Windows DLLs installed (no, thank you, I'm running Linux here, put these where the sun does not shine), things look not so bad.

So now I've got some eclipse projects, a shiny new account at BitBucket, a repository with a URL, so let's go and import stuff. But first, I'm greeted with an error message when starting Eclipse. Apparently, I still need the Mercurial binaries to get the whole shebang to work. I dawns on me what these Windows DLLs were for...

Ha, I use Linux, I don't need fancy automatic install. Open terminal, run apt, install Mercurial, done. I bet with Windows I'd have to reboot now. Take that, monopolist! And behold, Eclipse doesn't complain anymore as well. All good.

Well, nearly all. How am I going to get the projects into BitBucket? Apparently, I have to commit against a local repository first. Well, DVCS, kind of makes sense. After twiddling apart stuff in source and target folders (come on, Eclipse knows what's what, why can't the plugin?), I successfully commit.

Now it's still not in the BitBucket repo. Push is next on the list. But wait, I don't want my sources directly in the repo, project should be the top level. That didn't work... there's no way to delete things from the repo, or at least I haven't found any. So I just kill off the repo itself and start over.

Next try, I clone the repo to a folder in my workspace. Now I'm just moving the projects into that folder, and I can commit... er, push properly. That did the trick, I've got a neat list of my projects in BitBucket now.

Firefox Madness

Normally I rant about Internet Explorer. Don't even get me started on 6. 7 is bad enough. 8 is close to being basically usable. No I didn't just say that, did I? It's not. It's a nightmare.

But this is not about IE, it's about how everyone's darling Firefox just kept me dazzled for the best part of an hour on a trivial problem.

Using Stripes, there are some amazingly useful JSP taglibs shipping with it. One of my favourites is options-enumeration. This little beauty populates a combo box with the values from an enum. Plus, Stripes converts it back to enum when the action is called. Hibernate can persist it. How cool is that - one enum in a domain object and it works straight away.

Now one thing I was struggling with for a while was how to select the value from the pre-populated action. One option should be selected, according to whatever value the field of my domain object currently has.

Now by all means, that didn't work. Stupid dropdown kept on showing me "female" gender. I refreshed numerous times. I checked the database if the value was correct. I checked the source code of the options-enumeration tag. Don't you have that as well, when you're looking for the most complicated solution first, confident that it can't be a simple problem you're facing?

In the end, it turned out that some good soul made firefox keep form values on refresh. Guess what... CTRL-Refresh solved it. PEBKAC.

Switching to JPA2

I've been delaying the switch over to JPA 2 for a while - things worked fine, I'm using Hibernate anyway directly for most things and the new features of JPA 2 were not that useful for me.

Till I came around to set a custom user type, and found that with Hibernate 3.5, you can annotate the default class for it, so I could omit tagging every field that uses the custom type. Neat! So I can have a user type pojo, a user type implementation and annotate like this:

@TypeDef(
name=SomepojoUserType.TYPE,
typeClass=SomepojoUserType.class,
defaultForType=Somepojo.class
)

That requires Hibernate 3.5 though, so I did that - yet, 3.5 required JPA2, so I thought what the hell, here we go, time to give it a shot.

As expected, after updating, all my unit tests fail. What I see is this:

org.hibernate.HibernateException: increment size cannot be less than 1
at org.hibernate.id.enhanced.OptimizerFactory$LegacyHiLoAlgorithmOptimizer.(OptimizerFactory.java:336)

Quick search didn't produce something useful, so I went and checked the source code. Seems that they switched from a simple sequence generator to a hilo generator as default, and somewhere I miss the property "max_lo", which seems to be "0". Another quick search is equally inconclusive, there seems to be no way to configure that.

After half a day of searching and trying around, I finally figure out that the problem is in the SequenceGenerator annotation I'm using:

@SequenceGenerator(name="seq", sequenceName="seq_name", allocationSize=1)

Now I did it that way to avoid having holes in my pks... why waste perfectly good numbers by jumping ahead? I kept a performance test for later in the queue, but figured that it wouldn't become a problem for quite a while.

Now the hi/lo generator that Hibernate introduced as the new default seems to be taking the allocation size as base for the max_lo property computation, like max_lo = allocationSize - 1. Which results in "0", which blows it up. Turning that number up brought things back to working state.

That's it for now, let's see what other surprises JPA2 / Hibernate have in store for me.

The Double Webapps

I've been having some fun today tracing back a ClassNotFoundException. Original problem was that for some reason, the spring context didn't come up when launching Jetty, but failing on SLF4J. Which is strange, since I dropped them in Jetty's lib directory. One thing I did though was configuring the webAppContext to ParentLoaderPriortiy = true, which lets the server libs have precedence over the webapp libs (like JBoss would behave, for example).

So why couldn't they be found? After a while, I recognized that the application context got started twice. First one worked, second one broke. Huh? After finding nothing useful on the web on that, I started reducing web.xml and spring's configuration, but even when totally stripped, this still happened. It happened in Eclipse/WTP as well as when starting outside eclipse. Hm.

Finally, found the solution when examining the deployers in Jetty's config file. Obviously, by default there are two deployers active, a webAppDeployer and a contextDeployer. The contextDeployer takes the configuration from /contexts and deploys them. The webAppDeployer takes whatever WAR it finds in /webapps and deploys it.

Now when these two use the same context, Jetty seems to be smart enough to figure out not to deploy them twice. But I changed the context path in my configuration, since I never got around why to have a webapp under /webappname if there's only one all over my server. So I set the contextPath to "/", effectively making that single webapp the root context.

And then came the webAppDeployer, picked up the war, and started deploying it. Since ParentLoaderPriortiy defaults to false, and wasn't obviously configured for the webAppDeployer (how in any case?), it only looked inside the WAR, didn't find SLF4J, and blew up. Doh.

Now why did I drop SLF4J in Jetty's lib anyway? I want it for both Jetty AND my webapp, and SLF4J can't be having with itself twice on the classpath.

Log that!

I've just wasted a whole afternoon trying to make Jetty 7 log. Can you believe that? As mentioned, I went for the hightide compilation, as it promised to be a "full application server". AFAIK Jetty uses slf4j, which suits me fine, since I'm using logback, which is a native slf4j implementation. Now Jetty has a file named jetty-logging.xml, which obviously configures that. I won't go into details, but there is ZERO documentation on that on the web, I checked the source code, tried setting system properties as mentioned there, but nope, all I can get is INFO logging on STDOUT. No way to make that thing log anything else. I'm sure there is, but seriously guys, if there's no way for the average user to figure out how, even with your frickin' source code, that's one for the drain.

So what the hell, f*** Jetty 7, going back to 6. Somehow I have the feeling whenever Eclipse is invloved these days things turn into a huge pile of crap. So here's my setup for easy web development with Jetty 6 and Eclipse.

1. Get the Jetty WTP launcher (yes, there is one for Jetty 6. Jetty 7 is an Eclipse project, but not integratable with Eclipse).

2. Set up a Jetty runtime, and - this is important - switch off the autodeployer. You do NOT want the retarded WTP build a WAR with an ant script every time you change a JSP, and redeploy your web app, killing your session.

3. That's it basically for eclipse, the rest we do inside Jetty. Throw away everything under /contexts and /webapps, the test stuff there has lots of security leaks and no one needs it anyway.

4. If you want to use nice logging with logback, stuff slf4j, logback and the redirector jars for jcl etc. in /log. Throw away jsp-2.0, since it ships with some old libs that we don't need and that'd disturb the classpath. No idea if they're actually getting pulled, but better to be sure.

5. Now put logback.xml into /resources, and that's that for logging. Ideally you want to log to the console, as the Eclipse plugin for logback is crappy and hellishly slow.

6. Now here comes the nice one: go to your webapps folder and symlink to the webroot of your Eclipse war project. Call it "whatever.war" for nicety. If you can't symlink, go and get an Operating System.

7. Change your Eclipse build path to put compiled classes and resources into WEB-INF/classes. We don't want WTP to mess with our deployment, so we don't need to put stuff where it expects it.

Done! Now you can change most things, JSPs and Java code (as long as you're not messing with the method structure). Even with Spring, Hibernate and whatnot, the whole shebang starts in under 10 sec. Log in to your webapp, change your JSP and reload, just as you'd do with PHP or whatnot. Debugging works as well, of course.

Now the only question I have is, why the hell do I have to come up with that crap myself? Why is a new-millenium-second-decade-IDE not able to do that for me? One day I'll go and try out Netbeans with Glassfish, to see if they do things differently over there.

Jettison

I'm back! Been busy the past days, not able to work on my favourite stuff. But now, here I am again. Well, want to take the opportunity to thank the creator of my lovely avatar rock tux. Got it from http://tux.crystalxp.net, creative commons license. Thanks a lot guys! You rock.

Back on topic. I'm still trying to get Jetty 7 to run, after things failed with Eclipse. Switched back to my old solution, which looks like this.
What you absolutely want to have is hot deployment. Now how to achieve that if you're not actually starting your app server from within Eclipse? The neatest way I've found so far is to go to Jetty's webapps directory and create a symlink to your workspace web folder. Call the symlink foo.war for the looks, and done you are. What, you can't symlink, you're on Windows? Wrong blog mate, go get yourself an operating system :)

Finally, hot deployment, no more restarts. At least that's how it used to work, bracing myself for some surprises here too, you never know.

But first, Spring is spitting in my soup again. I got Spring Security on, quite excited about the shiny new configuration, waaay neater than stuff in the bad old Acegi days. But it doesn't start, and I get "Unable to locate Spring NamespaceHandler for XML schema namespace". Huh? Why not? Checking the xml, it's there. Jar is in lib.

Now I don't even try and run after that anymore, straight to google. And bingo, a gazillion of people are having the very same problem. Why is that? because the smart people at Spring Security found it a good idea to pack the namespace handler into an own jar. So shifting spring-security-core.jar and spring-security-web.jar over to your lib doesn't do anything, you need spring-security-config.jar as well.

So in order to use Spring Security with Spring, you need spring-security-config. I don't even rant about this anymore, I'm sooo close to just copying all jars over and done with it. But hell, I'd like a clean classpath if I'm given the opportunity.