jmx versioning

[Dimitris Balaouras <db...@gmail.com>]

Hi there,

When opening a jmx file that was created with a newer version of jmeter
(e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
in test plan" is thrown; not a detailed error message but fair enough.

I am wondering though, why is the version of jmeter that was used to create the jmx missing from the file itself? Wouldn't be handy to have the JMeter version in an attribute inside the jmeterTestPlan tag?

example: <jmeterTestPlan version="1.2" properties="2.2" jmeter:version="2.5.1">

Future versions of JMeter could use this attribute and external tools can parse jmx files without the need of heuristics. In my case, a proxy  would be able to delegate the execution of the jmx to the correct jMeter executable.



Thanks,
-Dimitris

Re: jmx versioning

[Shmuel Krakower <sh...@gmail.com>]

For the first point - I don't know why would someone try to run new script
with old jmeter. make no sense.

For the second point of having the jmeter version mentioned inside the
jmeter script - only for cases where newer versions don't support specific
samplers which were removed or default behavior was changed in such manner
that it might break the script. In such cases it would be nice to have the
originating jmeter version in hand.

I also don't see any problem or waste with saving this data.

Shmuel.

On Tue, Aug 7, 2012 at 5:15 PM, sebb <se...@gmail.com> wrote:

> On 7 August 2012 15:12, Shmuel Krakower <sh...@gmail.com> wrote:
> > Sebb, I guess you missed the point of Dimitris - to try and run a script
> > from jmeter 2.6 on jmeter2.5 executable.
>
> Why would one want to do that?
>
> > Dimitris - as sebb wrote currently only jmx version is reflected in the
> jmx
> > file, so you cannot directly know which version of jmeter was used to
> > create this script.
> >
> > I do find it useful too to have the jmeter version saved into the jmx
> file.
>
> Again, why?
>
> > Maybe you should open a bugzilla on this...
> >
> > On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com>
> wrote:
> >> > Hi there,
> >> >
> >> > When opening a jmx file that was created with a newer version of
> jmeter
> >> > (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
> >> > in test plan" is thrown; not a detailed error message but fair enough.
> >> >
> >> > I am wondering though, why is the version of jmeter that was used to
> >> create the jmx missing from the file itself? Wouldn't be handy to have
> the
> >> JMeter version in an attribute inside the jmeterTestPlan tag?
> >> >
> >> > example: <jmeterTestPlan version="1.2" properties="2.2"
> >> jmeter:version="2.5.1">
> >>
> >> The JMeter version does not directly affect the jmx version.
> >> The intention was to update the "version" field whenever changes were
> >> made, but some changes were unfortunately not reflected in the version
> >> attribute.
> >>
> >> > Future versions of JMeter could use this attribute and external tools
> >> can parse jmx files without the need of heuristics. In my case, a proxy
> >>  would be able to delegate the execution of the jmx to the correct
> jMeter
> >> executable.
> >> >
> >>
> >> JMeter should be able to run test plans from previous versions, unless
> >> the test plan is very old.
> >>
> >> If you have some examples where this does not apply, please raise a
> >> Bugzilla report.
> >>
> >> >
> >> >
> >> > Thanks,
> >> > -Dimitris
> >> >
> >>
>

Re: jmx versioning

[Dimitris Balaouras <db...@gmail.com>]

On 08/07/2012 06:11 PM, sebb wrote:
> On 7 August 2012 15:39, Dimitris Balaouras <db...@gmail.com> wrote:
>> On 08/07/2012 05:15 PM, sebb wrote:
>>> On 7 August 2012 15:12, Shmuel Krakower <sh...@gmail.com> wrote:
>>>> Sebb, I guess you missed the point of Dimitris - to try and run a script
>>>> from jmeter 2.6 on jmeter2.5 executable.
>>> Why would one want to do that?
>> Sebb, I wouldn't ever want to do this.  The use case goes like this:
>> users upload jmx scripts into a web app and a proxy application
>> delegates them to the correct jmeter executable for regular executions.
>> I tend to agree that using the latest version is always safe, but
>> sticking with one version provides some safety that all executions would
>> occur under the exact same context (wrt software at least). That said,
>> knowing the version of jM that was used to create a script would be handy.
>> Of course the users can explicitly define this, but automation is always
>> welcomed.
>>
>>>> Dimitris - as sebb wrote currently only jmx version is reflected in the jmx
>>>> file, so you cannot directly know which version of jmeter was used to
>>>> create this script.
>>>>
>>>> I do find it useful too to have the jmeter version saved into the jmx file.
>>> Again, why?
>> See above for a -hopefully- justified reason. Other than that, I'm
>> wondering if it would cause any harm.
> JMeter should just ignore the attribute when reading the file, but it
> might cause some issues for unit tests that check JMX files can be
> read and saved - at present the file size is checked, and that would
> change if the version strings were different lengths. Might have to
> make saving the attribute optional, at least for testing.
>
> Could potentially also affect 3rd party tools.

I see.

>> Surely, if it's too much work or breaks conventions, I wouldn't put any
>> effort on it.
> OK, then raise a Bugzilla enhancement request.

okay..I'll try that.

> It probably would not be too difficult to save the current JMeter
> version as a new attribute when writing a JMX file.
> Of course this will be overwritten if the file is ever updated in a
> different version of JMeter.

yes...makes perfect sense.

Thanks,
Dimi

>
>> - Dimi
>>
>>
>>>> Maybe you should open a bugzilla on this...
>>>>
>>>> On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> When opening a jmx file that was created with a newer version of jmeter
>>>>>> (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
>>>>>> in test plan" is thrown; not a detailed error message but fair enough.
>>>>>>
>>>>>> I am wondering though, why is the version of jmeter that was used to
>>>>> create the jmx missing from the file itself? Wouldn't be handy to have the
>>>>> JMeter version in an attribute inside the jmeterTestPlan tag?
>>>>>> example: <jmeterTestPlan version="1.2" properties="2.2"
>>>>> jmeter:version="2.5.1">
>>>>>
>>>>> The JMeter version does not directly affect the jmx version.
>>>>> The intention was to update the "version" field whenever changes were
>>>>> made, but some changes were unfortunately not reflected in the version
>>>>> attribute.
>>>>>
>>>>>> Future versions of JMeter could use this attribute and external tools
>>>>> can parse jmx files without the need of heuristics. In my case, a proxy
>>>>>  would be able to delegate the execution of the jmx to the correct jMeter
>>>>> executable.
>>>>> JMeter should be able to run test plans from previous versions, unless
>>>>> the test plan is very old.
>>>>>
>>>>> If you have some examples where this does not apply, please raise a
>>>>> Bugzilla report.
>>>>>
>>>>>> Thanks,
>>>>>> -Dimitris
>>>>>>


-- 
???????? ??????????
??. ???/??? & ???/??? ?/? - ??????????
*T* +306976990146
*F* +302410285612
*E* dbalaouras@gmail.com
Twitter <http://twitter.com/#%21/dbalaouras> | LinkedIn
<http://www.linkedin.com/in/dbalaouras> | G+
<https://plus.google.com/100211800323347120261/>

Re: jmx versioning

[sebb <se...@gmail.com>]

On 7 August 2012 15:39, Dimitris Balaouras <db...@gmail.com> wrote:
> On 08/07/2012 05:15 PM, sebb wrote:
>> On 7 August 2012 15:12, Shmuel Krakower <sh...@gmail.com> wrote:
>>> Sebb, I guess you missed the point of Dimitris - to try and run a script
>>> from jmeter 2.6 on jmeter2.5 executable.
>> Why would one want to do that?
>
> Sebb, I wouldn't ever want to do this.  The use case goes like this:
> users upload jmx scripts into a web app and a proxy application
> delegates them to the correct jmeter executable for regular executions.
> I tend to agree that using the latest version is always safe, but
> sticking with one version provides some safety that all executions would
> occur under the exact same context (wrt software at least). That said,
> knowing the version of jM that was used to create a script would be handy.
> Of course the users can explicitly define this, but automation is always
> welcomed.
>
>>
>>> Dimitris - as sebb wrote currently only jmx version is reflected in the jmx
>>> file, so you cannot directly know which version of jmeter was used to
>>> create this script.
>>>
>>> I do find it useful too to have the jmeter version saved into the jmx file.
>> Again, why?
>
> See above for a -hopefully- justified reason. Other than that, I'm
> wondering if it would cause any harm.

JMeter should just ignore the attribute when reading the file, but it
might cause some issues for unit tests that check JMX files can be
read and saved - at present the file size is checked, and that would
change if the version strings were different lengths. Might have to
make saving the attribute optional, at least for testing.

Could potentially also affect 3rd party tools.

> Surely, if it's too much work or breaks conventions, I wouldn't put any
> effort on it.

OK, then raise a Bugzilla enhancement request.

It probably would not be too difficult to save the current JMeter
version as a new attribute when writing a JMX file.
Of course this will be overwritten if the file is ever updated in a
different version of JMeter.

> - Dimi
>
>
>>
>>> Maybe you should open a bugzilla on this...
>>>
>>> On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
>>>>> Hi there,
>>>>>
>>>>> When opening a jmx file that was created with a newer version of jmeter
>>>>> (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
>>>>> in test plan" is thrown; not a detailed error message but fair enough.
>>>>>
>>>>> I am wondering though, why is the version of jmeter that was used to
>>>> create the jmx missing from the file itself? Wouldn't be handy to have the
>>>> JMeter version in an attribute inside the jmeterTestPlan tag?
>>>>> example: <jmeterTestPlan version="1.2" properties="2.2"
>>>> jmeter:version="2.5.1">
>>>>
>>>> The JMeter version does not directly affect the jmx version.
>>>> The intention was to update the "version" field whenever changes were
>>>> made, but some changes were unfortunately not reflected in the version
>>>> attribute.
>>>>
>>>>> Future versions of JMeter could use this attribute and external tools
>>>> can parse jmx files without the need of heuristics. In my case, a proxy
>>>>  would be able to delegate the execution of the jmx to the correct jMeter
>>>> executable.
>>>> JMeter should be able to run test plans from previous versions, unless
>>>> the test plan is very old.
>>>>
>>>> If you have some examples where this does not apply, please raise a
>>>> Bugzilla report.
>>>>
>>>>>
>>>>> Thanks,
>>>>> -Dimitris
>>>>>
>

Re: jmx versioning

[Dimitris Balaouras <db...@gmail.com>]

On 08/07/2012 05:15 PM, sebb wrote:
> On 7 August 2012 15:12, Shmuel Krakower <sh...@gmail.com> wrote:
>> Sebb, I guess you missed the point of Dimitris - to try and run a script
>> from jmeter 2.6 on jmeter2.5 executable.
> Why would one want to do that?

Sebb, I wouldn't ever want to do this.  The use case goes like this:
users upload jmx scripts into a web app and a proxy application
delegates them to the correct jmeter executable for regular executions.
I tend to agree that using the latest version is always safe, but
sticking with one version provides some safety that all executions would
occur under the exact same context (wrt software at least). That said,
knowing the version of jM that was used to create a script would be handy.
Of course the users can explicitly define this, but automation is always
welcomed.

>
>> Dimitris - as sebb wrote currently only jmx version is reflected in the jmx
>> file, so you cannot directly know which version of jmeter was used to
>> create this script.
>>
>> I do find it useful too to have the jmeter version saved into the jmx file.
> Again, why?

See above for a -hopefully- justified reason. Other than that, I'm
wondering if it would cause any harm.
Surely, if it's too much work or breaks conventions, I wouldn't put any
effort on it.

- Dimi


>
>> Maybe you should open a bugzilla on this...
>>
>> On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
>>>> Hi there,
>>>>
>>>> When opening a jmx file that was created with a newer version of jmeter
>>>> (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
>>>> in test plan" is thrown; not a detailed error message but fair enough.
>>>>
>>>> I am wondering though, why is the version of jmeter that was used to
>>> create the jmx missing from the file itself? Wouldn't be handy to have the
>>> JMeter version in an attribute inside the jmeterTestPlan tag?
>>>> example: <jmeterTestPlan version="1.2" properties="2.2"
>>> jmeter:version="2.5.1">
>>>
>>> The JMeter version does not directly affect the jmx version.
>>> The intention was to update the "version" field whenever changes were
>>> made, but some changes were unfortunately not reflected in the version
>>> attribute.
>>>
>>>> Future versions of JMeter could use this attribute and external tools
>>> can parse jmx files without the need of heuristics. In my case, a proxy
>>>  would be able to delegate the execution of the jmx to the correct jMeter
>>> executable.
>>> JMeter should be able to run test plans from previous versions, unless
>>> the test plan is very old.
>>>
>>> If you have some examples where this does not apply, please raise a
>>> Bugzilla report.
>>>
>>>>
>>>> Thanks,
>>>> -Dimitris
>>>>

Re: jmx versioning

[sebb <se...@gmail.com>]

On 7 August 2012 15:12, Shmuel Krakower <sh...@gmail.com> wrote:
> Sebb, I guess you missed the point of Dimitris - to try and run a script
> from jmeter 2.6 on jmeter2.5 executable.

Why would one want to do that?

> Dimitris - as sebb wrote currently only jmx version is reflected in the jmx
> file, so you cannot directly know which version of jmeter was used to
> create this script.
>
> I do find it useful too to have the jmeter version saved into the jmx file.

Again, why?

> Maybe you should open a bugzilla on this...
>
> On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:
>
>> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
>> > Hi there,
>> >
>> > When opening a jmx file that was created with a newer version of jmeter
>> > (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
>> > in test plan" is thrown; not a detailed error message but fair enough.
>> >
>> > I am wondering though, why is the version of jmeter that was used to
>> create the jmx missing from the file itself? Wouldn't be handy to have the
>> JMeter version in an attribute inside the jmeterTestPlan tag?
>> >
>> > example: <jmeterTestPlan version="1.2" properties="2.2"
>> jmeter:version="2.5.1">
>>
>> The JMeter version does not directly affect the jmx version.
>> The intention was to update the "version" field whenever changes were
>> made, but some changes were unfortunately not reflected in the version
>> attribute.
>>
>> > Future versions of JMeter could use this attribute and external tools
>> can parse jmx files without the need of heuristics. In my case, a proxy
>>  would be able to delegate the execution of the jmx to the correct jMeter
>> executable.
>> >
>>
>> JMeter should be able to run test plans from previous versions, unless
>> the test plan is very old.
>>
>> If you have some examples where this does not apply, please raise a
>> Bugzilla report.
>>
>> >
>> >
>> > Thanks,
>> > -Dimitris
>> >
>>

Re: jmx versioning

[Shmuel Krakower <sh...@gmail.com>]

Sebb, I guess you missed the point of Dimitris - to try and run a script
from jmeter 2.6 on jmeter2.5 executable.
Dimitris - as sebb wrote currently only jmx version is reflected in the jmx
file, so you cannot directly know which version of jmeter was used to
create this script.

I do find it useful too to have the jmeter version saved into the jmx file.
Maybe you should open a bugzilla on this...

On Tue, Aug 7, 2012 at 11:44 AM, sebb <se...@gmail.com> wrote:

> On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
> > Hi there,
> >
> > When opening a jmx file that was created with a newer version of jmeter
> > (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
> > in test plan" is thrown; not a detailed error message but fair enough.
> >
> > I am wondering though, why is the version of jmeter that was used to
> create the jmx missing from the file itself? Wouldn't be handy to have the
> JMeter version in an attribute inside the jmeterTestPlan tag?
> >
> > example: <jmeterTestPlan version="1.2" properties="2.2"
> jmeter:version="2.5.1">
>
> The JMeter version does not directly affect the jmx version.
> The intention was to update the "version" field whenever changes were
> made, but some changes were unfortunately not reflected in the version
> attribute.
>
> > Future versions of JMeter could use this attribute and external tools
> can parse jmx files without the need of heuristics. In my case, a proxy
>  would be able to delegate the execution of the jmx to the correct jMeter
> executable.
> >
>
> JMeter should be able to run test plans from previous versions, unless
> the test plan is very old.
>
> If you have some examples where this does not apply, please raise a
> Bugzilla report.
>
> >
> >
> > Thanks,
> > -Dimitris
> >
>

Re: jmx versioning

[sebb <se...@gmail.com>]

On 7 August 2012 09:20, Dimitris Balaouras <db...@gmail.com> wrote:
> Hi there,
>
> When opening a jmx file that was created with a newer version of jmeter
> (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error
> in test plan" is thrown; not a detailed error message but fair enough.
>
> I am wondering though, why is the version of jmeter that was used to create the jmx missing from the file itself? Wouldn't be handy to have the JMeter version in an attribute inside the jmeterTestPlan tag?
>
> example: <jmeterTestPlan version="1.2" properties="2.2" jmeter:version="2.5.1">

The JMeter version does not directly affect the jmx version.
The intention was to update the "version" field whenever changes were
made, but some changes were unfortunately not reflected in the version
attribute.

> Future versions of JMeter could use this attribute and external tools can parse jmx files without the need of heuristics. In my case, a proxy  would be able to delegate the execution of the jmx to the correct jMeter executable.
>

JMeter should be able to run test plans from previous versions, unless
the test plan is very old.

If you have some examples where this does not apply, please raise a
Bugzilla report.

>
>
> Thanks,
> -Dimitris
>