Re: refactorings_branch

[Oliver Rossmueller]

Mike Stover wrote:

On 28 Jan 2003 at 3:38, Oliver Rossmueller wrote:

On Mon, 27 Jan 2003, Mike Stover wrote:

Sure:

Things I don't like:

1. The plugin thing - the advantage of starting faster, to me, isn't worth the disadvantage of
making gui elements harder to write, or more tedious to write.  Maybe because I have too
much of a developer perspective, but an extra few seconds at start time don't bother me.  And
not the whole classpath is searched anyway - only the jars under /ext.  If it's really important,
there are other ways we could speed up JMeter's start up time (JMeter could "remember" the
information and only re-search if timestamps on the jar files have changed or new jars added
since last start).

In fact I started with the plugin thing because I needed a way to map gui
elements to test elements. As the tree holds test elements now and the
test elements know nothing about the gui this kind of mapping is necessary in
one way or another. The fact that detecting element classes is faster is
just a nice side-effect. The real potential of plugins for me is the
possibility to extend JMeter without having to change the JMeter sources
(e.g. because you need a new message resource for your gui). Using a
plugin you tell JMeter about your additional test elements, corresponding
gui elements and icons, and additional message resources.

I don't see why mapping was necessary. The way it is now, the GUI components create their test element and know all about them. Good point about the message resources - perhaps that could be addressed by breaking the message bundles out of the jars so they can be modified more easily?

Yes, now the GUI components create their test element and know all about them. On the branch it is the other way around: the tree panel holds the test element tree and when a test element is select in the tree the corresponding GUI has to be selected and displayed. The test elements have no information about the gui (models) so I have to hold the test element to GUI class mapping somewhere and the plugin is one way to provide this mapping information. It is not the only way, and in fact the plugin stuff can be removed with very little effort should it be necessary.

2. Requiring that GUI elements have to transfer changes immediately to the test elements.  I
didn't see that as necessary.  I like making the nodes hold test elements and reusing GUI
objects, but I was thinking the transfer from GUI to test element could occur at a "trigger"
event, and the duty could be handled by an action, thus relieving GUI component writers of
this duty.  For instance, an event could be generated when needed that results in a call to
"createTestElement" of the GUI component in question, thereby extracting the data for the test
element.  The even could occur when focus is lost/gained, when a test run is started.  Making
GUI writers responsible for keeping test element and gui object in sync is a real pain.

I tried it using focus and other events but it is not that easy and I was
not able to find a working solution this way. In fact writing guis is not
that much more complicated than before. I most cases you just have to
register a DocumentListener for the entry fields and there are helper
classes available to support this. If you now a little bit about Swing it
should be a matter of minutes to write the necessary stuff.

One thing nice about having many developers is often someone can find a solution you didn't see. You're trying to solve it all by yourself.

3. I don't get the whole properties in test element objects, or replacing the map with instance
variables.  How does cloning work now?  In what way was handling user-defined variables
difficult that is now easier?  I could see how property objects could make some things easier
and more modular, but not as instance variables.  I would think you'd still want some sort of
collection to organize and track all the properties.  But what's this have to do with changing
tree nodes from GUI objects to test element objects anyway?

Cloning works like before, instead of cloning the map I have to clone the
properties. This is not direct related to change tree nodes from GUIs to
test elements, but the property objects allow for simple dirty checking
and transparent user variable substitution.

This sounds pretty good then. I agree the property objects are probably useful. I'm still not sure I like them as fixed instance variables. Why not allow new properties to be added ad hoc to a test element?

I can't see how this should work, how should properties a test element does not know of affect the way the test element is doing its work? But if you have a scenario where this makes sense it can still be done one way or another.

4. Changing the jmx file format - seems completely unnecessary.   I can't hardly imagine what
you did that means you can't write the jmx in a compatible format?

Here is why: the current jmx format holds information like the name of the
gui class which are not held by the test elements anymore. That's the easy
part. The more difficult part is that because of what I think is a bug all
- or almost all configuration elements like FTP Defaults or HTTP Defaults
- are stored with class org.apache.jmeter.config.ConfigTestElement in the
jmx files but are separate test element classes now. All this would
require some kind of mapping from the new to the old structure to write
compatible jmx files. So perhaps I should better say that I'm not
confident this can work and that from my point of view the effort required
to do/try it is not worth it. I'm still not 100% sure that it will be possible
to create a mapping from the jmx files to the new internal structure.
It is always a problem to change file formats, but it will be possible to
load jmx files - at least I hope so - so you will not loose your
any existing test plans. And with the new JMeter you have a new file
format, a tradeoff that hopefully will be worth the deal because of all
the other great new features which will be available.

So these problems are a result of a) the mapping from plugins and b) making properties instance variables, thus requiring that every test element be it's own class. Neither of which seems necessary to me, so we could probably fix those things and remain compatible with current .jmx files.

Might be possible. I was thinking about this matter and am quite sure now that it would be possible to transform my new file format to the old jmx format on the XML level using XSLT. And if it is possible using XSLT than it can also be done in Java when the XML is generated. Needs further investigation but I think this issue can be solved.

Things I like:
1.  Using test element objects in the tree; only one instance of each gui class - should make a
marked difference in performance.

2.  Property objects have potential, but should hurt file format compatibility.

3. Splash screen, toolbar, and tabbed main panel all seem good.

-Mike

Probably it was the wrong decision to do all this changes at once and not
cleanly separate them, but anyway if I'm wasting my time from your point
of view I will continue my work on the branch. At some point we will have
to decide if what I did is okay for all of us. If this is not the case
that was my own risk. At least I have my private JMeter version then ;-)
And of corse I'm open for discussion, ideas, contribution, ...

Oliver

[snip]

Oliver

smime.p7s
Description: S/MIME Cryptographic Signature