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 Jordi Salvat i Alabart <js...@atg.com> on 2003/11/24 19:25:04 UTC
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=<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
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