Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki" for change notification.
The following page has been changed by JMeterAdmin: http://wiki.apache.org/jakarta-jmeter/FutureReleases ------------------------------------------------------------------------------ * Add option to use a single connection per-thread (e.g. if Pool Max=0) * or remove pooling altogether? - does it make sense to share connections between threads, which are supposed to be independent users? * use Apache DBCP instead of Excalibur? + * JDBC sampler - use different cache sizes for connection and statement? + * How do these really work? + * Should the connection cache be a Thread``Local item? + * Need to add debugging to show when cache items are created and destroyed * XPath Extractor - add user-declared namespaces * Rework HTTP GUI to make it easier to use and extend * JDBC IN/OUT/INOUT parameters @@ -76, +80 @@ * Extend CSV Data Set to read via JDBC * Assertion Results (or similar) could be used to attach errors to samples - e.g. if a Post-Processor failed, the error could be shown there instead of in the log. Or just add string array for storing such errors? * Save Graphics should prompt before overwriting files - * Improve HttpMirrorThread class - done, but not submitted (Alf Hogemark) + * Improve Http``Mirror``Thread class - done, but not submitted (Alf Hogemark) * It should allow blocking reads where appropriate, at least when content-length is known * Do not use Reader/Writer classes, which uses JVM default character encoding, causing mirrored content to differ * Add unit tests + * HTTP Cookie Manager should not clear static cookies each iteration = Non-functional improvements = @@ -92, +97 @@ * I looked into adding a GUI / dialog for "Help->View log" to easily view the jmeter log file from the application itself. * Seems to be some open source tools available for log4j which does that out of the box. * Would we gain functionality by moving to log4j ? - * Alternatively, move to Commons Logging (as used by HttpClient currently) + * Alternatively, move to Commons Logging (as used by Http``Client currently) + * Or perhaps SL4J - http://www.slf4j.org/ * What are the risks with continuing to use Avalon, if Avalon is not maintained anymore ? * Move development to the "trunk" of the Subversion repository * Upgrade to httpclient4 ? httpclient4 is still only in Alpha. Should / could we have one sampler class using httpclient3 and one httpclient4 ? @@ -101, +107 @@ * component_reference is getting much too big. This will require changes to the help system. * sort functions and component ref into more logical order (currently chronological) * perhaps use separate XML files for each item, included by main pages ? - * Recode SaveService so it does not load classes unnecessarily (code already developed and tested - not committed) + * Recode Save``Service so it does not load classes unnecessarily (code already developed and tested - not committed) * Re-write Class``Finder: * needs general tidyup / javadoc * cache results - same classes may be requested multiple times @@ -115, +121 @@ * ensure drop-down list size big enough for all entries (within limits!) * move from Bugzilla to JIRA? More flexible, (but attachments a bit more awkward at present?) * Change control logic so it does not use Exceptions for normal situations - * Can we add Beanshell jar to the distribution? If so, then some BeanShell elements could be simplified. + * Can we add Beanshell jar to the distribution? If so, then some BeanShell elements could be simplified. License is either SPL or LGPL, but versions are not stated; not clear if allowed. - * JMS GUIs should be loadable without needing JMS jars (needs an extra level of indirection, as is done by JMS Publisher) + * JMS GUIs should be loadable without needing JMS jars (needs an extra level of indirection, as is done by JMS Publisher) or as below. + * How to handle Gui elements that depend on optional jars: + * should these be displayable, even though the jars are missing? Convenient for creating and viewing test pans, but not so useful at run-time - should the test plan be allowed to run? + * or should they be omitted as at present? - this is confusing at build time. + * or perhaps generate a dummy entry in the list, with a message to say the jar is missing? his would be tricky, as the class is needed to retrieve the name and the menu category. Perhaps the way to do it is to handle it in the GUI by catching the errors, and changing the name or screen comment? May be tedious to do. + * Sort Menu types according to JMeter processing order? + * Controllers + * Config + * Timers + * Pre-Processors + * Samplers + * Assertions + * Post-processors + * Listeners + * Sort test tree according to JMeter processing order? This should probably be a separate action, as it would be confusing for the tree to change as it was editted! + * Re-order HTTP request defaults fields to be like sampler + * Protocol + * Host Port + * Path + * Encoding + * introduce Generic HTTP Sampler which can do either Java or Http``Client or ... + * could be new sampler GUI with new underlying test elements + * but it would be nice if existing test plans were converted into the new sampler. Looked at this a while back, but got stuck with XStream aliasing, which has to be one-to-one at present. However, the code change to Save``Service to remove the class loading should make it possible to have multiple aliases for a single class. That might be sufficient, otherwise we'll need a suitable converter. + + = Release strategy = --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
