Sunday, 21 February 2010

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.

No comments:

Post a Comment