> -----Original Message----- > From: Stover, Michael [mailto:[EMAIL PROTECTED]] > > -----Original Message----- > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
<snip/> > > > > Avalon already has the code to convert XML to and from > configuration > > objects--preserving namespaces if necessary. Now all you have to do > > > Using the configuration elements makes the system easier to > > build as you > > don't have the added complexity that comes with registering > > data mappers > > with the component types. Each component handles how it > > interprets the > > config element as it wants. > > But this neglects the issue of who had to create the > configuration element/XML with the correct ingredients. In > my thinking, your example is very useful if we're talking > about an object saving itself to XML, and then recreating > itself from that same XML, because in that case, only the > object is required to know it's own XML format. Which happens to be 99% of most scenarios. If the engine deals strictly with the configuration interface, then we have the flexibility of using the *same* configuration for all the servers in a distributed setup. It also allows us to completely divorce the front end or GUI from the test engine. The instrument package (which is finally available in CVS: jakarta-avalon-excalibur/instrument) shows how this can be possible (using the commons altrmi package). Attaching a GUI to a running test engine can be useful when you want to administrate remote test engines as well (same GUI, different server). > > For external objects trying to configure the Component, it is > no simpler to generate correct XML than it is to correctly > use a Java interface. The current method to generate XML is to write strings to a file. This is error prone, and you need some DOM-like approach to ensure that the XML format is correct. It would be a shame for a GUI to break an otherwise good test script because it misplaced the opening bracket on a test element. No matter what we use, we cannot allow the developer to simply write strings to the output file. When we do that, we have a *very* fragile test script serialization system. That is not good. You have to consider who is writing the serialization portion. By using a generic configuration API, we can simplify the creation of the test script, and maintain the serialization in one place. In the end, you save a lot of time and frustration. > Consider in JMeter, the GUI objects have to create test > elements. Would it make sense for the gui objects to create > XML, or configuration objects, which is then used to > configure test elements, or, have the GUI objects configure > the test elements by calling appropriate methods on those > elements? I vote for the latter, if only because it is what > Java Developers expect to have to learn. I'm not going to argue on this point. In the end, it is up to what you feel is right. However, if you use the special purpose configuration object approach (which is what you are proposing), then *you* need to define all acceptible configuration objects. Otherwise, as new configuation objects are added in the system, the serialization code can easily break. As a point of scalability I am against interfaces which unnecessarily force you call a number of methods before you can use a component. You pass in a configuration object--of whatever form you choose (avalon configuration or generic JavaBean), but you do it all at once--not a little at a time. The reason is that such a situation is not threadsafe. It forces you to arbitrarily have multiple instances of the same component in memory wasting resources when one could do. Simple interfaces with only one action method are best. It allows you to decide based on the *implementation* if the component should be pooled or not. Furthermore, I dislike combining configuration and action in the same interface which is what it sounds like you are talking about. The bottom line is that I want to avoid fragile testcase files like we have now. It would also help the distributed test engine case if we use a standard config object. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
