RE: MultiByte related issues in BugZilla
Hi, There are many issues in Bugzilla related to MultiByte which are difficult to fix without more information: - 48372 https://issues.apache.org/bugzilla/show_bug.cgi?id=48372 - 49039 https://issues.apache.org/bugzilla/show_bug.cgi?id=49039 It looks as if these two bugs are not really related (the first one it seems related to test plan serialization, the second one to changes the proxy server introduces compared to the normal byte stream). I just explained this issue more in detail in my recent message here in the list (Thu, 19 Jan, 12:50) - unfortunately no reply on this topic yet. Jens
Re: Properties files in mavenised artifacts
On 23 January 2012 06:38, Mark Collin m...@ardescosolutions.com wrote:
The mvn deploy command should also build the package if the build section
exists in the POM so you could have a build section for the parent POM that
only pulls in resources that are required (this would muddy the waters
slightly but seems like the pragmatic approach).
Ant build is currently only using deploy-file, which does not build anything.
The problem with deploy (as used when testing this previously) is that
it wants to build (and test) everything, which means that it
regenerates the jars.
Apart from being quite slow and unnecessary, the deployed jars would
then be different from the binary archive.
Of course you could also tweak your ant script to build all of the
dependencies into a jar and then deploy that as well for the mavenised
build. This sounds worse IMHO because you are modifying your existing build
process to create something that your normal ant build doesn't require.
That's what I have done for now; however I've put it in a maven-only task.
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 01:50
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 01:03, sebb seb...@gmail.com wrote:
On 22 January 2012 18:21, Mark Collin m...@ardescosolutions.com wrote:
Parent sounds like a good place.
Normally it would pick up things in src/main/resources, but as you
don't have a maven directory structure I think you'll need to define
a resource dir in the parent POM. Something like this should work:
resources
resource
directory${basedir}/bin/directory
includes
include**/*.properties/include
/includes
/resource
/resources
OK, thanks, I'll try that.
Just realised that won't work for creating the files to be uploaded, as we
don't use Maven to create the artifacts.
I'm not sure exactly where you would need to place it in the
artifact, I guess that depends on where you expect them to be when you
read them in.
JMeter expects to find them in the bin/ directory, i.e. where it finds
ApacheJMeter.jar.
However, I've no idea how any JMeter Maven launch plugins are intended
to work so that may not be appropriate.
Sorry, but I've no idea how to make this work.
All I can suggest is creating a jar containing the missing properties files
(there are also some other missing files) which can be uploaded as parent.
Whether that will be usable, I've no idea.
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 22 January 2012 11:42
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 21 January 2012 22:55, Mark Collin m...@ardescosolutions.com wrote:
I've been hunting through the mavenised artifacts available at:
https://repository.apache.org/content/repositories/snapshots/org/apa
ch
e/jmet
er/
However I cannot find the following in any package:
saveservice.properties
upgrade.properties
system.properties
jmeter.properties
user.properties
If I'm being blind please point me in the right direction, if I'm
not being blind can we get these added to an artefact, or another
artefact added that contains these.
You're right, those files are normally provided as part of the full
binary archive, which contains quite a few files in addition to the jars.
Adding them to an existing jar may cause issues for non-Maven users,
so they need to be in a new artifact.
Possibly change parent to be a jar?
But having them in a jar would be a bit of a pain.
How do Maven applications manage configuration files normally?
--
Mark Collin
Managing Director
Ardesco Solutions Ltd
mailto:m...@ardescosolutions.com m...@ardescosolutions.com
Registered Office:
The Coachhouse
Greys Green Business Centre
Henley-on-Thames
Oxon
RG9 4QG
REGISTERED IN ENGLAND NO. 4837759
--
This message contains confidential information and is intended only
for
the individual named. If you are not the named addressee you should
not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
If you have received this email in error please notify
postmas...@ardescosolutions.com
--
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified
Re: Apache Excalibur Logger
On 23 January 2012 03:22, Anthony Johnson ans...@gmail.com wrote: On Sun, Jan 22, 2012 at 9:28 PM, sebb seb...@gmail.com wrote: On 23 January 2012 01:46, Anthony Johnson ans...@gmail.com wrote: On Sun, Jan 22, 2012 at 8:29 PM, sebb seb...@gmail.com wrote: On 22 January 2012 13:04, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, I noticed there was some plan to remove Excalibur logger dependency. What is the new selected component to replace it ? - log4j - slf4J+logback Given that the main focus of JMeter is HTTP, and we use Apache HttpClient, if we do replace logging it will be sensible to use the same, i.e. Commons Logging. But it is a huge job to do this; every single file that uses logging will need to be updated. As well as changing all the documentation, config files etc. When do we plan this migration ? Not yet. Working on 41788 https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed javadocs for excalibur where no more available on internet. I suppose the same question will arise regarding DataBase Sampler pool. What are the candidates: - Tomcat JDBC Pool : http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html - Commons DBCP ? I wonder whether there's really any point supporting database pooling at all, given that the focus of JMeter is on independent test threads. JMeter definitely needs persistent database connections which is easily accomplished with database pooling. JMeter loses usefulness if it has to open a connection at sample time since this is a lot more expensive than running optimized SQL. Also, some database features rely on persistent connections to be optimized such as PreparedStatement caches. JMeter uses persistent connections; the connection is established by: http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration This is a different matter from sharing connections between threads. The per-thread (non-shared) pool is currently implemented as a pool size of 1 per thread. The preferred way(per the sarcastic why use pooling in the docs:-) is not very nice code-wise. If I have a 1,000 thread test then I will have a 1,000 excaliber thread pool objects in memory and 1,000 per-thread poolMap objects. Getting rid of pooling in JMeter would definitely make this code better. Even without Excalibur pool, we would still need per-thread data to hold the connection(s) for a thread. But it might well reduce the resource requirements if we used our own holding object. On the other hand, their are nice features from the pooling such as connection testing, keep-alives and such. Some of those would need to be implemented if you guys decided to rip out pooling. Regardless, you responded to my only concern and I learned something(despite having written several JDBC Test Plans in the past:-/) Adding pooling effectively means that JMeter is testing the pooling as well as the database. I made some Load tests for an ECommerce site comparing the 2 pools and the first one seems to be a little better performing (specially in exhaustion cases) although Commons DBCP quality is great. I don't think database pooling is really necessary for JMeter, so the performance is not a big issue; tests that want to exercise a database should not be using pooling - or at least should not be using a pooling solution which is fixed by JMeter. I don't know whether it's possible to create a datasource which includes pooling, if so, then that is the way to go - i.e. support data sources (I don't think we do currently). -- Cordialement. Philippe Mouawad.
Re: Properties files in mavenised artifacts
On 23 January 2012 13:08, Mark Collin m...@ardescosolutions.com wrote:
Yes parent really does have to be a POM package.
Bother.
So we need another jar and another pom.
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
I've just tried using the latest 2.6-SNAPSHOT and I'm getting the following
error:
How are you using it?
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.jmeter:ApacheJMeter_core
Reason: Parent: org.apache.jmeter:ApacheJMeter_parent:jar:2.6-SNAPSHOT of
project: org.apache.jmeter:ApacheJMeter_core has
wrong packaging: jar. Must be 'pom'. for project
org.apache.jmeter:ApacheJMeter_core
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 12 seconds
[INFO] Finished at: Mon Jan 23 13:03:50 GMT 2012
[INFO] Final Memory: 13M/107M
[INFO]
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 12:15
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 12:03, Mark Collin m...@ardescosolutions.com wrote:
Thinking about it, I think I'm talking a degree of rubbish here.
A parent needs to be packaged as a pom and not a jar so even if you
add a build section it's not going to work. I think you will instead
need to have a new package that the parent depends on that pulls in these
extra files.
Currently, the parent is now a jar package which contains the configuration
files.
The poms are basically just being used as jar descriptors and dependency
declarations currently.
Does the parent really have to be a pom package?
Has anyone tried using one of the latest snapshots (i.e. one with
ApacheJMeter_parent.jar as well as .pom)?
-Original Message-
From: Mark Collin [mailto:m...@ardescosolutions.com]
Sent: 23 January 2012 06:39
To: dev@jmeter.apache.org
Subject: RE: Properties files in mavenised artifacts
The mvn deploy command should also build the package if the build
section exists in the POM so you could have a build section for the
parent POM that only pulls in resources that are required (this would
muddy the waters slightly but seems like the pragmatic approach).
Of course you could also tweak your ant script to build all of the
dependencies into a jar and then deploy that as well for the mavenised
build. This sounds worse IMHO because you are modifying your existing
build process to create something that your normal ant build doesn't
require.
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 01:50
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 01:03, sebb seb...@gmail.com wrote:
On 22 January 2012 18:21, Mark Collin m...@ardescosolutions.com wrote:
Parent sounds like a good place.
Normally it would pick up things in src/main/resources, but as you
don't have a maven directory structure I think you'll need to define
a resource dir in the parent POM. Something like this should work:
resources
resource
directory${basedir}/bin/directory
includes
include**/*.properties/include
/includes
/resource
/resources
OK, thanks, I'll try that.
Just realised that won't work for creating the files to be uploaded,
as we don't use Maven to create the artifacts.
I'm not sure exactly where you would need to place it in the
artifact, I guess that depends on where you expect them to be when
you
read them in.
JMeter expects to find them in the bin/ directory, i.e. where it
finds ApacheJMeter.jar.
However, I've no idea how any JMeter Maven launch plugins are
intended to work so that may not be appropriate.
Sorry, but I've no idea how to make this work.
All I can suggest is creating a jar containing the missing properties
files (there are also some other missing files) which can be uploaded as
parent
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.
If you have received this email in error please notify
postmas...@ardescosolutions.com
RE: Properties files in mavenised artifacts
Unfortunately that's what it looks like :(
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 13:46
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 13:08, Mark Collin m...@ardescosolutions.com wrote:
Yes parent really does have to be a POM package.
Bother.
So we need another jar and another pom.
http://maven.apache.org/guides/introduction/introduction-to-the-pom.ht
ml
I've just tried using the latest 2.6-SNAPSHOT and I'm getting the
following
error:
How are you using it?
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
-- [INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.jmeter:ApacheJMeter_core
Reason: Parent: org.apache.jmeter:ApacheJMeter_parent:jar:2.6-SNAPSHOT
of
project: org.apache.jmeter:ApacheJMeter_core has wrong packaging: jar.
Must be 'pom'. for project org.apache.jmeter:ApacheJMeter_core
[INFO]
--
-- [INFO] For more information, run Maven with the -e switch [INFO]
--
--
[INFO] Total time: 12 seconds
[INFO] Finished at: Mon Jan 23 13:03:50 GMT 2012 [INFO] Final Memory:
13M/107M [INFO]
--
--
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 12:15
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 12:03, Mark Collin m...@ardescosolutions.com wrote:
Thinking about it, I think I'm talking a degree of rubbish here.
A parent needs to be packaged as a pom and not a jar so even if you
add a build section it's not going to work. I think you will instead
need to have a new package that the parent depends on that pulls in
these
extra files.
Currently, the parent is now a jar package which contains the
configuration files.
The poms are basically just being used as jar descriptors and
dependency declarations currently.
Does the parent really have to be a pom package?
Has anyone tried using one of the latest snapshots (i.e. one with
ApacheJMeter_parent.jar as well as .pom)?
-Original Message-
From: Mark Collin [mailto:m...@ardescosolutions.com]
Sent: 23 January 2012 06:39
To: dev@jmeter.apache.org
Subject: RE: Properties files in mavenised artifacts
The mvn deploy command should also build the package if the build
section exists in the POM so you could have a build section for the
parent POM that only pulls in resources that are required (this would
muddy the waters slightly but seems like the pragmatic approach).
Of course you could also tweak your ant script to build all of the
dependencies into a jar and then deploy that as well for the
mavenised build. This sounds worse IMHO because you are modifying
your existing build process to create something that your normal ant
build doesn't
require.
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 23 January 2012 01:50
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts
On 23 January 2012 01:03, sebb seb...@gmail.com wrote:
On 22 January 2012 18:21, Mark Collin m...@ardescosolutions.com wrote:
Parent sounds like a good place.
Normally it would pick up things in src/main/resources, but as you
don't have a maven directory structure I think you'll need to
define a resource dir in the parent POM. Something like this should
work:
resources
resource
directory${basedir}/bin/directory
includes
include**/*.properties/include
/includes
/resource
/resources
OK, thanks, I'll try that.
Just realised that won't work for creating the files to be uploaded,
as we don't use Maven to create the artifacts.
I'm not sure exactly where you would need to place it in the
artifact, I guess that depends on where you expect them to be when
you
read them in.
JMeter expects to find them in the bin/ directory, i.e. where it
finds ApacheJMeter.jar.
However, I've no idea how any JMeter Maven launch plugins are
intended to work so that may not be appropriate.
Sorry, but I've no idea how to make this work.
All I can suggest is creating a jar containing the missing properties
files (there are also some other missing files) which can be uploaded
as
parent
--
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
Re: Properties files in mavenised artifacts
On 23 January 2012 16:29, Mark Collin m...@ardescosolutions.com wrote: I'm in the process of simplifying it right now. The plan is that the only thing you will need to supply in the future is test files (obviously in a mavenised directory structure). With the stand-alone (and Ant) installation, it's easy for users to update the properties files if they need to. Will that be possible with the plugin? -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 23 January 2012 15:35 To: dev@jmeter.apache.org Subject: Re: Properties files in mavenised artifacts On 23 January 2012 15:05, Mark Collin m...@ardescosolutions.com wrote: That's what I am seeing, I was also expecting the following: saveservice.properties upgrade.properties system.properties jmeter.properties user.properties Oops, should be fixed now. Tried the JMeter Maven plugin, and it requires quite a lot of additional set up (creating work dirs etc.). Not easy to use compared with JMeter scripts or the JMeter Ant task (see extras/build.xml) -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 23 January 2012 14:57 To: dev@jmeter.apache.org Subject: Re: Properties files in mavenised artifacts On 23 January 2012 14:46, Mark Collin m...@ardescosolutions.com wrote: I'm able to pull the artifacts in and use them again, but I can't see any properties files in the ApacheJMeter_config jar. Just downloaded it, and I get: $ jar -tvf ApacheJMeter_config-2.6-20120123.135339-1.jar 0 Mon Jan 23 13:50:32 GMT 2012 META-INF/ 373 Mon Jan 23 13:50:30 GMT 2012 META-INF/MANIFEST.MF 172 Sat Jan 21 17:08:48 GMT 2012 META-INF/NOTICE 11560 Sat Jan 21 17:08:48 GMT 2012 META-INF/LICENSE 0 Mon Jan 23 01:39:32 GMT 2012 bin/ 1435 Sat Apr 05 02:49:46 BST 2008 bin/BeanShellAssertion.bshrc 2079 Fri Apr 17 11:29:10 BST 2009 bin/BeanShellFunction.bshrc 1232 Sat Apr 05 02:50:08 BST 2008 bin/BeanShellListeners.bshrc 2105 Sat Sep 17 16:40:04 BST 2011 bin/BeanShellSampler.bshrc 1406 Tue Dec 14 17:33:02 GMT 2010 bin/hc.parameters 1563 Fri Dec 10 02:29:52 GMT 2010 bin/httpclient.parameters 1801 Fri Jan 28 15:04:14 GMT 2011 bin/log4j.conf 5781 Fri Dec 16 10:57:22 GMT 2011 bin/logkit.xml 1324 Wed Aug 05 23:42:30 BST 2009 bin/proxyserver.jks 1022 Tue Apr 08 12:36:12 BST 2008 bin/users.dtd 2365 Tue Apr 08 12:36:14 BST 2008 bin/users.xml I'm testing it by building this: https://github.com/Ronnie76er/jmeter-maven-plugin OK, thanks, if that is not too time-consuming to set up I'll try it out. If that builds and successfully creates the package I'm using it to run a couple of JMeter tests. The above currently has copies of the properties files to enable it to run until they are available in maven artifacts. -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 23 January 2012 14:23 To: dev@jmeter.apache.org Subject: Re: Properties files in mavenised artifacts On 23 January 2012 14:14, Mark Collin m...@ardescosolutions.com wrote: Unfortunately that's what it looks like :( I've uploaded another version which creates a _config jar. Can you try that? Also, how are you testing it? It might speed turnround if I could test the deployed jars myself. -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 23 January 2012 13:46 To: dev@jmeter.apache.org Subject: Re: Properties files in mavenised artifacts On 23 January 2012 13:08, Mark Collin m...@ardescosolutions.com wrote: Yes parent really does have to be a POM package. Bother. So we need another jar and another pom. http://maven.apache.org/guides/introduction/introduction-to-the-pom. h t ml I've just tried using the latest 2.6-SNAPSHOT and I'm getting the following error: How are you using it? [INFO] --- - - - -- [ERROR] BUILD ERROR [INFO] --- - - - -- [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.jmeter:ApacheJMeter_core Reason: Parent: org.apache.jmeter:ApacheJMeter_parent:jar:2.6-SNAPSHOT of project: org.apache.jmeter:ApacheJMeter_core has wrong packaging: jar. Must be 'pom'. for project org.apache.jmeter:ApacheJMeter_core [INFO] --- - - - -- [INFO] For more information, run Maven with the -e switch [INFO] --- - - - -- [INFO] Total time: 12 seconds [INFO] Finished at: Mon Jan 23 13:03:50 GMT 2012 [INFO] Final Memory: 13M/107M [INFO] --- - - - -- -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: 23 January 2012 12:15 To: dev@jmeter.apache.org Subject: Re: Properties files in mavenised artifacts On 23 January 2012 12:03, Mark Collin
Re: New Logger Panel
On Mon, Jan 23, 2012 at 5:18 PM, sebb seb...@gmail.com wrote: On 23 January 2012 15:34, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, My answers below. On Mon, Jan 23, 2012 at 3:51 PM, sebb seb...@gmail.com wrote: The Logger panel is useful, but I really don't like the way it is added to every single GUI pane. Is that really intentional? Can you explain what you mean ?. Today LoggerPanel is initialized at creation of MainFrame and not every time you open a Test Plan. Start JMeter (Gui mode) Select Test Plan, then Workbench. No logger panel showing in either. Check Options/Logviewer Now both Workbench and Test Plan have the logger panel. Same applies to any other Gui screens. Yes it's intentional, because when I test a plan I want the console view to be always here. It's like the console in Eclipse. It is in MainFrame. I still not see what you would like to have. Also at present, disabling the option does not appear to release the memory, because the same contents are redisplayed when re-enabled. Ok with this, I'll fix it this evening. It might make more sense to add it to the workbench GUI. This could then provide options to clear/refresh/reload/change size etc. These are already handled in current implementation ? No, they are not, at least not at run-time. I am not sure to see what you are want, but if you are talking about menu options to clear, refresh , change size, well I imagined the same behaviour as Eclipse console, with some icons to clear. -- Cordialement. Philippe Mouawad. -- Cordialement. Philippe Mouawad.
Re: New Logger Panel
On 23 January 2012 17:52, Philippe Mouawad philippe.moua...@gmail.com wrote: On Mon, Jan 23, 2012 at 5:18 PM, sebb seb...@gmail.com wrote: On 23 January 2012 15:34, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, My answers below. On Mon, Jan 23, 2012 at 3:51 PM, sebb seb...@gmail.com wrote: The Logger panel is useful, but I really don't like the way it is added to every single GUI pane. Is that really intentional? Can you explain what you mean ?. Today LoggerPanel is initialized at creation of MainFrame and not every time you open a Test Plan. Start JMeter (Gui mode) Select Test Plan, then Workbench. No logger panel showing in either. Check Options/Logviewer Now both Workbench and Test Plan have the logger panel. Same applies to any other Gui screens. Yes it's intentional, because when I test a plan I want the console view to be always here. It's like the console in Eclipse. It is in MainFrame. I still not see what you would like to have. I think it looks wrong for every GUI to have a console panel at the bottom. Some GUIs are already very full, and adding the console view means the rest of the Gui will need to be scrolled. Either have a single panel, for example on the Workbench Gui - or even a new Gui - or have a floating panel that can be visible independently of the existing Guis. Also at present, disabling the option does not appear to release the memory, because the same contents are redisplayed when re-enabled. Ok with this, I'll fix it this evening. It might make more sense to add it to the workbench GUI. This could then provide options to clear/refresh/reload/change size etc. These are already handled in current implementation ? No, they are not, at least not at run-time. I am not sure to see what you are want, but if you are talking about menu options to clear, refresh , change size, well I imagined the same behaviour as Eclipse console, with some icons to clear. -- Cordialement. Philippe Mouawad. -- Cordialement. Philippe Mouawad.
Re: New Logger Panel
On 23 January 2012 19:56, Philippe Mouawad philippe.moua...@gmail.com wrote: On Mon, Jan 23, 2012 at 8:14 PM, sebb seb...@gmail.com wrote: On 23 January 2012 17:52, Philippe Mouawad philippe.moua...@gmail.com wrote: On Mon, Jan 23, 2012 at 5:18 PM, sebb seb...@gmail.com wrote: On 23 January 2012 15:34, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, My answers below. On Mon, Jan 23, 2012 at 3:51 PM, sebb seb...@gmail.com wrote: The Logger panel is useful, but I really don't like the way it is added to every single GUI pane. Is that really intentional? Can you explain what you mean ?. Today LoggerPanel is initialized at creation of MainFrame and not every time you open a Test Plan. Start JMeter (Gui mode) Select Test Plan, then Workbench. No logger panel showing in either. Check Options/Logviewer Now both Workbench and Test Plan have the logger panel. Same applies to any other Gui screens. Yes it's intentional, because when I test a plan I want the console view to be always here. It's like the console in Eclipse. It is in MainFrame. I still not see what you would like to have. I think it looks wrong for every GUI to have a console panel at the bottom. Some GUIs are already very full, and adding the console view means the rest of the Gui will need to be scrolled. I don't have the same opinion, when you write a script, you usually have a TreeView result and you click on failed sampler then look at response and then look in the logs if there is an error. In that case, having the console only on the Listener would be sufficient. As it is shown in Milamber screenshot. Regarding the place taken, you always have the option to click on divider at left to minimize window. Yes, but changing the size affects *all* gui screens, so if you close the console on one screen it won't be visible anywhere. Finally, LoggerPanel is independant of GUIs in term of implementation . Not sure that's relevant here. Either have a single panel, for example on the Workbench Gui - or even a new Gui - or have a floating panel that can be visible independently of the existing Guis. I must still say I don't see what you would like, maybe a screenshot on the Bugzilla will help me understand. I meant a floating panel like the Help viewer. Also at present, disabling the option does not appear to release the memory, because the same contents are redisplayed when re-enabled. Ok with this, I'll fix it this evening. It might make more sense to add it to the workbench GUI. This could then provide options to clear/refresh/reload/change size etc. These are already handled in current implementation ? No, they are not, at least not at run-time. I am not sure to see what you are want, but if you are talking about menu options to clear, refresh , change size, well I imagined the same behaviour as Eclipse console, with some icons to clear. -- Cordialement. Philippe Mouawad. -- Cordialement. Philippe Mouawad. -- Cordialement. Philippe Mouawad.
Re: svn commit: r1233093 - in /jmeter/trunk/src/core/org/apache/jmeter: gui/action/Remove.java resources/messages.properties resources/messages_fr.properties
On 18 January 2012 22:24, Milamber milam...@apache.org wrote:
Hello,
I can add a property (in jmeter.properties) to revert to default
behavior (remove without confirmation) but I don't think it is necessary.
I found the new behaviour annoying, so I added a property to skip the dialogue.
By default JMeter will still prompt.
Milamber
Le 18/01/2012 22:18, milam...@apache.org a ecrit :
Author: milamber
Date: Wed Jan 18 22:18:57 2012
New Revision: 1233093
URL: http://svn.apache.org/viewvc?rev=1233093view=rev
Log:
Add a dialog box to confirm removing the element(s) when Remove action is
called
Modified:
jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java
jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
Modified: jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java (original)
+++ jmeter/trunk/src/core/org/apache/jmeter/gui/action/Remove.java Wed Jan
18 22:18:57 2012
@@ -28,6 +28,7 @@ import javax.swing.tree.TreePath;
import org.apache.jmeter.gui.GuiPackage;
import org.apache.jmeter.gui.tree.JMeterTreeNode;
import org.apache.jmeter.testelement.TestElement;
+import org.apache.jmeter.util.JMeterUtils;
/**
* Implements the Remove menu item.
@@ -56,17 +57,24 @@ public class Remove implements Command {
}
public void doAction(ActionEvent e) {
- // TODO - removes the nodes from the CheckDirty map - should it be
done later, in case some can't be removed?
- ActionRouter.getInstance().actionPerformed(new
ActionEvent(e.getSource(), e.getID(), ActionNames.CHECK_REMOVE));
- GuiPackage guiPackage = GuiPackage.getInstance();
- JMeterTreeNode[] nodes =
guiPackage.getTreeListener().getSelectedNodes();
- TreePath newTreePath = // Save parent node for later
- guiPackage.getTreeListener().removedSelectedNode();
- for (int i = nodes.length - 1; i = 0; i--) {
- removeNode(nodes[i]);
+ int isConfirm = JOptionPane.showConfirmDialog(null,
+ JMeterUtils.getResString(remove_confirm_msg),//
$NON-NLS-1$
+ JMeterUtils.getResString(remove_confirm_title), //
$NON-NLS-1$
+ JOptionPane.WARNING_MESSAGE,
+ JOptionPane.YES_NO_OPTION);
+ if (isConfirm == JOptionPane.YES_OPTION) {
+ // TODO - removes the nodes from the CheckDirty map - should it
be done later, in case some can't be removed?
+ ActionRouter.getInstance().actionPerformed(new
ActionEvent(e.getSource(), e.getID(), ActionNames.CHECK_REMOVE));
+ GuiPackage guiPackage = GuiPackage.getInstance();
+ JMeterTreeNode[] nodes =
guiPackage.getTreeListener().getSelectedNodes();
+ TreePath newTreePath = // Save parent node for later
+ guiPackage.getTreeListener().removedSelectedNode();
+ for (int i = nodes.length - 1; i = 0; i--) {
+ removeNode(nodes[i]);
+ }
+
guiPackage.getTreeListener().getJTree().setSelectionPath(newTreePath);
+ guiPackage.updateCurrentGui();
}
-
guiPackage.getTreeListener().getJTree().setSelectionPath(newTreePath);
- guiPackage.updateCurrentGui();
}
private static void removeNode(JMeterTreeNode node) {
Modified:
jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
(original)
+++ jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
Wed Jan 18 22:18:57 2012
@@ -695,6 +695,8 @@ remote_start_all=Remote Start All
remote_stop=Remote Stop
remote_stop_all=Remote Stop All
remove=Remove
+remove_confirm_title=Confirm remove?
+remove_confirm_msg=Are you sure you want remove this element(s)?
rename=Rename entry
report=Report
report_bar_chart=Bar Chart
Modified:
jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties?rev=1233093r1=1233092r2=1233093view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
(original)
+++ jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
Wed Jan
