You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2016/08/12 11:36:20 UTC
Re: JMeter JMX file format
Note that changing the JMX file format has major implications for
upwards compatibility.
That's not to say it cannot be done, but the additional work must be
considered before deciding to make a change.
On 28 July 2016 at 03:10, 易, <sc...@gmail.com> wrote:
> Thanks a lot. I will check with these two projects. Please consider add
> this feature in your next.... release.
>
> 2016-07-28 6:18 GMT+08:00 Ra Ge <fo...@gmail.com>:
>
>> Philippe, understood! The readable-test-file feature is a "nice to have"
>> rather than a "must have". I just wanted to sort of vote +1 for the
>> feature.
>>
>> RaGe
>>
>> On Wed, Jul 27, 2016, 8:31 AM Philippe Mouawad <philippe.mouawad@gmail.com
>> >
>> wrote:
>>
>> > Hi Ra Ge,
>> > I agree it can be useful but it's a matter of priority and resources on
>> the
>> > project.
>> >
>> > Did you see the dev mailing list on roadmap for 2015 ?
>> >
>> > You can open a thread for other proposals and of course patches, ideas
>> are
>> > welcome.
>> >
>> > Regards
>> >
>> > On Wednesday, July 27, 2016, Ra Ge <fo...@gmail.com> wrote:
>> >
>> > > I think there is certainly value in making the test file more human
>> > > readable. A lot of real world use cases I've seen treats the jmx file
>> as
>> > > code. It is checked into git/svn very often - where it gets displayed
>> as
>> > > text/XML but isn't easy to read/parse.
>> > >
>> > > There are a few different attempts including Ruby-jmeter and
>> blazemeter's
>> > > Taurus that are basically DSL wrappers trying to address this need.
>> > >
>> > > I get that the IDE is still the primary way to create/edit a test, but
>> > > bring able to quickly change something in a text editor is valuable.
>> > >
>> > > On Wed, Jul 27, 2016, 5:30 AM Philippe Mouawad <
>> > philippe.mouawad@gmail.com
>> > > <javascript:;>>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > > In Jmeter, you're never supposed to manipulate xml.
>> > > > You use gui (which is a full fledge IDE for plan creation) to modify
>> > the
>> > > > test plan and pass parameters using properties.
>> > > >
>> > > > But If you need a dsl, look at ruby-jmeter.
>> > > > For now DSL for JMeter is not prioritary in the roadmap unless users
>> > > think
>> > > > it should.
>> > > >
>> > > > Regards
>> > > >
>> > > > On Wednesday, July 27, 2016, 易, <sc.yiwei@gmail.com <javascript:;>>
>> > > wrote:
>> > > >
>> > > > > Do you have any plan to change the JMX file to any other language
>> > like
>> > > > > scala? My working environment is linux, it is very hard for me to
>> > > change
>> > > > > the xml file if I need to modify the parameters.
>> > > > >
>> > > > > Thanks a lot.
>> > > > >
>> > > > > --
>> > > > > Best Regards
>> > > > >
>> > > > > Wei
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cordialement.
>> > > > Philippe Mouawad.
>> > > >
>> > >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>
>
>
> --
> Best Regards
>
> Wei
Re: JMeter JMX file format
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb:
> Of course: that's what serialisation is designed to do.
> It is however much more portable and readable than Java serialisation.
>
> > No wonder it's such a horrible mess.
>
> It works perfectly well for the purpose for which it was designed.
> Calling it a horrible mess does not help.
>
> [Human languages are a 'horrible mess' if considered from the
> perspective of automatically parsing them.]
>
+1
Vladimir
RE: JMeter JMX file format
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, August 12, 2016 4:01 PM
> To: dev@jmeter.apache.org
> Subject: Re: JMeter JMX file format
>
> On 12 August 2016 at 20:33, Epp, Jeremiah W (Contractor) <je...@cas.org>
> wrote:
>> Though it's true that it NEEDS to be changed when the format changes or
>> it's somewhat meaningless. (For example it probably should have changed
>> some time between 2.8 and 2.13 because I'm pretty sure we found a break
>> in there.)
>
> Is there a bug report?
>
> AFAIK a JMX created in 2.8 will still run in 2.13 unless it uses a test
> element that has been retired.
Other way around. JMX created in 2.13 opened in 2.8 but blew up at runtime
somehow. I don't remember the details beyond being peeved at Ubuntu RelEng
for packaging a prehistoric JMeter.
I'm not sure what the bug report for that would even be?
>> Oh god, it really does work exactly like I thought it did. It is quite
>> literally implementation defined.
>
> Of course: that's what serialisation is designed to do. It is however
> much more portable and readable than Java serialisation.
Doesn't it strike you as at least a little bit of a bad idea to use an
undocumented serialisation of a complex recursive data structure as the
"human readable" format, though?
We've definitely found it a huge pain in the butt to work with. :/
>> No wonder it's such a horrible mess.
>
> It works perfectly well for the purpose for which it was designed.
> Calling it a horrible mess does not help.
I went into a little more detail on this topic in the DSL discussion thread.
In brief: the structure of a JMX document _partially_ lacks correspondence
to the structure of the test plan it represents, confounding correct and
safe manipulation. That's a bad thing.
> [Human languages are a 'horrible mess' if considered from the perspective
> of automatically parsing them.]
Haha, this is very true, if a non sequitur.
>> Interesting. Doc link?
>
> https://svn.apache.org/repos/asf/jmeter/trunk/bin/saveservice.properties
>
Thanks. Not what I expected, but enlightening in its own way.
>> What? I think implementing a DSL sort of implies there will be an
>> interpreter for it...
>
> Well yes, but if JMeter also continues to support reading and writing the
> current JMX format how can one have a clean break?
JMX import and export is legacy code. It works. It's content. Leave it
alone. DSL import and export can exist concurrently-- philosophically, it's
no different from how JTL supports CSV and XML.
Users can save to either format unless a test plan uses new features (such
as those mentioned in the DSL thread) that exceed the semantic capabilities
of the JMX format. In that case, error if users attempt to export JMX with
a notification that they have to use the new format (and why).
All right, I'm out. Have a good weekend!
Cheers,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Re: JMeter JMX file format
Posted by sebb <se...@gmail.com>.
On 12 August 2016 at 20:33, Epp, Jeremiah W (Contractor) <je...@cas.org> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Friday, August 12, 2016 1:02 PM
>> To: dev@jmeter.apache.org
>> Subject: Re: JMeter JMX file format
>>
>>On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <je...@cas.org>
>>wrote:
>>>
>>> Part of the problem there is JMX isn't versioned.
>>
>> There *is* some versioning info; it's perhaps not changed as frequently as
>> it should be. But any changes are upwards compatible.
>
> Okay, egg on my face. Somehow I never actually noticed the version="1.2"
> and properties="1.8" attributes on the <jmeterTestPlan>.
>
> Though it's true that it NEEDS to be changed when the format changes or it's
> somewhat meaningless. (For example it probably should have changed some time
> between 2.8 and 2.13 because I'm pretty sure we found a break in there.)
Is there a bug report?
AFAIK a JMX created in 2.8 will still run in 2.13 unless it uses a
test element that has been retired.
>> However JMeter uses XStream to serialise the classes that form the nodes,
>> so the format is defined by that.
>
> Oh god, it really does work exactly like I thought it did. It is quite
> literally implementation defined.
Of course: that's what serialisation is designed to do.
It is however much more portable and readable than Java serialisation.
> No wonder it's such a horrible mess.
It works perfectly well for the purpose for which it was designed.
Calling it a horrible mess does not help.
[Human languages are a 'horrible mess' if considered from the
perspective of automatically parsing them.]
>> config files to define shorthand aliases to reduce the file size.
>
> Interesting. Doc link?
https://svn.apache.org/repos/asf/jmeter/trunk/bin/saveservice.properties
>> Otherwise of course the source code is available.
>
> Source code is not documentation.
>
> Especially _that_ code. I actually _tried_ to figure out what the hell was
> happening in SaveService at a few points and it's not easy reading.
You need to understand XStream as well.
>>> In my mind, this is the major motivation for a test plan DSL: retain
>>> support for the "legacy" JMX as much as possible (read and write), but
>>> otherwise have a clean break that lets the project move forward sanely.
>>
>> I'm not sure how you can do that unless the DSL generates JMX.
>
> What? I think implementing a DSL sort of implies there will be an
> interpreter for it...
Well yes, but if JMeter also continues to support reading and writing
the current JMX format how can one have a clean break?
> Cheers,
> Wyatt
>
> Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
>
RE: JMeter JMX file format
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, August 12, 2016 1:02 PM
> To: dev@jmeter.apache.org
> Subject: Re: JMeter JMX file format
>
>On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <je...@cas.org>
>wrote:
>>
>> Part of the problem there is JMX isn't versioned.
>
> There *is* some versioning info; it's perhaps not changed as frequently as
> it should be. But any changes are upwards compatible.
Okay, egg on my face. Somehow I never actually noticed the version="1.2"
and properties="1.8" attributes on the <jmeterTestPlan>.
Though it's true that it NEEDS to be changed when the format changes or it's
somewhat meaningless. (For example it probably should have changed some time
between 2.8 and 2.13 because I'm pretty sure we found a break in there.)
> However JMeter uses XStream to serialise the classes that form the nodes,
> so the format is defined by that.
Oh god, it really does work exactly like I thought it did. It is quite
literally implementation defined. No wonder it's such a horrible mess.
> config files to define shorthand aliases to reduce the file size.
Interesting. Doc link?
> Otherwise of course the source code is available.
Source code is not documentation.
Especially _that_ code. I actually _tried_ to figure out what the hell was
happening in SaveService at a few points and it's not easy reading.
>> In my mind, this is the major motivation for a test plan DSL: retain
>> support for the "legacy" JMX as much as possible (read and write), but
>> otherwise have a clean break that lets the project move forward sanely.
>
> I'm not sure how you can do that unless the DSL generates JMX.
What? I think implementing a DSL sort of implies there will be an
interpreter for it...
Cheers,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Re: JMeter JMX file format
Posted by Philippe Mouawad <ph...@gmail.com>.
On Fri, Aug 12, 2016 at 7:01 PM, sebb <se...@gmail.com> wrote:
> On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <je...@cas.org>
> wrote:
> >> -----Original Message-----
> >> From: sebb [mailto:sebbaz@gmail.com]
> >> Sent: Friday, August 12, 2016 7:36 AM
> >> To: dev@jmeter.apache.org
> >> Subject: Re: JMeter JMX file format
> >>
> >> Note that changing the JMX file format has major implications for
> >> upwards compatibility.
> >
> > Part of the problem there is JMX isn't versioned.
>
> There *is* some versioning info; it's perhaps not changed as
> frequently as it should be.
>
properties="2.9"
jmeter="3.0"
In JMX.
Maybe we should also upgrade them when we:
- upgrade xstream
We do it when we add a component.
> But any changes are upwards compatible.
>
> > Or really specified at all. It's a de facto format that arises from the
> [voodoo] serialisation of the test plan's root ListedHashTree of
> JMeterTreeNodes. (Please, DO correct me if I'm wrong; even a bad spec
> would have been useful months ago.)
>
> There is no spec as such.
> However JMeter uses XStream to serialise the classes that form the
> nodes, so the format is defined by that.
> JMeter uses config files to define shorthand aliases to reduce the file
> size.
> Otherwise of course the source code is available.
>
I definitely think we should provide a public API for creating the test
plan.
This would ease for us the management of changes and their impact and I
think it would be useful to users and 3rd party provider who generate XML.
> >> That's not to say it cannot be done, but the additional work must be
> >> considered before deciding to make a change.
> >
> > In my mind, this is the major motivation for a test plan DSL: retain
> support for the "legacy" JMX as much as possible (read and write), but
> otherwise have a clean break that lets the project move forward sanely.
>
> I'm not sure how you can do that unless the DSL generates JMX.
>
>
> > Regards,
> > Wyatt
> >
> >
> > Confidentiality Notice: This electronic message transmission, including
> any attachment(s), may contain confidential, proprietary, or privileged
> information from Chemical Abstracts Service ("CAS"), a division of the
> American Chemical Society ("ACS"). If you have received this transmission
> in error, be advised that any disclosure, copying, distribution, or use of
> the contents of this information is strictly prohibited. Please destroy all
> copies of the message and contact the sender immediately by either replying
> to this message or calling 614-447-3600.
> >
>
--
Cordialement.
Philippe Mouawad.
Re: JMeter JMX file format
Posted by sebb <se...@gmail.com>.
On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <je...@cas.org> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Friday, August 12, 2016 7:36 AM
>> To: dev@jmeter.apache.org
>> Subject: Re: JMeter JMX file format
>>
>> Note that changing the JMX file format has major implications for
>> upwards compatibility.
>
> Part of the problem there is JMX isn't versioned.
There *is* some versioning info; it's perhaps not changed as
frequently as it should be.
But any changes are upwards compatible.
> Or really specified at all. It's a de facto format that arises from the [voodoo] serialisation of the test plan's root ListedHashTree of JMeterTreeNodes. (Please, DO correct me if I'm wrong; even a bad spec would have been useful months ago.)
There is no spec as such.
However JMeter uses XStream to serialise the classes that form the
nodes, so the format is defined by that.
JMeter uses config files to define shorthand aliases to reduce the file size.
Otherwise of course the source code is available.
>> That's not to say it cannot be done, but the additional work must be
>> considered before deciding to make a change.
>
> In my mind, this is the major motivation for a test plan DSL: retain support for the "legacy" JMX as much as possible (read and write), but otherwise have a clean break that lets the project move forward sanely.
I'm not sure how you can do that unless the DSL generates JMX.
> Regards,
> Wyatt
>
>
> Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
>
RE: JMeter JMX file format
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, August 12, 2016 7:36 AM
> To: dev@jmeter.apache.org
> Subject: Re: JMeter JMX file format
>
> Note that changing the JMX file format has major implications for
> upwards compatibility.
Part of the problem there is JMX isn't versioned. Or really specified at all. It's a de facto format that arises from the [voodoo] serialisation of the test plan's root ListedHashTree of JMeterTreeNodes. (Please, DO correct me if I'm wrong; even a bad spec would have been useful months ago.)
> That's not to say it cannot be done, but the additional work must be
> considered before deciding to make a change.
In my mind, this is the major motivation for a test plan DSL: retain support for the "legacy" JMX as much as possible (read and write), but otherwise have a clean break that lets the project move forward sanely.
Regards,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.