Sorry, I should have been a little more clear. The problem isn't with Jetty per se. The problem is with TestContainer... the embedded Jetty launcher class I wrote. It just doesn't work, and I can't figure out how to fix it. When I first wrote TestContainer, I spent only enough time writing it to make it work minimally. Then something broke it. I do not have the time or energy to fix it.
Remember how we got to this point: we use Jetty for the webtests because parts of Jetty are included in the Selenium-RC jar. There's enough of Jetty there that it can set up a little server for proxying requests to Selenium-RC server. At the time, my reasoning was, "well we've already got part of Jetty already included with Selenium. How hard could it be to add in a few other JARs and write enough code to get it to run as an embedded web container? All we we need to do is write a launcher that configures support for executing JSPs, authentication, and JNDI objects. How hard could THAT be?" It turns out, pretty hard. TestContainer has to wire all that "other" stuff up programmatically -- precisely because we don't want or need to include the entire Jetty stack in the JSPWiki distro. It wasn't simple to write because there's very little documentation. Even worse, we had to use Jetty 5.1 because that's what Selenium uses. But Jetty is now at version 7, meaning the one we use in our test harness is damned ancient. By contrast, Winstone is much, much simpler. It doesn't need any other jars other than the JSP compiler & runtime, which we already ship. And it executes from the command line with just a few switches. For our purposes, it means we don't need to be writing custom code for embedding Jetty to run web tests. This is a good thing -- it's just one less peripheral thing that can break, and it mean we don't have to be chained to an ancient web container for testing. As for commons-logging, we "shouldn't" need to run it, I agree. At the moment the only way Winstone will run is if we include it. But perhaps someone who's more expert at logging can help me with this. Again -- to be clear. Jetty isn't the problem. It's with our TestContainer embedded servlet container launcher. Andrew. On 3/26/09, Janne Jalkanen <[email protected]> wrote: > > Yeah, I'm wondering about that too. If we can't run on Jetty, isn't > that a really big problem for our general servlet compatibility? > > We should not need commons-logging.jar. SLF4J should be able to take > care of it (since it contains commons-logging emulation). > > There are some limitations to including CDDL-licensed works, and > without looking at Winstone it's hard to say whether they apply or > not. http://www.apache.org/legal/3party.html > > /Janne > > On 26 Mar 2009, at 08:14, Harry Metske wrote: > >> Andrew, >> >> just for my understanding, what is wrong with Jetty that makes our >> webunit >> tests fail ? >> >> (and I agree that CDDL License should be ok, since we have more of >> them >> already) >> Harry >> >> >> 2009/3/26 Andrew Jaquith <[email protected]> >> >>> Janne and all -- >>> >>> The web unit tests are bothering me again. Specifically, the fact >>> that >>> we can't run them means we aren't getting good visibility to problems >>> like the container login issue mentioned on the -user list. So I want >>> to fix them. Again. >>> >>> I've gotten fed up with the bother of fixing the particular part of >>> our web unit tests that are broken -- the embedded Jetty container >>> that starts the test webapps. Fortunately I found an alternative >>> webapp container, Winstone, that does exactly what we need. It's >>> simple to run (can be done at the command line), and best of all it's >>> TINY. Total additional size is 320k, plus the commons-logging-api jar >>> (52k), which for some reason it needs. On the other side, I *think* >>> we >>> could get rid of the jetty-* jars in test (240k in total), which >>> means >>> the net addition is about 80k. >>> >>> I think this is worth doing. I'd like to back-port this to 2.8 so we >>> can fix the tests there, too. The best part is that this should >>> actually work, in the sense that it means we don't have to worry >>> about >>> maintaining TestContainer, which was only meant to be good enough to >>> barely function. And at the moment it doesn't. >>> >>> The only question is, is the CDDL ok? It looks like it probably is, >>> since we have a license notice for it in docs already. >>> >>> Andrew >>> > >
