> -----Original Message----- > From: Stover, Michael [mailto:[EMAIL PROTECTED]] > > I'm currently working on reversing the relationship between > JMeter test components and GUI components. Right now, it's > sort of a two-way street, and the test components are > required to know certain information about the gui (ie, class > label, gui class, name and the like). So, I'm in the process > of reversing this so that test components are blissfully > unaware of a gui (they don't even exist until the test is > started), and instead, gui code has to know all about test > components. > > I have two interfaces: > JMeterGUIComponent > TestElement
:) Inversion of Control does simplify some things. I like the approach you are taking! > I'm reworking all JMeter elements to fit into this model. I > think the advantages will be obvious: 1. No longer 1-1 > correspondence of gui classes to test classes. Now, there > can be three different gui's that can create HTTP Requests - > each for different needs. A gui that simply asked for the > URL on one line would be quite useful, I think. 2. I'm pretty > sure I can get rid of all specialized save handlers. This > would save everyone the effort of figuring out how to make > their implementations save correctly to .jmx files. 3. I > think I'll be able to implement correct cloning procedures > for everyone, provided they follow some simple rules. 4. GUI > code is already simplifying itself - after reworking a class, > I find most event handling code unused. > 5. Many current config classes are becoming unnecessary - > such as UrlConfig, MultipartUrlConfig. > 6. No more "Logical" and "Generative" controllers. Now, > there are simply Controllers (all are Logicial Controllers), > and Samplers. The generative controllers are going away, and > instead, the Samplers are taking their place. Previously, > Samplers were only created in the JMeter Engine. Now, they > are Test Elements that get configured by gui components, and > then bubble up through the test the way Entry objects did > before. Entry objects will probably go away too. This all sounds like the proper direction. Perhaps we can make the SSL Manager integrate nicely so that each thread can have a unique certificate.... But that would require directly using the Socket API, and not the URL API.... > One disadvantage is that the format of .jmx files will be > completely different than before. I'm not even sure if it > will be feasible to bring old jmx files "up-to-date". If they start as XML and end as XML, we can create an XSLT stylesheet to make the change. I would highly recommend introducing a version attribute to the root element: <jmeter-test version="2.0"> </jmeter-test> (or whatever the root element is). That way we can create XSLT or even better XSLTC to make the transfermation between versions. We would have an import feature to select the correct XSLT transformer based on the version attribute (and if there is none, it would be the current style). That way, people don't have to recreate their scripts--but they can take advantage of the new Jmeter! > After doing this work, I think it will be considerably easier > to apply the Avalon framework and ideas to JMeter. I think the JMeter story is becoming clearer with all the work you are doing. After that, it will be easy to find the main characters, and turn them into components. Keep up the good work! -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
