jakarta-watchdog-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Lubke <Ryan.Lu...@Sun.COM>
Subject Re: watchdog http, eol handling
Date Mon, 17 Jun 2002 16:19:59 GMT
On Fri, 2002-06-14 at 16:12, Christopher K. St. John wrote:
> Ryan Lubke wrote:
> >
> > > Long term, Watchdog probably needs to move to a proper
> > > HTTP client library.
> > 
> > Agreed.  I've been thinking about prototyping a replacement
> > using Latka from the Commons project (based of the HttpClient
> > library, also in the Commons project), but haven't had
> > a lot of time to work on this.
> >
> > Do you have any thoughts on this?  Have you taken a look
> > at Latka?  Do you have an alternate suggestion?
> > 
>  I took a quick look at Latka. It seems pretty close. Are
> you familiar with:
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons/latka/src/distribution/tests/watchdog/
>  What's the story? There doesn't seem to be much in the archives
> about how this happened, at least not indexed by google, other than:
>   http://archive.covalent.net/jakarta/watchdog-dev/2002/05/0004.xml

I recall this question about the organization.  I replied saying that
an improved way to organize the tests would be welcomed, but I never
heard any more.  I guess perhaps one of the Latka folks began some
work on this.  I'll contact them to see if I can get more details.

> > > Medium term the places where Watchdog servlets use
> > > println("data") need to be changed to use
> > > print(data+"\r\n") or print(data+"\n") or whatever, as
> > > long as they do it consistently, and the number of magic
> > > constants needs to be minimzied.
> > 
> > I will start going through the existing test code and make
> > changes as appropriate.
> > 
>  Just to be clear, when I whine and moan like that I'm
> also offering to help.

No clarification necessary.  There is still plenty of work
that could be done in this area.  I would welcome any help
you offered.

>  MinTC currently passes the full set of Watchdog tests,
> but is obviously non-compliant. As part of my internal
> testing, I was thinking about writing new Watchdog tests
> as I hit nonconformant behavior. I'm currently trying
> to figure out what the balance need to be between pushing
> conformance tests back out to watchdog, and how much 
> should go into internal testing ala Tomcat 4 tester.

The goal of Watchdog, which I'm sure you're aware of, is to ensure
a container's compliance with the spec.  To that end, when designing
tests, the keep the following goals in mind:

   - Anything that is unclear in the spec should not be in Watchdog.
   - Anything that is not mandated (optionally, should, could) by
     the spec should not be in Watchdog.  Of course, there are
     certain exceptions to this.
   - Anytime there is a 'must', or 'will' there should be a test.
   - Anything that could fall into the lines of implementation
     specific functionality, this should go into the internal
     Tomcat 4 tests.
   - Tests must be container neutral, but this can be a 
     difficult goal to reach if one has limited access to alternate

PS.  Have you updated your workspace lately?  I've made some changes to
how GTest sends multiple headers with the same name, but different
values (similar to how Apache would send them via JK) which exposes
a problem with HttpServletRequest.getHeaders(). 
> -- 
> Christopher St. John cks@distributopia.com
> DistribuTopia http://www.distributopia.com
> --
> To unsubscribe, e-mail:   <mailto:watchdog-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:watchdog-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:watchdog-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:watchdog-dev-help@jakarta.apache.org>

View raw message