incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Winstone/CDDL
Date Thu, 26 Mar 2009 11:37:14 GMT
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.


On 3/26/09, Janne Jalkanen <> 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.
> /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 <>
>>> 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

View raw message