Hi Andrew, a few notes along the line
+) I recently wrote a plain vanilla Jetty integration (see http://turbine.apache.org/fulcrum/fulcrum-jetty/index.html) +) based on Fulcrum I'm also able to run Jetty within a JUnit test case (for webservice tests) So I think fixing the TestContainer is possible +) what is the actual problem with Jetty +) is Selenium tied to Jetty 5 in any way +) which JSPWiki version is affected 2.8.1 or trunk? If you don't mind I have a quick look at it ... BTW Andrew Jaquith wrote: > 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 >>>> >>>> >> > > >
