DO NOT REPLY [Bug 22721] - HTTP Proxy captures Request Headers by default

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Parser refactoring; should Jmeter fetch more than images/appl ets?

OK. I'm doing that. I will also try to devise some easy-to-reproduce test that we can use for comparison. En/na peter lin ha escrit: i like the idea of an iterator, since that is how we use it anyways :) peter Jordi Salvat i Alabart <[EMAIL PROTECTED]> wrote: En/na BAZLEY, Sebastian ha esc

Re: Parser refactoring; should Jmeter fetch more than images/appl ets?

i like the idea of an iterator, since that is how we use it anyways :) peter Jordi Salvat i Alabart <[EMAIL PROTECTED]> wrote: En/na BAZLEY, Sebastian ha escrit: > Oops. The parser selection property I introduced does not extend well. You're right. I have no shame. > I propose changing t

Re: Parser refactoring; should Jmeter fetch more than images/appl ets?

En/na BAZLEY, Sebastian ha escrit: Oops. The parser selection property I introduced does not extend well. You're right. I have no shame. I propose changing the property to something like: jmeter.html.parser= Sounds like a good option. In the short-term, I suggest hard-coding the class nam

Re: ORO or java.util.regex?

En/na BAZLEY, Sebastian ha escrit: Forgot to add - does java.util.regex have the concept of "matches" as well as "contains"? Yes, it does. If not, "matches" will either have to be coded, or we could remove the functionality - "matches" is tricky, and I'm not sure how useful it is. S. -Origi

Re: ORO or java.util.regex?

Well... I've always advocated to maintain it, but it's long since JMeter doesn't build but on 1.4. -- Salut, Jordi. En/na BAZLEY, Sebastian ha escrit: I thought we were trying to maintain at least 1.3 compatibility - but I'm happy to go with requiring 1.4. S. -Original Message- From: Jor

RE: Parser refactoring; should Jmeter fetch more than images/appl ets?

Likewise, I favour supporting multiple parsers. Oops. The parser selection property I introduced does not extend well. I should really have used a multi-valued property to define the parser type, rather than using a boolean. I propose changing the property to something like: jmeter.html.pars

Re: ORO or java.util.regex?

Yes, it does. En/na BAZLEY, Sebastian ha escrit: Forgot to add - does java.util.regex have the concept of "matches" as well as "contains"? If not, "matches" will either have to be coded, or we could remove the functionality - "matches" is tricky, and I'm not sure how useful it is. S. -Origin

Re: Parser refactoring; should Jmeter fetch more than images/applets?

nothing like tackling a problem that appears simple, but ends up being challenging :) In that case, my personal preference is to support multiple. For heavy load testing with insane load, squeezing more performance out of JMeter is desirable to me. But I wouldn't require regexp guru-ness to e

RE: ORO or java.util.regex?

Forgot to add - does java.util.regex have the concept of "matches" as well as "contains"? If not, "matches" will either have to be coded, or we could remove the functionality - "matches" is tricky, and I'm not sure how useful it is. S. -Original Message- From: BAZLEY, Sebastian Sent: 24

RE: ORO or java.util.regex?

I thought we were trying to maintain at least 1.3 compatibility - but I'm happy to go with requiring 1.4. S. -Original Message- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 24 November 2003 16:50 To: JMeter Developers List Subject: ORO or java.util.regex? I've found java.

cvs commit: jakarta-jmeter/src/protocol/http/org/apache/jmeter/protocol/http/sampler ParseRegexp.java

jsalvata2003/11/24 08:52:51 Modified:src/protocol/http/org/apache/jmeter/protocol/http/sampler ParseRegexp.java Log: Use java.util.regex instead of ORO classes. Performance is similar, but some memory savings are easier and it's much simpler. Revision C

ORO or java.util.regex?

I've found java.util.regex to be much simpler and slightly better performing than the ORO classes for the kind of usage we need. Any arguments against generally replacing ORO with java.util.regex, now that we are JDK 1.4-dependent anyway? -- Salut, Jordi. --

Re: Parser refactoring; should Jmeter fetch more than images/applets?

En/na peter lin ha escrit: if we go with the regexp approach, can it be made such that it maintains heirarchy information? No, I guess it can't. Actually, this approach draws it's memory efficiency from not maintaining that information. That's what I meant when I said it is less accurate: the

Re: Parser refactoring; should Jmeter fetch more than images/applets?

good discussion. I get the feeling we need to unify the parse code. I plan on debugging the bug jordi found. unfortunately I won't have time until after the holidays. If I can fix the bug with HTMLParser, do others feel it would be a strong candidate? I have mixed feelings about having just

Re: Parser refactoring; should Jmeter fetch more than images/applets?

En/na BAZLEY, Sebastian ha escrit: As you are no doubt aware, I recently refactored the HTML Parsing code. - JTidy and HTMLParser now have their own separate class files. There's a third one since yesterday evening: ParseRegexp -- a regexp-based parser, which performs much better memory-wise tha

Parser refactoring; should Jmeter fetch more than images/applets?

As you are no doubt aware, I recently refactored the HTML Parsing code. - JTidy and HTMLParser now have their own separate class files. - The parsing method is selected at run-time by HTTPSamplerFull. During the refactoring process, I noticed that JTidy was not picking up some images, for example