We could check for the presence of HTMLParser at run-time, and fall back to JTidy or Regex (or etc.) if not present.
Some users might not like the fallback behaviour, so if the parser property were changed to be a list of the acceptable parsers, in order of preference, we could support as much (or as little) fallback as required. We should log a warning message if the desired parser is not present (JMeter already logs an info message when a parser is initialised). S. >-----Original Message----- >From: peter lin [mailto:[EMAIL PROTECTED] >Sent: 05 February 2004 00:23 >To: JMeter Developers List >Subject: RE: Are we ready for a RC? > > > >right except that would mean users would have to go >download HTMLParser, and change the setting for JMeter >to make HTTPSampler use HTMLParser. > >otherwise it would still use JTidy. If you think we >realy shouldn't have it, then I'm fine with removing >it. Though it's already there and I feel it is a >benefit to users and it does improve the throughput of >JMeter as my benchmarks showed. > >peter lin > > >--- [EMAIL PROTECTED] wrote: >> That's why we'd use Ant to fetch them rather than >> put them in CVS. We can't distribute >> the jars, but to do a dist, JMeter should come fully >> compiled against these optional jars >> (and so I need them). Also, an Ant fetch target >> would be really nice for users - want all >> the optional abilities? Run the target to get them. >> Wouldn't work for the mail api's, but >> would be great for anything under non-compatible >> free licenses. >> >> -Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
