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

------------------------------------------------------------------------------
    * Would make it a lot easier to see what is what in the tree
   * Make menu options more context sensitive, so they are only enabled when 
they make sense
    * There seems to be some context sensitivity currently, but the code seems 
a bit odd, with explicit methods used by various parts of the code
+  * 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
+  
+ 
  
  = Non-functional improvements =
  
@@ -87, +92 @@

   * 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 ?
   * Remove some code in HTTPSampler, which is there fore workaround for 
httpclient3.0 bug, which has been fixed in httpclient3.1
+  * Reorganise documentation
-  * Reorganise documentation - component_reference is getting much too big. 
This will require changes to the help system.
+   * 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)
+  * Re-write Class``Finder:
+   * needs general tidyup / javadoc
+   * cache results - same classes may be requested multiple times
+   * find a way to scan the classes without needing to load them:
+    * BCEL, or 
+    * perhaps use a pre-generated list of class names in a file which is 
regenerated if any jar files change (MD5)
+  * Test``Bean:
+   * prepare is probably called too often; can it be done once per test?
+   * need some more GUI types - eg. table
+   * would be nice to be able to enable/disable fields depending on what else 
is selected - e.g. JDBC parameters only needed for prepared statements
+   * 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.
+  * JMS GUIs should be loadable without needing JMS jars (needs an extra level 
of indirection, as is done by JMS Publisher)
  
  = Release strategy =
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to