You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by "BAZLEY, Sebastian" <Se...@london.sema.slb.com> on 2003/11/24 19:06:49 UTC
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.parser=<parser-class>
where <parser-class> is the name of the implementing class.
So long as the appropriate default is provided, the casual user would not
need to worry about it.
More demanding users could still change it as needed.
In the short-term, I suggest hard-coding the class names in HTTPSamplerFull,
but it might be useful to use a factory in future.
There should be a parser interface as well.
A suitable API should become clearer when the URL fetching code has been
moved out of the parser - suggestions?
S.
-----Original Message-----
From: peter lin [mailto:jmw00lfel@yahoo.com]
Sent: 24 November 2003 17:23
To: JMeter Developers List
Subject: 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 extend JMeter if
someone just wants to parse a couple of tables and do functional testing.
hopefully we'll get there slowly.
peter
Jordi Salvat i Alabart <js...@atg.com> wrote:
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 regexp (at
least as it is now) would not be able, for example, to avoid parsing
tags embeded in HTML comments or in JavaScript code. For example: the
IMG tag in
var img1=''
would be parsed just as if it were not in JavaScript code.
About performance vs. functional testing and the need for speed: I guess
you're right. If you want the images AND real speed, you'll be better
off creating the samplers for those images in the first place.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Parser refactoring; should Jmeter fetch more than images/appl
ets?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
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 <js...@atg.com> 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 the property to something like:
>>
>>jmeter.html.parser=
>
>
>
> Sounds like a good option.
>
>
>>In the short-term, I suggest hard-coding the class names in HTTPSamplerFull,
>>but it might be useful to use a factory in future.
>
>
> Or simply grabbing jmeter.html.parser and instantiating the class from
> the name?
>
>
>>There should be a parser interface as well.
>
>
> Agree.
>
>
>>A suitable API should become clearer when the URL fetching code has been
>>moved out of the parser - suggestions?
>
>
> My ParserRegexp already separates obtention from fetching. I used a
> LinkedHashSet to hold the list of URLs, but I'd rather favour the parser
> returning a Collection or even an Iterator.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Parser refactoring; should Jmeter fetch more than images/appl ets?
Posted by peter lin <jm...@yahoo.com>.
i like the idea of an iterator, since that is how we use it anyways :)
peter
Jordi Salvat i Alabart <js...@atg.com> 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 the property to something like:
>
> jmeter.html.parser=
Sounds like a good option.
> In the short-term, I suggest hard-coding the class names in HTTPSamplerFull,
> but it might be useful to use a factory in future.
Or simply grabbing jmeter.html.parser and instantiating the class from
the name?
> There should be a parser interface as well.
Agree.
> A suitable API should become clearer when the URL fetching code has been
> moved out of the parser - suggestions?
My ParserRegexp already separates obtention from fetching. I used a
LinkedHashSet to hold the list of URLs, but I'd rather favour the parser
returning a Collection or even an Iterator.
--
Salut,
Jordi.
---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
Re: Parser refactoring; should Jmeter fetch more than images/appl
ets?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
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=<parser-class>
Sounds like a good option.
> In the short-term, I suggest hard-coding the class names in HTTPSamplerFull,
> but it might be useful to use a factory in future.
Or simply grabbing jmeter.html.parser and instantiating the class from
the name?
> There should be a parser interface as well.
Agree.
> A suitable API should become clearer when the URL fetching code has been
> moved out of the parser - suggestions?
My ParserRegexp already separates obtention from fetching. I used a
LinkedHashSet to hold the list of URLs, but I'd rather favour the parser
returning a Collection or even an Iterator.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org