Web application integration testing made easy with mycila jetty testing plugin

It is time to do some advertising about a very cool way of doing integration testing of a web application (aka : a java WAR deployment and testing).

I am honored to present the mycila jetty testing plugin :D

Google please, give my navigation reader link back !

As Google operating system blog said, they moved some of the navigation menu links.

I instantly noticed that because I use it every day.

So please Google, give my navigation reader link back or make the navigation menu customizable.

EDIT (25/01/2011) : Google give it back, thanks.

dry-run svn update on command line

"svn merge –dry-run -r BASE:HEAD ."

maven groovy compiler plugin

    <build>
        <plugins>
            <plugin>
                <groupid>org.codehaus.gmaven</groupId>
                <artifactid>gmaven-plugin</artifactId>
                <version>1.3</version>
                <configuration>
                    <debug>true</debug>
                    <verbose>true</verbose>
                    <stacktrace>true</stacktrace>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generateStubs</goal>
                            <goal>compile</goal>
                            <goal>generateTestStubs</goal>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
    
    <dependencies>
        <dependency>
            <groupid>org.codehaus.gmaven.runtime</groupId>
            <artifactid>gmaven-runtime-1.7</artifactId>
            <version>1.3</version>
        </dependency>
    </dependencies>

Integration test coverage of WAR using cobertura

I've made a fork of codehaus cobertura-maven-plugin which enable the so long waited integration test coverage feature MCOBERTURA-86 until they commit something cool.

http://code.google.com/p/cobertura-it-maven-plugin/

Disable Jetty 7 URL rewriting sessionid param

With Jetty 7, the documentation (http://wiki.eclipse.org/Jetty/Howto/SessionIds) said to use this configuration, but it does not work :( (EDIT : I've updated it :D)

<context-param>
    <param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
    <param-value>none</param-value>
  </context-param>

So, I browse the source code and found the org.eclipse.jetty.server.SessionManager class which define the param name. The right configuration is this one :

<context-param>
    <param-name>org.eclipse.jetty.servlet.SessionIdPathParameterName</param-name>
    <param-value>none</param-value>
  </context-param>

Hope this help !

References :

http://groups.google.com/group/liftweb/browse_thread/thread/267bcda70fdde149/a32df23704edd5cf?lnk=raot

http://www.mail-archive.com/liftweb@googlegroups.com/msg11348.html

Dear Oracle, can we have our nice javadoc URLs back?

source : http://grep.codeconsult.ch/2010/07/21/dear-oracle-can-we-have-our-nice-javadoc-urls-back/

Dear Oracle,

A while ago you bought Sun, and IIRC promised to do good things for Java. Or at least indicated you would. Or something like that.

Now, a bad thing happened a few days ago. Not a bad bad bad thing, just a tiny annoying change in the cool URLs that Sun used to publish the JDK’s javadocs. Not annoying annoying annoying but not nice.

Even Google remembers: today if I search forIndexOutOfBoundsException on Google it returns the following URL:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

Which is a cool URL that shouldn’t change.

Now, requesting this URL today causes a redirect to:
http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

Which is also somewhat cool, but not as much. Factor 10 down in coolness. It makes me assume that you’re serving javadocs from a CD, and that CD’s identifier is E17476_01. That’s useful info if you’re the filesystem driver who’s reading the CD, but I doubt filesystem drivers are searching for javadocs on Google. Also, I’m not looking at downloading anything. Just browsing, okay?

Cool URLs shouldn’t change.

Can we have the old one back? Ok, maybe with java.oracle.com instead of java.sun.com – you bought them anyway. But please please please, let the poor CD filesystem driver alone!

Thanks.

source : http://grep.codeconsult.ch/2010/07/21/dear-oracle-can-we-have-our-nice-javadoc-urls-back/