Harry, thanks for looking into this. I'll take a look at the Selenium/Firefox issues (might not be able to do that until late in the week).
On Sat, Mar 28, 2009 at 11:29 AM, Harry Metske <[email protected]> wrote: > So, > > with the latest patches to the trunk (see ChangeLog and commits) I got > Selenium working but finally ended up with firefox talking to Jetty telling > me : > > HTTP ERROR: 404 > /selenium-server/tests/TestSuite.html Not Found > RequestURI=/selenium-server/tests/TestSuite.html > > Since this is a version 3 firefox, and wasn't sure if this Selenium works > with firefox 3, I stopped for now (I also could not get ff2 working > anymore). > > According to http://jira.openqa.org/browse/SIDE-171 it should work, I'll do > some more testing on this when I get some more time. > > regards, > Harry > > 2009/3/26 Andrew Jaquith <[email protected]> > >> That would be great! Please take a look at it, if you wouldn't mind. >> >> I don't actually know why it doesn't work. Part of the problem is that we >> don't wrap Throwables in WikiExceptions, so there is no way to know why >> WikiEngine won't start unless you bust out the debugger. >> >> Jetty is tied to Selenium -- we are using the embedded 5.1 classes included >> inside the Selemium server jar. Then I added the "plus" jar and a few >> others. >> >> Both 2.8.1 and the trunk are affected. >> >> Any insights you could provide would be appreciated. Thanks. >> >> Andrew >> >> >> On Mar 26, 2009, at 9:18, Siegfried Goeschl <[email protected]> >> wrote: >> >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> >>>> >
