Re: [g...@vmgump]: Project cactus (in module jakarta-cactus) failed

[sebb]

That's probably because you are subscribed as mfigueir...@maisis.pt

Send the e-mail to

dev-unsubscribe-mfigueiredo=maisis...@jakarta.apache.org

and reply to the confirmation e-mail

On 22/04/2010, Miguel Figueiredo  wrote:
> Hello all,
>
>  I was subscribed to the retired Slide Project and now I'm receiving emails 
> from d...@jakarta.apache.org. unsubscribing through 
> dev-unsubscr...@jakarta.apache.org does not work... what shall I do?
>
>  Many thanks,
>  Miguel
>
>  -Original Message-
>  From: Petar Tahchiev [mailto:ptahch...@apache.org]
>  Sent: quinta-feira, 22 de Abril de 2010 16:50
>  To: cactus-...@jakarta.apache.org
>  Subject: [g...@vmgump]: Project cactus (in module jakarta-cactus) failed
>
>  To whom it may engage...
>
>  This is an automated request, but not an unsolicited one. For
>  more information please visit http://gump.apache.org/nagged.html,
>  and/or contact the folk at gene...@gump.apache.org.
>
>  Project cactus has an issue affecting its community integration.
>  This issue affects 3 projects,
>   and has been outstanding for 793 runs.
>  The current state of this project is 'Failed', with reason 'Build Failed'.
>  For reference only, the following projects are affected by this:
> - cactus :  Cactus Framework
> - portals-jetspeed-1 :  Enterprise Information Portal
> - strutstestcase :  An extension of the standard JUnit TestCase class 
> that provi...
>
>
>  Full details are available at:
> http://vmgump.apache.org/gump/public/jakarta-cactus/cactus/index.html
>
>  That said, some information snippets are provided here.
>
>  The following annotations (debug/informational/warning/error messages) were 
> provided:
>   -DEBUG- Sole output 
> [cactus.core.framework.uberjar.javaEE.14-1.8.1-SNAPSHOT.jar] identifier set 
> to project name
>   -INFO- Optional dependency httpunit failed with reason build failed
>   -INFO- Optional dependency jetty failed with reason build failed
>   -DEBUG- (Gump generated) Maven2 Settings in: 
> /srv/gump/public/workspace/jakarta-cactus/gump_mvn_settings.xml
>   -INFO- Failed with reason build failed
>   -DEBUG- Maven POM in: /srv/gump/public/workspace/jakarta-cactus/pom.xml
>   -INFO- Project Reports in: 
> /srv/gump/public/workspace/jakarta-cactus/build/test-report
>   -WARNING- No directory 
> [/srv/gump/public/workspace/jakarta-cactus/build/test-report]
>   -INFO- Failed to extract fallback artifacts from Gump Repository
>
>
>
>  The following work was performed:
>  
> http://vmgump.apache.org/gump/public/jakarta-cactus/cactus/gump_work/build_jakarta-cactus_cactus.html
>  Work Name: build_jakarta-cactus_cactus (Type: Build)
>  Work ended in a state of : Failed
>  Elapsed: 1 min 12 secs
>  Command Line: mvn --batch-mode -Dsurefire.useFile=false --settings 
> /srv/gump/public/workspace/jakarta-cactus/gump_mvn_settings.xml install
>  [Working Directory: /srv/gump/public/workspace/jakarta-cactus]
>  CLASSPATH: 
> /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/cargo/core/containers/weblogic/target/cargo-core-container-weblogic-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/jetty/target/cargo-core-container-jetty-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/api/module/target/cargo-core-api-module-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/resources/build-tools/target/cargo-build-tools-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/jrun/target/cargo-core-container-jrun-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/resin/target/cargo-core-container-resin-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/extensions/maven2/plugin/target/cargo-maven2-plugin-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/tomcat/target/cargo-core-container-tomcat-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/jo/target/cargo-core-container-jo-1.0.1-SNAPSH
>   
> OT.jar:/srv/gump/public/workspace/cargo/core/api/generic/target/cargo-core-api-generic-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/orion/target/cargo-core-container-orion-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/api/container/target/cargo-core-api-container-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/jonas/target/cargo-core-container-jonas-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/jboss/target/cargo-core-container-jboss-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/extensions/ant/target/cargo-ant-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/uberjar/target/cargo-core-uberjar-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/containers/geronimo/target/cargo-core-container-geronimo-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/cargo/core/api/util/target/cargo-core-api-util-1.0.1-SNAPSHOT.jar:/srv/gump/public/workspace/checkstyle/target/dist/checkstyle-22042010/chec
>   
> kstyle-22042010.jar:/srv/gump/public/workspace/checkstyle/target/dist/c

Release BSF 3.1 ?

[sebb]

There have been a few changes to the BSF 3.x code line since 3.0.

I think it would be good to release version 3.1 along with its Maven version.

I've asked for Nexus access for BSF 3.x, so I propose to use that for
staging/voting on the Maven artifacts.

I'm happy to manage the release, unless anyone else wants to do it.

Comments?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[Travel Assistance] - applications Open for ApacheCon NA 2010

[sebb]

 The Travel Assistance Committee is now taking in applications for those
 wanting to attend ApacheCon North America (NA) 2010, which is taking place
 between the 1st and 5th November in Atlanta.

 The Travel Assistance Committee is looking for people who would like to be
 able to attend ApacheCon, but who need some financial support in order to be
 able to get there. There are limited places available, and all applications
 will be scored on their individual merit.

 Financial assistance is available to cover travel to the event, either in
 part or in full, depending on circumstances. However, the support available
 for those attending only the barcamp is smaller than that for people
 attending the whole event. The Travel Assistance Committee aims to support
 all ApacheCons, and cross-project events, and so it may be prudent for those
 in Asia and the EU to wait for an event closer to them.

 More information can be found on the main Apache website at
 http://www.apache.org/travel/index.html - where you will also find a link to
 the online application and details for submitting.

 Applications for applying for travel assistance are now being accepted, and
 will close on the 7th July 2010.

 Good luck to all those that will apply.

 You are welcome to tweet, blog as appropriate.

 Regards,

 The Travel Assistance Committee.



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Release BSF 3.1 ?

[sebb]

On 18/05/2010, Brett Randall  wrote:
> +1.
>
>  My only hesitation is that work was done to try and get the Maven+Gump
>  build passing, but we still have that issue with the odd dependency
>  bsf-all:jar.  I thought we were pretty close to fixing that - should I
>  look into it again?

By all means - I could not work out why Gump does not find the dependency.
It works fine on Hudson and on my WinXP box.

I think any changes will be in the Gump descriptors which won't affect
the release.
But even if changes are needed to the BSF build files in order to
support Gump, I don't think that's a release blocker, as the code
builds and tests fine without Gump.

>  If the Maven build is clean it should make
>  deploying the artifacts to Maven Central easier.

I think I have fixed the Maven Deploy.
I am just tidying up some loose ends, and will call for a vote shortly.

>
>  Brett
>
>
>  On Sat, May 15, 2010 at 2:42 AM, sebb  wrote:
>  > There have been a few changes to the BSF 3.x code line since 3.0.
>  >
>  > I think it would be good to release version 3.1 along with its Maven 
> version.
>  >
>  > I've asked for Nexus access for BSF 3.x, so I propose to use that for
>  > staging/voting on the Maven artifacts.
>  >
>  > I'm happy to manage the release, unless anyone else wants to do it.
>  >
>  > Comments?
>  >
>
> > -
>  > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  > For additional commands, e-mail: dev-h...@jakarta.apache.org
>  >
>  >
>
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Export Control Question re: BSF

[sebb]

Have you seen

http://www.apache.org/licenses/exports/

On 18/05/2010, Erin Clark  wrote:
> Hi All:
>
>
>
>  I'm not sure to contact, so forgive me, but I'm assisting a client with
>  the export classification of their product and the subject product
>  utilizes Apache Jakarta Bean Scripting Framework v.2.4.0.  Do you know
>  who might be the correct developer(s) for this open source code?  If
>  it's you all, do you happen to know what the Export Control
>  Classification Number (ECCN) for this code?  If you don't know the ECCN,
>  can you please respond to the following questions at your convenience?
>
>
>
>  a. Does the code perform cryptographic functions (i.e.,
>  encryption/decryption)?
>
>  b.Does the code contain any cryptographic algorithms (i.e., 3DES,
>  Diffie-Helman, Blowfish, Rijndael, RC4, RSA) (whether or not these
>  algorithms are actually being used by the software)?
>
>  c. Is the code capable of interfacing with, calling to, using,
>  invoking or enabling/disabling the cryptographic features within other
>  software or within the underlying platform in any way?
>
>  d.Is the code capable of performing message digesting/hashing (i.e.,
>  MD5, RIPEMD, SHA, Tiger), fixed data compression or authentication?
>
>  e. Does the code contain/utilize and open cryptographic interface
>  (OCI), where the cryptographic capabilities of the code are
>  user-accessible and/or modifiable?  (See below for a more detailed
>  definition of OCI.)
>
>
>
>  If 'yes' to any of the above, please provide detailed response.
>
>  (Open cryptographic interface - A mechanism which is designed to allow a
>  customer or other party to insert cryptographic functionality without
>  the intervention, help or assistance of the manufacturer or its agents
>  (i.e., manufacturer's signing of cryptographic code or proprietary
>  interfaces). If the cryptographic interface implements a fixed set of
>  cryptographic algorithms, key lengths or key exchange management
>  systems, that cannot be changed, it will not be considered an "open"
>  cryptographic interface. All general application programming interfaces
>  (i.e., those that accept either a cryptographic or non-cryptographic
>  interface, but do not themselves maintain any cryptographic
>  functionality) will not be considered "open" cryptographic interfaces
>  either.)
>
>  Please let me know if you have any questions for me and many thanks in
>  advance for your assistance.
>
>
>
>  Regards,
>
>  Erin
>
>
>
>  Erin Clark
>
>  Export Compliance Manager
>
>  
>
>  Sandler & Travis Trade Advisory Services, Inc.
>
>
>
>  |phone  248.699.1588 | cell  619.997.4197 | fax 619.330.2336 | Web
>    trade.com/>  | eMail   |
>
>
>
>  This is a transmission from Sandler & Travis Trade Advisory Services,
>  Inc. and is solely for the use of the intended addressee. It may contain
>  information which is confidential and subject to attorney client
>  privilege.  If you are not the intended recipient, please e-mail the
>  sender and destroy all copies of this message and any attachment.  Any
>  unauthorized use of the contents of the message or attachments is
>  strictly prohibited.
>
>
>
>  P PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[VOTE] Release BSF 3.1

[sebb]

Please review and vote on the BSF 3.1 release.

The artifacts are available at:

http://people.apache.org/~sebb/bsf-3.1-RC1/

The Maven artifacts are at:

https://repository.apache.org/content/repositories/orgapachebsf-001/

The SVN tag is at:

http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC1

This will be renamed following a successful vote.

Keys are here:
http://www.apache.org/dist/jakarta/bsf/KEYS

Vote will remain open for at least 72 hours.

[ ] +1 I support this release.
[ ] -1 I am against releasing the packages (must include a reason).

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release BSF 3.1

[sebb]

On 18/05/2010, Jörg Schaible  wrote:
> sebb wrote:
>
>  > On 18/05/2010, Jörg Schaible  wrote:
>
>  [snip]
>
>
> >> Yes, if I add this, the build runs through. However, you're aware that
>  >> the
>  >>  usage of repositories within the POMs is strongly discouraged and IIRC
>  >>  will no longer work in M3?
>  >
>  > No, I was not aware of that.
>  >
>  > How are such dependencies supposed to be managed then?
>
>
> The problem is that in a company environment you want normally to control
>  the accessed remote resources (or with a repo manager like Nexus) and with
>  such repository declarations arbitrary locations are added.
>  http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-
>  poms-is-a-bad-idea/

I've read the article, and I don't think it applies here, because:
- it only affects one test project
- the test projects are not uploaded to Maven.

So I think the best is to re-instate the repo reference.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BSF3] Drop bsf-engines from release?

[sebb]

Following on from https://issues.apache.org/jira/browse/BSF-32:

I'm not sure it really makes sense to include a single jar with all
the BSF engine factories in it.

For one thing, why would one want so many factories present?
They will only work if the corresponding engine jar is also present,
so most of the factories will fail at run-time.

Another problem is the possibility of clashes between factories for
different versions of a scripting language.

The BSF3 code is still useful for Java 1.4 and Java 1.5, and the
bsf-utils jar can be used with Java 1.6+ as well.

==

I'm also not sure that the specific engine test cases add much value -
any failures I've seen are nothing to do with the BSF api code itself,
but all about how the test classpath is set up.

I think one could keep one or two of the test modules only.
These should probably depend directly on the specific engine factory
rather than on the bsf-engine bundle.

Thoughts?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [BSF3] Drop bsf-engines from release?

[sebb]

On 19/05/2010, Rony G. Flatscher  wrote:
> On 19.05.2010 17:18, sebb wrote:
>  > Following on from https://issues.apache.org/jira/browse/BSF-32:
>  >
>  > I'm not sure it really makes sense to include a single jar with all
>  > the BSF engine factories in it.
>  >
>  > For one thing, why would one want so many factories present?
>  >
>
> To be "future safe", such that one scripting language is used, but
>  later, one may want to try out another one concurrently without a need
>  for a JSR-223 engine being available for that scripting language
>  (because one must use an older version for whatever reason).

The factories are useless without the engines, so I don't think BSF helps here.

Note that bsf-engines.jar is badly named - it contains engine
factories only, not engines.

>  OTOH, Java 6 is around for a couple of years already and therefore most
>  of the maintained Java-related scripting languages would probably supply
>  a JSR-223 engine in their distribution already. If the bsf-engine bundle
>  and/or the individual JSR-223 engines remain downloadable separately
>  from BSF-3, then there should be no problem whatsoever.

Yes, the code for each factory (and each engine) is separately
available (outside the ASF).

>
>  > They will only work if the corresponding engine jar is also present,
>  > so most of the factories will fail at run-time.
>  >
>  > Another problem is the possibility of clashes between factories for
>  > different versions of a scripting language.
>  >
>
> This seems to be some sort of a show-stopper currently.

AFAICT it's only a showstopper because of bsf-engines.jar.

And the same problem applies to Java 1.6 when used with
bsf-engines.jar, because bsf-api by design implements the
javax.scripting API which is now in Java 1.6.

>  (Actually it should not be a show-stopper but be able to deal with
>  different engine versions, but with the same name. Then one could query
>  the engine what capabilities it has and pick the more powerful/more
>  versatile or the latest one.)

I agree that the selection criteria are not ideal, but that is what
the JSR-223 API currently mandates.
JSR-223 does not allow one to select by engine version, only by
extension, mime-type and name.

One can get the full list of engines, and it would be possible to put
some code in bsf-utils to make use of that to provide version-specific
engine selection. But that is outside the scope of JSR-223, and would
not be a "standard" API.

In the meantime, one just has to ensure that the factories that are
available on the classpath don't contain incompatible engines.

>
>  > The BSF3 code is still useful for Java 1.4 and Java 1.5, and the
>  > bsf-utils jar can be used with Java 1.6+ as well.
>  >
>  > ==
>  >
>  > I'm also not sure that the specific engine test cases add much value -
>  > any failures I've seen are nothing to do with the BSF api code itself,
>  > but all about how the test classpath is set up.
>  >
>  > I think one could keep one or two of the test modules only.
>  > These should probably depend directly on the specific engine factory
>  > rather than on the bsf-engine bundle.
>  >
>
> +1
>  > Thoughts?
>  >
>  I think it would be o.k. to leave the bsf-engine bundle out of the BSF3
>  distribution, but allow the bundle and the individual JSR-223 engines to
>  be downloaded separately, such that older versions of those scripting
>  engines that have no JSR-223 engine on their own can still be deployed
>  with BSF3.

My point is that the factories (and engines) all originate outside the ASF.
The engine bundle is an aggregation of some of the available engines factories.
[It's badly named too, as the engines are not included!]

So I think the bundle just complicates the build, without offering any benefit.

>  Reasoning: quite a few commercial deployments will have to live with the
>  company's politics regarding upgrading software and versions to be
>  deployed, such that this scenario will materialize one way or the other
>  (never change a running software/configuration). For them being able to
>  get bsf-engine bundle (or the individual engine) will help a lot, if
>  they wish to use JSR-223 scripting on pre-Java-6 installations.

I think the engine (factory) bundle will be just as much a nuisance
for commercial deployments, because of the problem of version clashes.

And commercial deployments still have to go elsewhere for the actual
engines, without which the factories jar is useless.

>  ---rony
>
>
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release BSF 3.1

[sebb]

Note some issues have been raised which make it prudent to do another RC.

However, it would be very helpful if someone could have a look at the
Maven artifacts to see if there are any packaging problems, so these
can be fixed before the next RC.

Equally, if there are bugs in the code, please say so now - thanks!


On 18/05/2010, sebb  wrote:
> Please review and vote on the BSF 3.1 release.
>
>  The artifacts are available at:
>
>  http://people.apache.org/~sebb/bsf-3.1-RC1/
>
>  The Maven artifacts are at:
>
>  https://repository.apache.org/content/repositories/orgapachebsf-001/
>
>  The SVN tag is at:
>
>  http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC1
>
>  This will be renamed following a successful vote.
>
>  Keys are here:
>  http://www.apache.org/dist/jakarta/bsf/KEYS
>
>  Vote will remain open for at least 72 hours.
>
>  [ ] +1 I support this release.
>  [ ] -1 I am against releasing the packages (must include a reason).
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BSF3] [VOTE] Drop bsf-engines.jar from release

[sebb]

I'd like to call a formal vote on dropping the bsf-engines.jar from
BSF3 releases.

The reasons for this are:
- it's not possible to selectively include just the factories one
wants. This can cause a clash with other factories that may be
required.
- the jar is just a repackaging of factories from a 3rd party. It does
not add any code.
- the user must still download the engine separately.
- some of the factories require additional classes to be present
otherwise Java 1.6 fails to register *any* factories.
- many engines now come with their own factories (and that is the way forward)

[Note that previous releases of bsf-engines.jar will of course
continue to be available from the archives.]

Please vote:

[ ] +1, OK, drop bsf-engines.jar from future releases
[ ] -1, No, keep the engines (must provide a reason)

Vote will remain open for at least 72 hours.

Thanks for your attention.

S///

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [BSF3] [VOTE] Drop bsf-engines.jar from release

[sebb]

Here's mine:

+1

On 22/05/2010, Rony G. Flatscher  wrote:
> +1
>
>
>  ---rony
>
>
>  On 22.05.2010 13:17, sebb wrote:
>  > I'd like to call a formal vote on dropping the bsf-engines.jar from
>  > BSF3 releases.
>  >
>  > The reasons for this are:
>  > - it's not possible to selectively include just the factories one
>  > wants. This can cause a clash with other factories that may be
>  > required.
>  > - the jar is just a repackaging of factories from a 3rd party. It does
>  > not add any code.
>  > - the user must still download the engine separately.
>  > - some of the factories require additional classes to be present
>  > otherwise Java 1.6 fails to register *any* factories.
>  > - many engines now come with their own factories (and that is the way 
> forward)
>  >
>  > [Note that previous releases of bsf-engines.jar will of course
>  > continue to be available from the archives.]
>  >
>  > Please vote:
>  >
>  > [ ] +1, OK, drop bsf-engines.jar from future releases
>  > [ ] -1, No, keep the engines (must provide a reason)
>  >
>  > Vote will remain open for at least 72 hours.
>  >
>  > Thanks for your attention.
>  >
>  > S///
>  >
>
> > -
>  > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  > For additional commands, e-mail: dev-h...@jakarta.apache.org
>  >
>  >
>
>
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BCEL] anyone working on BCEL ?

[sebb]

Is anyone working on - or wanting to work on - BCEL at present?

I know that Findbugs are keen to get away from using their patched version.

I can do some tidying up of test cases and basic warnings if that would help.

There seem to have been a lot of fixes since 5.2, so it would be good
to get a new release out.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [BCEL] anyone working on BCEL ?

[sebb]

On 25/05/2010, Torsten Curdt  wrote:
> > Is anyone working on - or wanting to work on - BCEL at present?
>
>
> Patch applying time is slowly approaching for me. But that's about it.
>
>
>  > I know that Findbugs are keen to get away from using their patched version.
>
>
> Well, we talked years ago. More than happy to accept patches from
>  them. IIRC last them they said they are too specific though ...so. Up
>  to them. But it would be great to work this out. A lot of wasted
>  effort otherwise.
>
>
>  > I can do some tidying up of test cases and basic warnings if that would 
> help.
>
>
> All contributions are welcome :)
>

I've done a bit of tidying up of licences and a few Eclipse warnings etc.

Unfortunately the code is infested with tabs.
I've not done anything about that yet, because it's only cosmetic, and
would make older patches (if there are any) harder to apply.

>  > There seem to have been a lot of fixes since 5.2, so it would be good
>  > to get a new release out.
>
>
> I think the one thing *really* missing for a new release are people testing 
> it.
>  Big changes since last release.

Also unit tests - there don't seem to be many for such a large codebase.

The test cases already require Java 1.5, but the main code currently
requires only Java 1.4.
Probably should consider updating that to 1.5 at some point. It will
require a good deal of work to fix all the raw types etc., but doing
that should make the code safer.

Another item to consider at some point is whether to try and make the
code thread-safe.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BSF3] [VOTE] [RESULT] Drop bsf-engines.jar from release

[sebb]

Thanks very much to all who voted.

The votes were as follows:

+1 (* = Jakarta PMC => binding)
Sanjiva Weerawarana (*)
Rony G. Flatscher (*)
Sebastian Bazley (*)
Sanka Samaranayake

No other votes were received

Therefore the vote passes.

Note: I will create an SVN tag of the current BSF3 code before
removing the bsf engine build etc.

-- Forwarded message --
From: sebb 
Date: 22 May 2010 12:17
Subject: [BSF3] [VOTE] Drop bsf-engines.jar from release
To: dev@jakarta.apache.org


I'd like to call a formal vote on dropping the bsf-engines.jar from
 BSF3 releases.

 The reasons for this are:
 - it's not possible to selectively include just the factories one
 wants. This can cause a clash with other factories that may be
 required.
 - the jar is just a repackaging of factories from a 3rd party. It does
 not add any code.
 - the user must still download the engine separately.
 - some of the factories require additional classes to be present
 otherwise Java 1.6 fails to register *any* factories.
 - many engines now come with their own factories (and that is the way forward)

 [Note that previous releases of bsf-engines.jar will of course
 continue to be available from the archives.]

 Please vote:

 [ ] +1, OK, drop bsf-engines.jar from future releases
 [ ] -1, No, keep the engines (must provide a reason)

 Vote will remain open for at least 72 hours.

 Thanks for your attention.


 S///

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [BCEL] anyone working on BCEL ?

[sebb]

On 25/05/2010, David Brosius  wrote:
> >> The test cases already require Java 1.5, but the main code currently
>  requires only Java 1.4.
>  Probably should consider updating that to 1.5 at some point. It will
>  require a good deal of work to fix all the raw types etc., but doing
>  that should make the code safer.
>
>
> Again, 5.2 requires jdk 1.3.

The current POM (5.3-SNAPSHOT) requires 1.4.
Dunno when this was changed.

>  i'm fine with bumping this up, but it's
>  unclear to me if there are any apache processes needed to be followed to
>  change this requirement, or whether we are free to just do it.

It can certainly be changed. Might be an idea to vote on it just in case.

Not sure that Jakarta has a documented policy for what changes can be
introduced in each type of release (major, minor, point).

Minor releases must normally be drop-in replacements, at least API-wise.

Changing minimum JVM release is a bit trickier - AFAIK, some PMCs
allow this in a minor release.

If there is any doubt, the next release could be 6.0 (there's quite a
few other changes anyway).

>
>  >> Another item to consider at some point is whether to try and make the
>  code thread-safe.
>
>
> I would strongly recommend against doing that. I don't believe it's a
>  parsing library's job to provide this, as it tends to usually be a single
>  threaded activity.

However, the code at the moment is not only not thread-safe, AFAICT it
is thread-hostile.
There are quite a few mutable static fields which control the processing.

So the question should be: should the code be made thread-compatible,
so that different threads could use their own independent instances.
At present that is not possible as far as I can tell (except by using
different classloaders).

>
>
>  - Original Message -
>  From: "sebb" 
>  Sent: Tue, May 25, 2010 11:30
>  Subject:Re: [BCEL] anyone working on BCEL ?
>
>
>  On 25/05/2010, Torsten Curdt  wrote:
>  > > Is anyone working on - or wanting to work on - BCEL at present?
>  >
>  >
>  > Patch applying time is slowly approaching for me. But that's about it.
>  >
>  >
>  >  > I know that Findbugs are keen to get away from using their patched
>  version.
>  >
>  >
>  > Well, we talked years ago. More than happy to accept patches from
>  >  them. IIRC last them they said they are too specific though ...so. Up
>  >  to them. But it would be great to work this out. A lot of wasted
>  >  effort otherwise.
>  >
>  >
>  >  > I can do some tidying up of test cases and basic warnings if that
>  would help.
>  >
>  >
>  > All contributions are welcome :)
>  >
>
>  I've done a bit of tidying up of licences and a few Eclipse warnings etc.
>
>  Unfortunately the code is infested with tabs.
>  I've not done anything about that yet, because it's only cosmetic, and
>  would make older patches (if there are any) harder to apply.
>
>  >  > There seem to have been a lot of fixes since 5.2, so it would be good
>  >  > to get a new release out.
>  >
>  >
>  > I think the one thing *really* missing for a new release are people
>  testing it.
>  >  Big changes since last release.
>
>  Also unit tests - there don't seem to be many for such a large codebase.
>
>  The test cases already require Java 1.5, but the main code currently
>  requires only Java 1.4.
>  Probably should consider updating that to 1.5 at some point. It will
>  require a good deal of work to fix all the raw types etc., but doing
>  that should make the code safer.
>
>  Another item to consider at some point is whether to try and make the
>  code thread-safe.
>
>
> -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
>
>
>
> - End of original message -
>
>
>
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[VOTE] Release BSF 3.1 (based on RC2)

[sebb]

I've hopefully fixed all the problems reported with the previous RC1.

Please review and vote on the BSF 3.1 release.

The artifacts are available at:

http://people.apache.org/~sebb/bsf-3.1-RC2/

The Maven artifacts are at:

https://repository.apache.org/content/repositories/orgapachebsf-037/

The SVN tag is at:

http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC2

This will be renamed following a successful vote.

Keys are here:
http://www.apache.org/dist/jakarta/bsf/KEYS

Vote will remain open for at least 72 hours.

[ ] +1 I support this release.
[ ] -1 I am against releasing the packages (must include a reason).

Thanks in advance!

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[CANCELLED][VOTE] Release BSF 3.1 (based on RC2)

[sebb]

On 04/06/2010, sebb  wrote:
> I've hopefully fixed all the problems reported with the previous RC1.

Unfortunately I created a packaging problem, so the vote is cancelled.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r951636 - /jakarta/bsf/branches/bsf3.x/bsf-engines/build.xml

[sebb]

On 10/06/2010, Juergen Pill  wrote:
> Hello sebb,
>
>  I am flooded with tons of Jakarta e-mails, but do not know hpow to 
> unsubscribe to all of those lists. It seems an accident that I was enforced 
> added to those list.
>  In particular I do not know the e-mail address, that I am subscribed to 
> those lists, making it impossible to unsubscribe.
>
>  Do you have any hint for me?
>

Read the footer of any mails you don't want to get, and follow the instructions.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Documentation Need

[sebb]

On 11/06/2010, Hosni Romdhani  wrote:
>
>
>
>  Hello:
>
>
>  I am Hosni Romdhani, a Java/J2EE developper.
>  I am working on a project in which we will need to personalize or create a 
> new HTTP request creation in JMeter.

Why? What is it that the current code does not do?

> I got the source code of JMeter from your SVN link.

OK

> The matter is that field lost between all of this class.

No idea what you mean by the above statement.

> I am using eclipse and as the run is performed by Ant, I can't even debug to 
> see what is happening.

You can run JMeter directly in Eclipse - please see the "eclipse.readme" file.

>  That is what pushed me to ask if it is possible to get some description on 
> how the sourse code work. Especially for HTTP Request execution.

The main documentation is the source code itself.

There is also the user manual which explains how the samplers are used.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Release BSF 3.1 (based on RC3)

[sebb]

[Third time lucky?]

Please review and vote on the BSF 3.1 release.

The artifacts are available at:

http://people.apache.org/~sebb/bsf-3.1-RC3/

The Maven artifacts are at:

https://repository.apache.org/content/repositories/orgapachebsf-004/

The SVN tag is at:

http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3

This will be renamed following a successful vote.

Keys are here:
http://www.apache.org/dist/jakarta/bsf/KEYS

Vote will remain open for at least 72 hours.

[ ] +1 I support this release.
[ ] -1 I am against releasing the packages (must include a reason).

Thanks in advance!

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BSF][VOTE] Release BSF 3.1 (based on RC3)

[sebb]

[Resending because I left off the VOTE prefix, and the subject change
does not seem to be filtering down ...]

[Third time lucky?]

 Please review and vote on the BSF 3.1 release.

 The artifacts are available at:

 http://people.apache.org/~sebb/bsf-3.1-RC3/

 The Maven artifacts are at:

 https://repository.apache.org/content/repositories/orgapachebsf-004/

 The SVN tag is at:

 http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3

 This will be renamed following a successful vote.

 Keys are here:
 http://www.apache.org/dist/jakarta/bsf/KEYS

 Vote will remain open for at least 72 hours.

 [ ] +1 I support this release.
 [ ] -1 I am against releasing the packages (must include a reason).

 Thanks in advance!

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [BSF][VOTE] Release BSF 3.1 (based on RC3)

[sebb]

On 21/06/2010, sebb  wrote:
> [Resending because I left off the VOTE prefix, and the subject change
>  does not seem to be filtering down ...]
>
>
>  [Third time lucky?]
>
>   Please review and vote on the BSF 3.1 release.
>
>   The artifacts are available at:
>
>   http://people.apache.org/~sebb/bsf-3.1-RC3/
>
>   The Maven artifacts are at:
>
>   https://repository.apache.org/content/repositories/orgapachebsf-004/
>
>   The SVN tag is at:
>
>   http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3
>
>   This will be renamed following a successful vote.
>
>   Keys are here:
>   http://www.apache.org/dist/jakarta/bsf/KEYS
>
>   Vote will remain open for at least 72 hours.
>
>   [ ] +1 I support this release.
>   [ ] -1 I am against releasing the packages (must include a reason).
>
>   Thanks in advance!
>

+1 here is my vote

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[BSF][VOTE][RESULT] Release BSF 3.1 (based on RC3)

[sebb]

Thanks very much to all who voted.

Here are the results of the vote:

+1 (* = binding)

Dave Brosius

Andrey Pohilko
Rony Flatscher (*)
Phil Steitz (*)
Sebastian Bazley (*)
Luc Maisonobe
Jörg Schaible

There were no other votes.

As there are at least 3 binding +1 votes, and no -1 votes, the vote succeeds.

Note: the vote e-mail was resent [2] because the subject was incorrect
orginally [1]

All the binding votes were repeated on the second thread.

[1] http://markmail.org/message/6xycqbaifuetm3fm
[2] http://markmail.org/message/hhu7jybllj7q4yiw

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMeter plugin menu items

[sebb]

On 01/07/2010, Andrey Pohilko  wrote:
> Hi,
>
>  There's a lot of plugins in JMeter already and when user's trying to add
>  another sampler (or something) to test plan, he sees a long menu with items
>  sorted with seems no order. Actually it is ordered by reverse plugin load
>  order, but this makes no sense.
>
>  I believe that it is not usable, and menus must be sorted by visual label.
>  Then user will be able to find items easily.
>
>  What'd ya say?

This ought to be raised on the JMeter user list instead, please.

>  Best wishes,
>  Andrey Pohilko
>
>
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>  For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.4 based on RC3

[sebb]

On 9 July 2010 17:17, Derry, Stanton  wrote:
>
>
> 
>
> From: seb...@gmail.com on behalf of sebb AT ASF
> Sent: Thu 7/8/2010 4:10 PM
> To: dev@jakarta.apache.org; gene...@jakarta.apache.org
> Subject: [VOTE] Release JMeter 2.4 based on RC3
>
>
>
> Please can I have votes for the release of JMeter 2.4?
>
> Archives/hashes/sigs and RAT report:
>
> http://people.apache.org/~sebb/jmeter-2.4_RC3/dist
>
> MD5 hashes of archives for this vote:
>
> 01ac101b161643a77267baec99b3acfe *jakarta-jmeter-2.4.tgz
> 8b1e592d88523c9594560be3b497a6fd *jakarta-jmeter-2.4.zip
> c8176c116c6273d6ce75606992de24a5 *jakarta-jmeter-2.4_src.tgz
> 90d2645cac7b15323830d29d2aa16def *jakarta-jmeter-2.4_src.zip
>
> Site Docs are here:
>
> http://people.apache.org/~sebb/jmeter-2.4_RC3/docs
>
> Tag:
>
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_4_RC3 (r961953)
>
> Keys are here:
>
> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
> also
> http://www.apache.org/dist/jakarta/jmeter/KEYS
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 2.4 requires Java 1.5 or later.
>
> Note that there is a bug in Java on some Linux systems that manifests
> itself as the following error when running the test cases or JMeter itself:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
> This does not affect JMeter operation.
>
> All feedback (and votes!) welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0   OK, but
> [ x ] -1   I do not support this release (please indicate why)
>
> Doesn't include the Stepping ThreadGroup

The Stepping ThreadGroup is a 3rd-party extension which is not
included with JMeter.

>  The vote will remain open for at least 72 hours.
>
>  Note: If the vote passes, the intention is to release the archive
>  files and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> S///
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.4 based on RC3

[sebb]

On 9 July 2010 18:58, Derry, Stanton  wrote:
> Hi Sebb,
>
> Thought it had become part of the JMeter source, it was in a prior nightly 
> build I had pullled down.

Which nighly build?

JMeter was enhanced to make it *possible* to add 3rd party Thread
Groups by adding a jar to the appropriate directory.

But the only thread group currently included is the one that was
previously available.

> Stan
>
> ____
>
> From: sebb [mailto:seb...@gmail.com]
> Sent: Fri 7/9/2010 10:52 AM
> To: dev@jakarta.apache.org
> Cc: gene...@jakarta.apache.org
> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>
>
>
> On 9 July 2010 17:17, Derry, Stanton  wrote:
>>
>>
>> ____
>>
>> From: seb...@gmail.com on behalf of sebb AT ASF
>> Sent: Thu 7/8/2010 4:10 PM
>> To: dev@jakarta.apache.org; gene...@jakarta.apache.org
>> Subject: [VOTE] Release JMeter 2.4 based on RC3
>>
>>
>>
>> Please can I have votes for the release of JMeter 2.4?
>>
>> Archives/hashes/sigs and RAT report:
>>
>> http://people.apache.org/~sebb/jmeter-2.4_RC3/dist
>>
>> MD5 hashes of archives for this vote:
>>
>> 01ac101b161643a77267baec99b3acfe *jakarta-jmeter-2.4.tgz
>> 8b1e592d88523c9594560be3b497a6fd *jakarta-jmeter-2.4.zip
>> c8176c116c6273d6ce75606992de24a5 *jakarta-jmeter-2.4_src.tgz
>> 90d2645cac7b15323830d29d2aa16def *jakarta-jmeter-2.4_src.zip
>>
>> Site Docs are here:
>>
>> http://people.apache.org/~sebb/jmeter-2.4_RC3/docs
>>
>> Tag:
>>
>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_4_RC3 (r961953)
>>
>> Keys are here:
>>
>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>> also
>> http://www.apache.org/dist/jakarta/jmeter/KEYS
>>
>> N.B.
>> To download the dependencies: "ant download_jars"
>>
>> To create the jars and test JMeter: "ant package test".
>>
>> JMeter 2.4 requires Java 1.5 or later.
>>
>> Note that there is a bug in Java on some Linux systems that manifests
>> itself as the following error when running the test cases or JMeter itself:
>>
>>  [java] WARNING: Couldn't flush user prefs:
>>  java.util.prefs.BackingStoreException:
>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>
>> This does not affect JMeter operation.
>>
>> All feedback (and votes!) welcome.
>>
>> [  ] +1  I support this release
>> [  ] +0  I am OK with this release
>> [  ] -0   OK, but
>> [ x ] -1   I do not support this release (please indicate why)
>>
>> Doesn't include the Stepping ThreadGroup
>
> The Stepping ThreadGroup is a 3rd-party extension which is not
> included with JMeter.
>
>>  The vote will remain open for at least 72 hours.
>>
>>  Note: If the vote passes, the intention is to release the archive
>>  files and rename the RC tag as the release tag.
>>
>> Thanks in advance!
>>
>> S///
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.4 based on RC3

[sebb]

On 9 July 2010 20:35, Derry, Stanton  wrote:
> Hi Sebb,
>
> I don't have access to the system I installed it on at this time.  What 
> prompted me to download a nightly build in June'2010 was the comment "... 
> plugin available with JMeter 2.3.5 or later only (currently with the latest 
> nightly build)" on the 
> http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup page.

That comment is misleading; the plugin is only "usable" with the
nightly build as JMeter 2.3.4 and earlier did not have the appropriate
support.

BTW there is no JMeter 2.3.5; the next version of JMeter will be 2.4.

> stan
>
> 
>
> From: sebb [mailto:seb...@gmail.com]
> Sent: Fri 7/9/2010 11:12 AM
> To: dev@jakarta.apache.org
> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>
>
>
> On 9 July 2010 18:58, Derry, Stanton  wrote:
>> Hi Sebb,
>>
>> Thought it had become part of the JMeter source, it was in a prior nightly 
>> build I had pullled down.
>
> Which nighly build?
>
> JMeter was enhanced to make it *possible* to add 3rd party Thread
> Groups by adding a jar to the appropriate directory.
>
> But the only thread group currently included is the one that was
> previously available.
>
>> Stan
>>
>> 
>>
>> From: sebb [mailto:seb...@gmail.com]
>> Sent: Fri 7/9/2010 10:52 AM
>> To: dev@jakarta.apache.org
>> Cc: gene...@jakarta.apache.org
>> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>>
>>
>>
>> On 9 July 2010 17:17, Derry, Stanton  wrote:
>>>
>>>
>>> 
>>>
>>> From: seb...@gmail.com on behalf of sebb AT ASF
>>> Sent: Thu 7/8/2010 4:10 PM
>>> To: dev@jakarta.apache.org; gene...@jakarta.apache.org
>>> Subject: [VOTE] Release JMeter 2.4 based on RC3
>>>
>>>
>>>
>>> Please can I have votes for the release of JMeter 2.4?
>>>
>>> Archives/hashes/sigs and RAT report:
>>>
>>> http://people.apache.org/~sebb/jmeter-2.4_RC3/dist
>>>
>>> MD5 hashes of archives for this vote:
>>>
>>> 01ac101b161643a77267baec99b3acfe *jakarta-jmeter-2.4.tgz
>>> 8b1e592d88523c9594560be3b497a6fd *jakarta-jmeter-2.4.zip
>>> c8176c116c6273d6ce75606992de24a5 *jakarta-jmeter-2.4_src.tgz
>>> 90d2645cac7b15323830d29d2aa16def *jakarta-jmeter-2.4_src.zip
>>>
>>> Site Docs are here:
>>>
>>> http://people.apache.org/~sebb/jmeter-2.4_RC3/docs
>>>
>>> Tag:
>>>
>>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_4_RC3 (r961953)
>>>
>>> Keys are here:
>>>
>>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>>> also
>>> http://www.apache.org/dist/jakarta/jmeter/KEYS
>>>
>>> N.B.
>>> To download the dependencies: "ant download_jars"
>>>
>>> To create the jars and test JMeter: "ant package test".
>>>
>>> JMeter 2.4 requires Java 1.5 or later.
>>>
>>> Note that there is a bug in Java on some Linux systems that manifests
>>> itself as the following error when running the test cases or JMeter itself:
>>>
>>>  [java] WARNING: Couldn't flush user prefs:
>>>  java.util.prefs.BackingStoreException:
>>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>>
>>> This does not affect JMeter operation.
>>>
>>> All feedback (and votes!) welcome.
>>>
>>> [  ] +1  I support this release
>>> [  ] +0  I am OK with this release
>>> [  ] -0   OK, but
>>> [ x ] -1   I do not support this release (please indicate why)
>>>
>>> Doesn't include the Stepping ThreadGroup
>>
>> The Stepping ThreadGroup is a 3rd-party extension which is not
>> included with JMeter.
>>
>>>  The vote will remain open for at least 72 hours.
>>>
>>>  Note: If the vote passes, the intention is to release the archive
>>>  files and rename the RC tag as the release tag.
>>>
>>> Thanks in advance!
>>>
>>> S///
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>>>
>>> 

Re: [VOTE] Release JMeter 2.4 based on RC3

[sebb]

On 9 July 2010 22:40, Derry, Stanton  wrote:
> Hi Sebb,
>
> The nightly build I pulled down was jakarta-jmeter-r955958_bin.zip.  Looking 
> at the dates of the jar files I probably dropped the plugin jar file in the 
> ext directory.

Seems so.

> Would be a useful thread group to have as part of the release.

That's a different discussion.

Given that your -1 was not applicable, would you like to vote again on
the JMeter release please?

> Stan
>
> -----Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Friday, July 09, 2010 12:58 PM
> To: dev@jakarta.apache.org
> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>
> On 9 July 2010 20:35, Derry, Stanton  wrote:
>> Hi Sebb,
>>
>> I don't have access to the system I installed it on at this time.  What 
>> prompted me to download a nightly build in June'2010 was the comment "... 
>> plugin available with JMeter 2.3.5 or later only (currently with the latest 
>> nightly build)" on the 
>> http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup page.
>
> That comment is misleading; the plugin is only "usable" with the
> nightly build as JMeter 2.3.4 and earlier did not have the appropriate
> support.
>
> BTW there is no JMeter 2.3.5; the next version of JMeter will be 2.4.
>
>> stan
>>
>> 
>>
>> From: sebb [mailto:seb...@gmail.com]
>> Sent: Fri 7/9/2010 11:12 AM
>> To: dev@jakarta.apache.org
>> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>>
>>
>>
>> On 9 July 2010 18:58, Derry, Stanton  wrote:
>>> Hi Sebb,
>>>
>>> Thought it had become part of the JMeter source, it was in a prior nightly 
>>> build I had pullled down.
>>
>> Which nighly build?
>>
>> JMeter was enhanced to make it *possible* to add 3rd party Thread
>> Groups by adding a jar to the appropriate directory.
>>
>> But the only thread group currently included is the one that was
>> previously available.
>>
>>> Stan
>>>
>>> 
>>>
>>> From: sebb [mailto:seb...@gmail.com]
>>> Sent: Fri 7/9/2010 10:52 AM
>>> To: dev@jakarta.apache.org
>>> Cc: gene...@jakarta.apache.org
>>> Subject: Re: [VOTE] Release JMeter 2.4 based on RC3
>>>
>>>
>>>
>>> On 9 July 2010 17:17, Derry, Stanton  wrote:
>>>>
>>>>
>>>> 
>>>>
>>>> From: seb...@gmail.com on behalf of sebb AT ASF
>>>> Sent: Thu 7/8/2010 4:10 PM
>>>> To: dev@jakarta.apache.org; gene...@jakarta.apache.org
>>>> Subject: [VOTE] Release JMeter 2.4 based on RC3
>>>>
>>>>
>>>>
>>>> Please can I have votes for the release of JMeter 2.4?
>>>>
>>>> Archives/hashes/sigs and RAT report:
>>>>
>>>> http://people.apache.org/~sebb/jmeter-2.4_RC3/dist
>>>>
>>>> MD5 hashes of archives for this vote:
>>>>
>>>> 01ac101b161643a77267baec99b3acfe *jakarta-jmeter-2.4.tgz
>>>> 8b1e592d88523c9594560be3b497a6fd *jakarta-jmeter-2.4.zip
>>>> c8176c116c6273d6ce75606992de24a5 *jakarta-jmeter-2.4_src.tgz
>>>> 90d2645cac7b15323830d29d2aa16def *jakarta-jmeter-2.4_src.zip
>>>>
>>>> Site Docs are here:
>>>>
>>>> http://people.apache.org/~sebb/jmeter-2.4_RC3/docs
>>>>
>>>> Tag:
>>>>
>>>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_4_RC3 (r961953)
>>>>
>>>> Keys are here:
>>>>
>>>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>>>> also
>>>> http://www.apache.org/dist/jakarta/jmeter/KEYS
>>>>
>>>> N.B.
>>>> To download the dependencies: "ant download_jars"
>>>>
>>>> To create the jars and test JMeter: "ant package test".
>>>>
>>>> JMeter 2.4 requires Java 1.5 or later.
>>>>
>>>> Note that there is a bug in Java on some Linux systems that manifests
>>>> itself as the following error when running the test cases or JMeter itself:
>>>>
>>>>  [java] WARNING: Couldn't flush user prefs:
>>>>  java.util.prefs.BackingStoreException:
>>>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>>>
>>>

[VOTE][RESULT] Release JMeter 2.4 based on RC3

[sebb]

Thanks very much to all who voted. The votes were as follows:

(*) binding

+1

Peter Lin (*)
Andrey Pohilko
Sebastian Bazley (*)
Milamber
Derry, Stanton
Daniel F. Savarese (*)

There were no other votes, so the vote passes.

Sebastian

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Getting enough votes (was Re: Update of "JakartaBoardReport-current" ...)

[sebb]

On 14 July 2010 02:16, Rahul Akolkar  wrote:
> Moved to dev@ ...
>
> On Tue, Jul 13, 2010 at 8:38 PM, Apache Wiki  wrote:
>> Dear Wiki user,
>>
>> You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
>> change notification.
>>
>> The "JakartaBoardReport-current" page has been changed by SebastianBazley.
>> http://wiki.apache.org/jakarta/JakartaBoardReport-current?action=diff&rev1=5&rev2=6
>>
>> --
>>
>>
>>  === General ===
>>
>> + Getting enough votes from the Jakarta community is becoming a problem.
>>
> 
>
> I recollect having trouble getting enough votes at Jakarta 5+ years
> ago. Often, votes need nudges (Jakarta or not).
>
> What do you expect to achieve by highlighting this in a board report?

OK, will remove it.

>
> -Rahul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[ANNOUNCE] JMeter 2.4 is released

[sebb]

The Apache JMeter team announces the availability of Apache JMeter  2.4 r961953.

This is a new release which corrects a lot of bugs and adds many new features.

JMeter 2.4 requires Java 1.5 or later to run.

== All users are recommended to upgrade. ==

Apache JMeter is a Java application designed to test server applications.
It can be used to:
* generate test loads
* test functional behaviour
* measure performance.
It includes support for protocols such as HTTP(S), JDBC, JMS, FTP, and others.
It can also be extended with user-written code.

See http://jakarta.apache.org/jmeter/

The release can be downloaded from:

http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

When downloading, please verify signatures using the KEYS file.

Only the binary archive is needed to run JMeter - there is no need to
download the source archive.

However there are some optional libraries which are not included.
See the "Getting Started" page for details:
http://jakarta.apache.org/jmeter/usermanual/get-started.html

The list of changes since version 2.3.4 can be found at:

http://jakarta.apache.org/jmeter/changes.html

All users are recommended to upgrade to this release.

Enjoy!
The JMeter team

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMETER] HTTPSampler2

[sebb]

On 20 July 2010 17:26, Chris van Es  wrote:
> Hi, I've recently been looking through the jmeter source in an attempt to
> create a HTTP sampler for testing proxy servers. As a result I need to
> configure multiple proxies over the course of a test run rather than the
> current global proxy settings in a properties file as
> org.apache.jmeter.protocol.http.sampler.HTTPSampler2 uses. If I were to
> enhance HTTPSampler2 to allow overriding the properties file proxy
> configuration with GUI config, would anyone be interested a
> patch/enhancement submitted for this?

Not necessary with JMeter 2.4 - the proxy can be defined on the
sampler GUI itself.

> Cheers,
>
> Chris.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Apache Retreat in Hursley, UK - 17-19th September

[sebb]

From: Nick Burch 
To: retre...@apache.org
Reply-To: retre...@apache.org
Subject: Apache Retreat in Hursley, UK - 17-19th September

Hi All

Just a reminder that our next Apache Retreat will be in Hursley in the
UK, from the 17th - 19th September. That's a little over a month away
now!

If you're an Apache Committer, we'd like to invite you to come for the
whole weekend. We've booked Tipis to stay in(!), catering on-site,
we've conference facilities sorted for running a BarCamp both days,
we'll be doing lightning talks, socialising, hacking etc.

If you're a user of Apache software, we'd love for you to come along
in the day on the Saturday. We're running a BarCamp in the day, and
it'll be great chance to learn more about new Apache projects, how the
Apache Way leads us to develop software, as well as to talk about your
current projects.

More details on the event, and a link to the signup site are available
from the ApacheCon wiki:
       http://wiki.apache.org/apachecon/
(Signup is available now for the whole retreat, and he barcamp signup
will open on Monday)

Also, if funding would be an issue to stop you attending, then the
Travel Assistance Committee are accepting applications for assistance
to attend until Wednesday 11th. More details, and a link to the
applications site are available from:
       http://www.apache.org/travel/

Nick
(On behalf of the retreat organising committee)

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [jmeter] beanshell version ?

[sebb]

On 27 July 2010 11:03, nicolas de loof  wrote:
> Hi,
>
> I wonder what version of beanshell is used by jMeter (2.4) :
> the build script downloads bsh2.0b5.jar from beanshell.org, but according
> to http://www.beanshell.org/download.html the latest stable version is
> 2.0b4. Sounds like the build script uses some nightly-build...

AIUI 2.0b5 is just as valid as 2.0b4. However, the web-site has not
been updated.
Note that 2.0b5 is required in order to support JSR-223.

> Nicolas
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [jmeter] publish artifacts on central ?

[sebb]

On 26 July 2010 12:54, nicolas de loof  wrote:
> Hi,
>
> now that jMeter 2.4 is out, is there any plan to publish artifacts on
> central for maven users ?

No plans at present.

> I can help if you wish ...

There are no scripts to create the required Maven artifacts, so if you
want to provide those as patches via Bugzilla that would be helpful.

> Cheers,
> Nicolas
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Gump nags, from address

[sebb]

+1

On 17 August 2010 18:59, Rahul Akolkar  wrote:
> Like Commons now does for the new gump builds, I suggest we change the
> from address for all Jakarta nags to be "Gump ",
> rather than any individuals.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: cactus-reports.xsl is being generated with errors

[sebb]

2010/8/24 José Ricardo :
> Hi folks,
>
> I was following this article about generating XML and HTML report from my
> cactus tests:
> http://jakarta.apache.org/cactus/integration/integration_browser.html
> Unfortunately when I was try to generate one html report about my tests with
> any kind of failure. In my method where exist failure, the row remains out
> off formatting table  and my report shows the following error:

Please raise this issue on the Cactus User mailing list.

>
> java.lang.reflect.InvocationTargetException
>
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
>      at java.lang.reflect.Method.invoke(Method.java:585)
>
>      at
> org.apache.cactus.server.runner.ServletTestRunner.doGet_aroundBody0(ServletTestRunner.java:204)
>
>      at
> org.apache.cactus.server.runner.ServletTestRunner.doGet_aroundBody1$advice(ServletTestRunner.java:218)
>
>      at
> org.apache.cactus.server.runner.ServletTestRunner.doGet(ServletTestRunner.java:1)
>
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
>
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:734)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:391)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:908)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:458)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:226)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:127)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:116)
>
>      at
> oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
>
>      at
> oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:234)
>
>      at
> oracle.oc4j.network.ServerSocketAcceptHandler.access$700(ServerSocketAcceptHandler.java:29)
>
>      at
> oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:879)
>
>      at com.evermind[Oracle Containers for J2EE 10g (10.1.3.5.0)
> ].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
>
>      at java.lang.Thread.run(Thread.java:595)
>
> Caused by: java.lang.StackOverflowError
>
>      at java.util.HashMap.put(HashMap.java:425)
>
>      at java.util.HashSet.add(HashSet.java:194)
>
>      at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:336)
>
>      at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400)
>
>      at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:128)
>
>      at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400)
>
>      at
> org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java:394)
>
>      at
> org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java:248)
>
>      at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400)
>
>      at org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java:128)
>
> [...]
>
> Please... Does anybody can help me to solution this problem?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Mime types on icons (was: svn commit: r991327)

[sebb]

On 31 August 2010 23:17, Rahul Akolkar  wrote:
> On Tue, Aug 31, 2010 at 5:04 PM,   wrote:
>> Author: milamber
>> Date: Tue Aug 31 21:04:21 2010
>> New Revision: 991327
>>
>> URL: http://svn.apache.org/viewvc?rev=991327&view=rev
>> Log:
>> Add missing files
>> Bug 30563 - Thread Group should have a start next loop option on Sample Error
>>
>>
>> Modified:
>>    jakarta/jmeter/trunk/docs/images/screenshots/threadgroup.png
>>    jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup.png
>>    jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup2.png
>>
> 
>
> You can adjust your svn client auto-props to get the correct
> svn:mime-type properties on these additions (same comment for images
> added in r991333).

Huh?

These were changes to existing images, not new images, so the existing
properties still apply.

I cannot find any missing properties in SVN currently.

> For example, see (search for "image/"):
>
>  http://www.apache.org/dev/svn-eol-style.txt
>
> -Rahul
>
>
>> Modified: jakarta/jmeter/trunk/docs/images/screenshots/threadgroup.png
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/threadgroup.png?rev=991327&r1=991326&r2=991327&view=diff
>> ==
>> Binary files - no diff available.
>>
>> Modified: 
>> jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup.png
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup.png?rev=991327&r1=991326&r2=991327&view=diff
>> ==
>> Binary files - no diff available.
>>
>> Modified: 
>> jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup2.png
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/webtest/threadgroup2.png?rev=991327&r1=991326&r2=991327&view=diff
>> ==
>> Binary files - no diff available.
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Addon development: Add new element and extension of existing ones

[sebb]

On 27 August 2010 13:39, Jens Müller  wrote:
>
> Hello,
>
> using the addons.xml ant file I want to extend JMeter. I am able to override 
> existing implementations this way, but I see no way of adding new elements to 
> the "Edit, Add, Non test elements" Menu.

New elements should automatically appear if you code the classes correctly.

> Also, I don't know how to add strings to the resource properties files, as if 
> I add them into the addons directory, they are not compiled into the jar.

There's currently no way to merge property file entries.
However you don't have to use resource properties. You can also use
the TestBean interface which has a private property file.

> Thank you for any hints,
> Jens
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Extending JMeter: Shared Data Set

[sebb]

On 10 September 2010 17:20, Milamber  wrote:
> Hello,
>
> Your idea is good, and(but) needs a lot of works.
>
> Please note, you can do this with another way:
> 1/ use a JDBC sampler with a SQL SELECT on a database, around a Once
> only controller which start first in test
> 2/ and JMeter's function __V{}
> http://jakarta.apache.org/jmeter/usermanual/functions.html#__V
> to build dynamically variables name from SELECT results.
>
> This way is limited by JVM memory (all rows are store in memory by JDBC
> SELECT request), but for a small list (<10.000 rows) this is a good way.
>
> I wrote a french tutorial in 2 parts to do this.
> http://blog.milamberspace.net/index.php/2009/06/12/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-1-311.html
> http://blog.milamberspace.net/index.php/2009/06/13/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-2-317.html
> (sorry, it's in french, but some screen-shots shows the way)

I'm not sure that will work in client-server mode, because each server
will run the same JDBC query.

> Milamber
>
> Le 09/09/2010 12:05, Jens Müller a ecrit :
>> Hello,
>>
>> JMeter does not seem to include a test element that allows a string out of a 
>> list to be assinged to a variable, guaranteeing at most once semantics for 
>> all users, even in distributed mode. Meaning that every element of the list 
>> will only be used once, even trhoughout multiple test runs.
>>
>> I have the following in mind:
>> Creating a ConfigTestElement (currently a TestBean) which allows the user to 
>> add a list of values. When starting the test, this list would be put into a 
>> centrally accessible singleton and everytime a value would be read in 
>> iterationStart, it would be removed from this central list and assigned to a 
>> variable, similarly to CSV Data Set Config, only that the value is not read 
>> from a file.
>> So far possible.
>>
>> When the test is completed, only the remaining unused values should be 
>> present in the test element. How can I modify a specific element in the test 
>> tree? If I implement TestListener and change the list in testEnded, this 
>> change is not applied to the test element if I open it in the test plan. It 
>> is probably cloned, but even by overriding clone and keeping a reference to 
>> the original element, I cannot get the test element's values changes.
>>
>>
>> Furthermore, in distributed mode, I would need to split the list in equal 
>> parts to the different client hosts. This could be done somewhere in 
>> ClientJMeterEngine#Configure, not cloning the element, but taking a sublist 
>> of the complete list. The total number of hosts and the number of the 
>> current host would need to be known for this. These two values could be 
>> filled into some context in RemoteStart#doAction.
>>
>> Every host would then perform its test run and at the end, they would need 
>> to send back the sublist of unused items. As far as I understand, only the 
>> Listeners are wrapped with RemoteListenerWrapper so that they can transfer 
>> back information. Maybe the information which elements of the list were not 
>> used can be piggybacked somewhere on testEnded? The compund list of 
>> remaining items would then again need to be incorporated into the original 
>> test element - a problem I already described above.
>>
>> Any help in solving any of these sub tasks is very appreciated.
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Extending JMeter: Shared Data Set

[sebb]

On 9 September 2010 13:05, Jens Müller  wrote:
>
> Hello,
>
> JMeter does not seem to include a test element that allows a string out of a 
> list to be assinged to a variable, guaranteeing at most once semantics for 
> all users, even in distributed mode. Meaning that every element of the list 
> will only be used once, even trhoughout multiple test runs.
>
> I have the following in mind:
> Creating a ConfigTestElement (currently a TestBean) which allows the user to 
> add a list of values. When starting the test, this list would be put into a 
> centrally accessible singleton and everytime a value would be read in 
> iterationStart, it would be removed from this central list and assigned to a 
> variable, similarly to CSV Data Set Config, only that the value is not read 
> from a file.
> So far possible.

But it will require large amounts of memory.

> When the test is completed, only the remaining unused values should be 
> present in the test element. How can I modify a specific element in the test 
> tree? If I implement TestListener and change the list in testEnded, this 
> change is not applied to the test element if I open it in the test plan. It 
> is probably cloned, but even by overriding clone and keeping a reference to 
> the original element, I cannot get the test element's values changes.
>
>
> Furthermore, in distributed mode, I would need to split the list in equal 
> parts to the different client hosts. This could be done somewhere in 
> ClientJMeterEngine#Configure, not cloning the element, but taking a sublist 
> of the complete list. The total number of hosts and the number of the current 
> host would need to be known for this. These two values could be filled into 
> some context in RemoteStart#doAction.
>
> Every host would then perform its test run and at the end, they would need to 
> send back the sublist of unused items. As far as I understand, only the 
> Listeners are wrapped with RemoteListenerWrapper so that they can transfer 
> back information. Maybe the information which elements of the list were not 
> used can be piggybacked somewhere on testEnded? The compund list of remaining 
> items would then again need to be incorporated into the original test element 
> - a problem I already described above.
>
>
> Any help in solving any of these sub tasks is very appreciated.

It will be complicated to do this as you describe it.

The StringFromFile function has a feature which allows it to read from
multiple files.

This was created to solve a problem whereby we could only use an
account number once in a test.
So we created lots of files, each with a different subset of the valid numbers.
For each test, we made a note of which files had been used, and
updated the start and end numbers accordingly.

One way to do this in distributed mode might be to enhance CSV DataSet.
- add a starting line number, so it would skip that number of lines
when opening the file.
- log the finishing line number; this can be used for determining the
next test starting value.
- for multiple remote servers, you could also add an increment value,
so it would only read every Nth record.

Start and end line numbers for CSV Dataset might be useful anyway, and
should be easy to add. Likewise increment.

However I'm not sure how you get each server to start with a different line.
Perhaps JMeter could set a special property to the server number when
starting multiple server tests.

One could just edit the properties on each server, but that would be tedious.

You could play around with reading a database table, and use the
hostname as the key to the CSV start/increment/ending variables.

> Jens
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Contribution: Adding a function

[sebb]

On 21 September 2010 08:35, Jens Müller  wrote:
>
> Hi,
>
> I needed a new JMeter function to be able to access the name of the current 
> sampler from the Header Manager.
>
> I wanted to share it, maybe you can add it to the development branch:

Code additions are normally provided via the bug-tracking system, i.e. Bugzilla.

https://issues.apache.org/bugzilla/enter_bug.cgi?product=JMeter

If you create an enhancement request you can add the code to it as an
attachment.
If you do so, please include the standard AL header in the file.

Thanks!

> package org.apache.jmeter.functions;
>
> import java.util.Collection;
> import java.util.LinkedList;
> import java.util.List;
>
> import org.apache.jmeter.engine.util.CompoundVariable;
> import org.apache.jmeter.functions.AbstractFunction;
> import org.apache.jmeter.functions.InvalidVariableException;
> import org.apache.jmeter.samplers.SampleResult;
> import org.apache.jmeter.samplers.Sampler;
> import org.apache.jmeter.threads.JMeterContextService;
>
> /**
>  * Function to return the name of the current sampler.
>  */
> public class SamplerName extends AbstractFunction {
>
>     private static final String KEY = "__samplerName"; //$NON-NLS-1$
>
>     private static final List desc = new LinkedList();
>
>     /** {...@inheritdoc} */
>     @Override
>     public String execute(SampleResult previousResult, Sampler currentSampler)
>             throws InvalidVariableException {
>         return 
> JMeterContextService.getContext().getCurrentSampler().getName();
>     }
>
>     /** {...@inheritdoc} */
>     @Override
>     public void setParameters(Collection parameters)
>             throws InvalidVariableException {
>         checkParameterCount(parameters, 0, 0);
>     }
>
>     /** {...@inheritdoc} */
>     @Override
>     public String getReferenceKey() {
>         return KEY;
>     }
>
>     /** {...@inheritdoc} */
>     public List getArgumentDesc() {
>         return desc;
>     }
> }
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: New JMeter Skin

[sebb]

On 2 November 2010 20:10, Joe Rice  wrote:
> Hi,
>
> I have been an avid JMeter user / fan for years.  I would like to port
> JMeter from Swing to SWT (eclipse) to give it a fresh interface and also
> allow eclipse plugin support.  I also have a number of suggested
> improvements around managing load test runs, but first things first.  First
> step would be a port to Eclipse.
>
> I am setting up a Google Code project to accomplish this.  Before getting
> too far, I wanted to get feedback & acceptance from the community on this
> idea.  If there is anyone interested in helping, that would be awesome, too
> :-).
>
> thoughts?

JMeter is intended to be a pure Java application so that it runs on
any compliant JVM.
However SWT is not pure Java and is not supported on as many platforms
as Swing, so would not be acceptable for the JMeter project.

Likewise, JMeter is not currently tied to any IDE.
An optional Eclipse add-on would of course be OK.

> Thanks,
>
> Joe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1023592 - /jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java

[sebb]

On 18 October 2010 00:07, Milamber  wrote:

>  Hello,
>
> With last commit (r1023592) it's possible to add this behavior on Arguments
> Panel (in HTTP sampler and Java sampler):
> * When user double click in the table on a cell which has a String value,
> JMeter display a text box to edit the value.
>
> It's more user-friendly for a long parameter value (like SOAP parameter, or
> values from dev web framework (spring, struts, etc))
>
> But, this new functionality will remove the default behavior : actually a
> double click on cell allows inline editing (directly in cell). Now if you
> want a edit directly on cell, you must use F2 key.
>
>
I tried the patch, and it's still possible to edit the text by clicking in
the box - one does not have to use F2.


> I think that this text box functionality is good, and improve JMeter. What
> is your opinion ?
>

Yes, definitely better for editting larger amounts of data.
However, at present it's a bit confusing, as the pop-up accepts new lines,
but these are dropped when the value is saved.
For fields that don't allow multiple lines, it would be better if the popup
only displayed a single line

Also it might be useful if  acted as a cancel button.


> (I have attached the patch (only 1 new line) to ArgumentsPanel if you want
> test)
>
> Thanks
>
> Milamber
>
>
>
>  Original Message   Subject: svn commit: r1023592 -
> /jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java
>   Date:
> Sun, 17 Oct 2010 22:36:36 -  From: milam...@apache.org  Reply-To:
> dev@jakarta.apache.org  To: notificati...@jakarta.apache.org
>
>
> Author: milamber
> Date: Sun Oct 17 22:36:35 2010
> New Revision: 1023592
>
> URL: http://svn.apache.org/viewvc?rev=1023592&view=rev
> Log:
> Adding a new inner class to allow display a text box to edit cell content in 
> Jtable (futur use in ArgumentsPanel)
>
> Modified:
> 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java
>
> Modified: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java?rev=1023592&r1=1023591&r2=1023592&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java 
> (original)
> +++ 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/TextBoxDialoger.java 
> Sun Oct 17 22:36:35 2010
> @@ -86,8 +86,8 @@ public class TextBoxDialoger implements
>   * @param editable - allow to modify text
>   */
>  public TextBoxDialoger(String text, boolean editable) {
> -init(text);
>  this.editable = editable;
> +init(text);
>  }
>
>  private void init(String text) {
> @@ -191,5 +191,36 @@ public class TextBoxDialoger implements
>  }
>  }
>
> +/**
> + * Class to edit in a dialog box the cell's content
> + * when double (pressed) click on a table's cell which is editable
> + *
> + */
> +public static class TextBoxDoubleClickPressed extends MouseAdapter {
> +
> +private JTable table = null;
> +
> +public TextBoxDoubleClickPressed(JTable table) {
> +super();
> +this.table = table;
> +}
> +
> +@Override
> +public void mousePressed(MouseEvent e) {
> +if (e.getClickCount() == 2) { // double (pressed) click
> +TableModel tm = table.getModel();
> +Object value = tm.getValueAt(table.getSelectedRow(), 
> table.getSelectedColumn());
> +if (value instanceof String) {
> +if (table.getCellEditor() != null) {
> +table.getCellEditor().cancelCellEditing(); // in 
> main table (evt mousePressed because cell is editable)
> +}
> +TextBoxDialoger tbd = new 
> TextBoxDialoger(value.toString(), true);
> +tm.setValueAt(tbd.getTextBox(), table.getSelectedRow(), 
> table.getSelectedColumn());
> +} // else do nothing (cell isn't a string to edit)
> +}
> +}
> +
> +}
> +
>
>  }
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>

Re: svn commit: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/

[sebb]

a:23)
>     [java]     at junit.extensions.TestSetup.run(TestSetup.java:27)
>     [java]     at org.apache.jorphan.test.AllTests.main(AllTests.java:224)
>     [java] 2)
> testPostRequest_FormMultipart(org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer)junit.framework.AssertionFailedError:
> Expected type:multipart/form-data;
> boundary=---7d159c1302d0y0 & length: 421 in:
>     [java] Connection: close
>     [java] Content-Type: multipart/form-data;
> boundary=---7d159c1302d0y0
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkHeaderTypeLength(TestHTTPSamplersAgainstHttpMirrorServer.java:1012)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkPostRequestFormMultipart(TestHTTPSamplersAgainstHttpMirrorServer.java:735)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FormMultipart(TestHTTPSamplersAgainstHttpMirrorServer.java:270)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FormMultipart(TestHTTPSamplersAgainstHttpMirrorServer.java:114)
>     [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>     [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [java]     at
> junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>     [java]     at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>     [java]     at junit.extensions.TestSetup.run(TestSetup.java:27)
>     [java]     at org.apache.jorphan.test.AllTests.main(AllTests.java:224)
>     [java] 3)
> testPostRequest_FileUpload(org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer)junit.framework.AssertionFailedError:
> Expected type:multipart/form-data;
> boundary=---7d159c1302d0y0 & length: 713 in:
>     [java] Connection: close
>     [java] Content-Type: multipart/form-data;
> boundary=---7d159c1302d0y0
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkHeaderTypeLength(TestHTTPSamplersAgainstHttpMirrorServer.java:1012)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkPostRequestFileUpload(TestHTTPSamplersAgainstHttpMirrorServer.java:783)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FileUpload(TestHTTPSamplersAgainstHttpMirrorServer.java:369)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FileUpload(TestHTTPSamplersAgainstHttpMirrorServer.java:122)
>     [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>     [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [java]     at
> junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>     [java]     at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
>     [java]     at junit.extensions.TestSetup.run(TestSetup.java:27)
>     [java]     at org.apache.jorphan.test.AllTests.main(AllTests.java:224)
>     [java] 4)
> testPostRequest_BodyFromParameterValues(org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer)junit.framework.AssertionFailedError:
> Expected type:application/x-www-form-urlencoded & length: 20 in:
>     [java] Connection: close
>     [java] Content-Type: application/x-www-form-urlencoded
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkHeaderTypeLength(TestHTTPSamplersAgainstHttpMirrorServer.java:1012)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkPostRequestBody(TestHTTPSamplersAgainstHttpMirrorServer.java:816)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_BodyFromParameterValues(TestHTTPSamplersAgainstHttpMirrorServer.java:405)
>     [java]     at
> org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_BodyFromParameterValues(TestHTTPSamplersAgainstHttpMirrorServer.java:130)
>     [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>     [java]     at
> sun.reflect.NativeMethodAccessorImpl.

Re: svn commit: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/

[sebb]

On 3 November 2010 09:32, sebb  wrote:
> On 3 November 2010 08:03, Milamber  wrote:
>> Hello,
>>
>> When I use Ant script [tests] (on same project), I have the following
>> errors :
>>
>> * 1 error with jdk1.6_21
>> * 1 error + 4 failures with jdk1.6_22
>>
>> For the error, I think that must remove a slash in
>> test/src/org/apache/jmeter/services/TestFileServer.java
>> on this line : "infile=findTestPath("/testfiles/test.csv");"
>> to infile=findTestPath("testfiles/test.csv");
>
> Oops!
>
> No idea why this works on Windows.
>
>> For failures, I don't understand now (I don't really searching the root
>> cause)
>
> Me neither, but I will investigate.

Looks like the HTTP implementation has changed - it no longer seems to
send the Content-Length header with POST requests.

>
> I'm also updating the build script and test code so Hudson should
> catch failures better.
>
>> == JDK1.6 u21=
>>     [echo]
>>     [echo]    gump.run = false
>>     [echo]    java.awt.headless = ${java.awt.headless}
>>     [echo]    test.headless =
>>     [echo]    user.dir =
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>     [echo]    basedir =
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>     [echo]    test dir = build/test
>>     [echo]    test dir gump = build/test
>>     [echo]    testsaveservice.saveout = ${testsaveservice.saveout}
>>     [echo]
>>     [java] Setting JMeterHome:
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>     [java] Setting up logging props using file:
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>     [java] Using initializeProperties() from
>> org.apache.jmeter.util.JMeterUtils
>>     [java] Setting up initial properties using:
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>     [java] Initializing Properties:
>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>     [java] java.version=1.6.0_21
>>     [java] java.home=/home/milamber/opt/jdk1.6.0_21/jre
>>     [java]
>> user.dir=/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin
>>     [java] os.name=Linux
>>     [java] os.version=2.6.32-5-amd64
>>     [java] +++
>>     [java] java.awt.headless=
>>     [java] java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
>>     [java] 
>>     [java] Creating test suite
>>     [java] Scanning build/test for test cases
>>     [java] ClassFinder found: 87 TestCase classes
>>     [java] INFO: JMeterGUIComponent: skipping some tests
>> org.apache.jmeter.testbeans.gui.TestBeanGUI
>>     [java] Created: 87 tests including 8 suites
>>     [java] Starting test run, test count = 1999
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .
>>     [java] .

Re: svn commit: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/

[sebb]

On 3 November 2010 10:18, sebb  wrote:
> On 3 November 2010 09:32, sebb  wrote:
>> On 3 November 2010 08:03, Milamber  wrote:
>>> Hello,
>>>
>>> When I use Ant script [tests] (on same project), I have the following
>>> errors :
>>>
>>> * 1 error with jdk1.6_21
>>> * 1 error + 4 failures with jdk1.6_22
>>>
>>> For the error, I think that must remove a slash in
>>> test/src/org/apache/jmeter/services/TestFileServer.java
>>> on this line : "infile=findTestPath("/testfiles/test.csv");"
>>> to infile=findTestPath("testfiles/test.csv");
>>
>> Oops!
>>
>> No idea why this works on Windows.
>>
>>> For failures, I don't understand now (I don't really searching the root
>>> cause)
>>
>> Me neither, but I will investigate.
>
> Looks like the HTTP implementation has changed - it no longer seems to
> send the Content-Length header with POST requests.

Appears to be related to this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6996110

as setting "sun.net.http.allowRestrictedHeaders=true" allows the test
to complete successfully.

Unfortunately "sun.net.http.allowRestrictedHeaders" does not appear to
be documented anywhere yet apart from the bug report.

>>
>> I'm also updating the build script and test code so Hudson should
>> catch failures better.
>>
>>> == JDK1.6 u21=
>>>     [echo]
>>>     [echo]    gump.run = false
>>>     [echo]    java.awt.headless = ${java.awt.headless}
>>>     [echo]    test.headless =
>>>     [echo]    user.dir =
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>>     [echo]    basedir =
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>>     [echo]    test dir = build/test
>>>     [echo]    test dir gump = build/test
>>>     [echo]    testsaveservice.saveout = ${testsaveservice.saveout}
>>>     [echo]
>>>     [java] Setting JMeterHome:
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
>>>     [java] Setting up logging props using file:
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>>     [java] Using initializeProperties() from
>>> org.apache.jmeter.util.JMeterUtils
>>>     [java] Setting up initial properties using:
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>>     [java] Initializing Properties:
>>> /home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
>>>     [java] java.version=1.6.0_21
>>>     [java] java.home=/home/milamber/opt/jdk1.6.0_21/jre
>>>     [java]
>>> user.dir=/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin
>>>     [java] os.name=Linux
>>>     [java] os.version=2.6.32-5-amd64
>>>     [java] +++
>>>     [java] java.awt.headless=
>>>     [java] java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
>>>     [java] 
>>>     [java] Creating test suite
>>>     [java] Scanning build/test for test cases
>>>     [java] ClassFinder found: 87 TestCase classes
>>>     [java] INFO: JMeterGUIComponent: skipping some tests
>>> org.apache.jmeter.testbeans.gui.TestBeanGUI
>>>     [java] Created: 87 tests including 8 suites
>>>     [java] Starting test run, test count = 1999
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] .
>>>     [java] 

Re: svn commit: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/

[sebb]

On 3 November 2010 10:57, sebb  wrote:
> On 3 November 2010 10:18, sebb  wrote:
>> On 3 November 2010 09:32, sebb  wrote:
>>> On 3 November 2010 08:03, Milamber  wrote:
>>>> Hello,
>>>>
>>>> When I use Ant script [tests] (on same project), I have the following
>>>> errors :
>>>>
>>>> * 1 error with jdk1.6_21
>>>> * 1 error + 4 failures with jdk1.6_22
>>>>
>>>> For the error, I think that must remove a slash in
>>>> test/src/org/apache/jmeter/services/TestFileServer.java
>>>> on this line : "infile=findTestPath("/testfiles/test.csv");"
>>>> to infile=findTestPath("testfiles/test.csv");
>>>
>>> Oops!
>>>
>>> No idea why this works on Windows.
>>>
>>>> For failures, I don't understand now (I don't really searching the root
>>>> cause)
>>>
>>> Me neither, but I will investigate.
>>
>> Looks like the HTTP implementation has changed - it no longer seems to
>> send the Content-Length header with POST requests.

Not so - the length is sent as before.

It looks like the test case assumes that one can set Content-Length in
the header and then retrieve it.

I'm not sure what this achieves in the context of this test, so I
think the best would be to remove that check of the request header.
The mirrored content is checked later anyway.

> Appears to be related to this bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6996110
>
> as setting "sun.net.http.allowRestrictedHeaders=true" allows the test
> to complete successfully.
>
> Unfortunately "sun.net.http.allowRestrictedHeaders" does not appear to
> be documented anywhere yet apart from the bug report.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1036578 - /jakarta/jmeter/trunk/build.xml

[sebb]

On 18 November 2010 19:14,   wrote:
> Author: milamber
> Date: Thu Nov 18 19:14:25 2010
> New Revision: 1036578
>
> URL: http://svn.apache.org/viewvc?rev=1036578&view=rev
> Log:
> Update URL for get package list (javadoc generating)

Well spotted!

> Modified:
>    jakarta/jmeter/trunk/build.xml
>
> Modified: jakarta/jmeter/trunk/build.xml
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1036578&r1=1036577&r2=1036578&view=diff
> ==
> --- jakarta/jmeter/trunk/build.xml (original)
> +++ jakarta/jmeter/trunk/build.xml Thu Nov 18 19:14:25 2010
> @@ -1568,7 +1568,7 @@ run JMeter unless all the JMeter jars ar
>       packagenames="org.apache.jmeter.*,org.apache.jorphan.*"
>       excludepackagenames="org.apache.jorphan.timer">
>       
> -      http://java.sun.com/j2se/1.5.0/docs/api/"/>
> +      http://download.oracle.com/javase/1.5.0/docs/api/"/>
>     
>   
>
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1036752 - /jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java

[sebb]

On 19 November 2010 07:28,   wrote:
> Author: milamber
> Date: Fri Nov 19 07:28:51 2010
> New Revision: 1036752
>
> URL: http://svn.apache.org/viewvc?rev=1036752&view=rev
> Log:
> Seems to miss a close parenthesis

Thanks!

[Was using a different system to do the edit does not have a suitable
compiler. Thought I could do without!]

> Modified:
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java?rev=1036752&r1=1036751&r2=1036752&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
>  Fri Nov 19 07:28:51 2010
> @@ -439,7 +439,7 @@ public class HttpRequestHdr {
>                 // Set the file uploads
>                 sampler.setHTTPFiles(urlConfig.getHTTPFileArgs().asArray());
>             // used when postData is pure xml (eg. an xml-rpc call) or for PUT
> -            } else if (postData.trim().startsWith(" "PUT".equals(sampler.getMethod()) {
> +            } else if (postData.trim().startsWith(" "PUT".equals(sampler.getMethod())) {
>                 sampler.addNonEncodedArgument("", postData, "");
>             } else if (contentType == null || 
> contentType.startsWith(HTTPConstants.APPLICATION_X_WWW_FORM_URLENCODED) ){
>                 // It is the most common post request, with parameter name 
> and values
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] - Get the log file parameter from plugin code (non gui mode, -j option)

[sebb]

2010/11/18 Stéphane Hoblingre :
> Hi,
>
> Is there a way to retrieve the jtl file path/name specified as argument when
> running JMeter in non gui mode?
> I need it to implement non gui mode of our plugin:
> http://code.google.com/p/jmeter-plugins/wiki/PerfMon

AFAIK, no other samplers/visualisers need this information.
It's the Listener's job to save the samples.

So why does this code need it?

> Is it possible?

Probably, but why is it needed?

> Regards,
>
> Stephane
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] - Get the log file parameter from plugin code (non gui mode, -j option)

[sebb]

2010/11/22 Stéphane Hoblingre :
> Hi,

> In non gui mode, I create my own file to collect the metrics. My idea was to
> get the name of the jtl file and create another one with same path/name but
> different extension.
>
> It is not a big deal if I cannot get the jtl file name. the user can specify
> -JperfmonFile=/path/to/file.jppm it is enough.

If the data belongs in the jtl file, then just use the standard
listener to save the data.

If not, then the file name should probably be defined separately on the GUI.

Note that there may be multiple JTL files (possibly even none) in any test run.

> I'm sorry I have diverted from the JMeter model to implement this particular
> plugin...
>
> Regards,
>
> Stephane
>
>
>
> On Tue, Nov 23, 2010 at 12:14 AM, sebb  wrote:
>
>> 2010/11/18 Stéphane Hoblingre :
>> > Hi,
>> >
>> > Is there a way to retrieve the jtl file path/name specified as argument
>> when
>> > running JMeter in non gui mode?
>> > I need it to implement non gui mode of our plugin:
>> > http://code.google.com/p/jmeter-plugins/wiki/PerfMon
>>
>> AFAIK, no other samplers/visualisers need this information.
>> It's the Listener's job to save the samples.
>>
>> So why does this code need it?
>>
>> > Is it possible?
>>
>> Probably, but why is it needed?
>>
>> > Regards,
>> >
>> > Stephane
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[sebb]

On 25 November 2010 14:18, Peter Lynch  wrote:
> I am wondering if there is developer support for the idea of converting
> JMeter's build process to be based on Maven. If there is suitable support of
> this idea, I was going to start writing a conversion script that would
> convert the project sources while maintaining as much scm history as
> possible.

Should be possible to maintain all SCM history if done properly.

Note that changes of source layout will cause a (one-off) problem for
people who maintain private patches.

> I have outlined some of the advantages this offers in this enhancement
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50324
>
> 
> So what do the developers think?

Why do you want to build JMeter with Maven?

Is it just so that JMeter jars can be uploaded to Maven Central?
If so, then there are simpler ways to achieve this.

Is it so that you can run JMeter with Maven (assuming jars are in Central)?
If so, then potentially major changes are needed to JMeter, because
currently it maintains its own classpath, and expects to find jars in
specific locations.
For example, lib/ext is searched for JMeter components; lib is not.
Since JMeter has to do quite a lot of jar scanning, it is important
that this is efficient.

Note also that the Ant build does some work that may be tricky to
implement in Maven.
For example, the documentation is built twice - once for web-site, and
once for the dynamic help system.
The build also creates a lot of different jars.
My experience of multimodule Maven builds is that they can take a lot
longer than Ant, and are tricky to get working correctly.

I'm not saying that JMeter can't or won't use Maven for builds, but
it's not going to be at all easy to implement and maintain.
I know from my participation in Apache Commons that even simple
projects can spend quite a lot of time on Maven issues.

> -Peter
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[JMeter] HTTP Sampler consolidation of implementations

[sebb]

Just a heads up that I'm currently working on trying to combine the
HTTP implementations (Java, HttpClient3) into a single GUI, with
run-time choice of implementation.

The rationale for this is that HttpClient 4 is now available, and it
would be good to add that, but I think we should keep HttpClient for
backwards compatibility and comparison.

Creating another GUI/Sampler set is easy enough, but it would be
useful to be able to switch implementations easily - currently that
requires switching samplers (e.g. by editting the JMX file).

The current plan is to allow the implementation to be specified on the
HTTP Request Defaults config screen as well as on the HTTP Request
screen.

The code is a bit involved, because the Config settings are processed
at run-time after the test plan has been built.
[But even the Sampler GUI needs to create the sampler before it can
store the sampler settings - and the implementation can then be
changed.]
Currently I use a Sampler Proxy that dispatches to the appropriate
implementation class.
These classes have to extend an abstract class that provides the
necessary methods to interface with the Proxy test element and thus
provide access to the test element properties.
That part seems to be working OK.

The next phase is to ensure that existing JMX files can be converted
(during load) to use the new sampler.

The intention is to keep the existing Java and HttpClient samplers, so
that subclasses will continue to work, but not expose them in the GUI.

I've not  finally decided about the AJP sampler - it can be easily
converted, but I don't think there's much of a use case for switching
between AJP and another implementation.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[sebb]

On 25 November 2010 17:54, Peter Lynch  wrote:
> Hi sebb,
>
> On Thu, Nov 25, 2010 at 9:42 AM, sebb  wrote:
>
>> On 25 November 2010 14:18, Peter Lynch  wrote:
>> > I am wondering if there is developer support for the idea of converting
>> > JMeter's build process to be based on Maven. If there is suitable support
>> of
>> > this idea, I was going to start writing a conversion script that would
>> > convert the project sources while maintaining as much scm history as
>> > possible.
>>
>> Should be possible to maintain all SCM history if done properly.
>>
>> Note that changes of source layout will cause a (one-off) problem for
>> people who maintain private patches.
>>
>> > I have outlined some of the advantages this offers in this enhancement
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=50324
>> >
>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324>
>> > So what do the developers think?
>>
>> Why do you want to build JMeter with Maven?
>>
>>
> I'd like JMeter to be accessible to as many developers as possible. I'd like
> the source code layout to be more standardized, to be more accessible to
> Java developers who want to contribute to the project. I'd like to fix
> problems in JMeter source code by opening the project in any IDE that
> supports Maven project structures and know instantly how to run tests, build
> and deploy. I'd like the artifacts that JMeter produces to be in a format
> that can be more easily reused and referenced by other projects.
>
>
>> Is it just so that JMeter jars can be uploaded to Maven Central?
>> If so, then there are simpler ways to achieve this.
>>
>>
> No that is not the primary reason, see above. I am familiar with how to get
> jars on Central using various methods - I work at Sonatype afterall ;).
>
> Is it so that you can run JMeter with Maven (assuming jars are in Central)?
>
> If so, then potentially major changes are needed to JMeter, because
>> currently it maintains its own classpath, and expects to find jars in
>> specific locations.
>> For example, lib/ext is searched for JMeter components; lib is not.
>> Since JMeter has to do quite a lot of jar scanning, it is important
>> that this is efficient.
>>
>
> You bring up some good points but all of this is scope creep - it may come
> as an eventual side effect but that is not the main goal.

This is not scope creep - if the above mentioned issues are not
addressed, then JMeter either won't work or will be slowed down.

> It may turn out
> that during the conversion process there is some roadblock that would
> prevent Maven being useful - but I doubt it.

Well, the above need to be addressed for a start.

> I would suggest any changes
> converting to Maven brings affects mostly project structure, accessibility
> and maintainability over the long term.

The layout of SVN is not particularly important to me; that can be
changed to suit Maven and the Ant file modified to suit.

However, I do take issue with the proposition that converting to Maven
necessarily reduces maintenance.

>>
>> Note also that the Ant build does some work that may be tricky to
>> implement in Maven.
>> For example, the documentation is built twice - once for web-site, and
>> once for the dynamic help system.
>> The build also creates a lot of different jars.
>> My experience of multimodule Maven builds is that they can take a lot
>> longer than Ant, and are tricky to get working correctly.
>>
>> I'm not saying that JMeter can't or won't use Maven for builds, but
>> it's not going to be at all easy to implement and maintain.
>> I know from my participation in Apache Commons that even simple
>> projects can spend quite a lot of time on Maven issues.
>>
>>
> It sounds like you have some valuable experience to draw upon. That's great!

I'm the current release manager, and have been for several years.

> As long as there is not a defacto no to experimenting using Maven then I
> suggest to come up with a script first that does the conversion, and then
> discuss if the end result tradeoffs make JMeter a better project or not (...
> and if the changes the script applies should get committed).

Rejigging the source files to fit in with Maven is a one-off effort,
but before starting down this road, I think someone needs to show that
JMeter will actually run OK when the jars are stored in a Maven repo.

That should be possible to prove without needing to make any changes
to the JMeter source layout.
AIUI, it would just require copying the jars and basic POMs to a local
repo, and creating a POM that depends on the JMeter jars.

This work would not be wasted, as the POMs that are created will be
needed later in the Mavenisation of JMeter (assuming the experiment is
successful).

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 25 November 2010 23:13, Milamber  wrote:
> Hello,
>
> Your plan seems very well.
>
> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
> has three http samplers thus will introduce some confusing for a new
> user? (what http sampler is the best for my test?)

It will have to be documented.

In theory, HC4 will be the best, but it may take a while to get the
JMeter interface code working correctly.
So I did not want to replace HC3 with HC4.

Once it is well established, HC3 can be made optional, at which point
JMeter would revert to two choices again.

> (Actually, my understanding is the Java Http sampler is the legacy and
> reliable, and Hc3 is new challenger and is better for httpS request...)
>
> Another ask: what will be the default sampler?

Currently it is the Java sampler, but I plan to make it configurable
with a JMeter property.

> AJP sampler seems not very used like sampler. Keep his independence will
> be good for the evolution of federated http sampler.
>
> Milamber
>
> Le 25/11/2010 15:45, sebb a ecrit :
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not  finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[sebb]

On 26 November 2010 16:54, Phil Steitz  wrote:
> On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar wrote:
>
>> On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien 
>> wrote:
>> > On Nov 25, 2010, at 2:29 PM, Peter Lin  wrote:
>> >
>> >> even though I haven't been active in jmeter in a while, I am still a
>> >> jmeter committer.
>> >>
>> >
>> > Quantify "a while".
>> >
>> 
>>
>> No need, we have archives for the curious.
>>
>>
>> > I'm still a committee on various projects.   Would I veto a change by
>> someone with a defined need who shows initiative?   No.
>> >
>> > If Peter Lynch has the itch, why not let him experiment?   This place
>> works on initiative, not a series of subjective objections to a tool he
>> wishes to use.
>> >
>> > This place works only if people like yourself (like myself) get out of
>> the way of people more active than ourselves.
>> >
>> 
>>
>> All good above.
>>
>> Finally, the onus is on those who experiment to convince those who do
>> the work here that the proposed changes are then worthy.
>>
>> +1
>
> As one data point for a potential contributor, I will share the following.
> I have been lurking on this list for quite some time and intending to
> eventually propose some ideas/patches for enhancements.

We look forward to seeing these!

> Seeing this thread,
> i thought it would be a good idea to see how hard it was for me to get set
> up to build the code and run the tests.  The answer is it took me about 10
> minutes, which is frankly less time than most maven-built projects take to
> get going and *way less* than any nontrivial maven build.  I particularly
> like that there is a README as well as a building.html that clearly describe
> the simple steps necessary to get set up.  If you follow the directions to
> download the dependent jars and replace the Eclipse .classpath file with
> eclipse.classpath, Eclipse is fully set up.  I did not try to actually run
> anything from within Eclipse, as I find that is in general a bad idea for
> anything nontrivial;

Eclipse can easily be used for running and debugging JMeter, but
running some of the JUnit tests can be a bit of a pain as they need
the classpath to be set up correctly.

> but the nicely documented ant build.xml worked for me
> out of the box.  It was impressive to me that I did not have to fuss with
> any local property settings, given the amount of config that Jmeter and its
> tests use.
>
> [I did get the following test failure:
>
> [java] 1)
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
> serialization of org.apache.jmeter.functions.gui.FunctionHelper failed:
> java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI
>
> Looks Apple-specific.   I am running
>  java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)]

It does seem to be Apple-specific, though perhaps the field that holds
the GUI item could be made transient to avoid the problem.
The JMeter GUI does not need to be serialisable - only the test
element etc. that are required for running in client-server mode.
The FunctionHelper is GUI only, so could be dropped entirely from the
serialisation tests.

> Two of the ten minutes were spent fussing with Eclipse because I had
> replaced the classpath before downloading the jars.  Closing and reopening
> the project was not enough to get Eclipse to stop thinking the jars were
> "missing."  I had to recreate it after the jars were in place.  It might be
> better to change the instructions to remind people to download the jars
> before creating the Eclipse project.   I can submit a patch for that if
> others agree this is a good idea.

+1

> So I am personally finding it hard to believe that mavenizing the build is
> really going to make it easier for people to get involved with Jmeter.  If
> there are Jmeter artifacts of general usefulness, I think it would be a
> *good thing* to develop either Ant or Maven targets to get them published.
> That would be a much easier task than trying to get the full Jmeter build
> working in Maven.

+1

Seems to me to be a useful gain.

Is that something that can be easily done in Maven, using the current
directory layout and jar contents?

Patches welcome (via Bugzilla please).

> I agree strongly with Rahul and Peter Lin though that this decision belongs
> to them who do the work.

Thanks.

I'm not against Maven per se, but I have not seen it used on a project
with so many output jars and which makes assumptions about locations
of jars.

I may be wrong, but I can see no benefit to converting to a Maven
build, and there are several potential blockers which I (and others)
have already mentioned else-thread.

I can see no point in starting the process when it might not be
possible to achieve its goal.

So I don't intend personally to spend any time working on creating a
Maven build for JMeter.

> Phil
>
>
>
>
>
>> -Rahul
>>
>> 

Re: svn commit: r1039675 - /jakarta/jmeter/trunk/eclipse.readme

[sebb]

On 27 November 2010 13:13,   wrote:
> Author: milamber
> Date: Sat Nov 27 13:13:21 2010
> New Revision: 1039675
>
> URL: http://svn.apache.org/viewvc?rev=1039675&view=rev
> Log:
> typo

Well spotted!

> Modified:
>    jakarta/jmeter/trunk/eclipse.readme
>
> Modified: jakarta/jmeter/trunk/eclipse.readme
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/eclipse.readme?rev=1039675&r1=1039674&r2=1039675&view=diff
> ==
> --- jakarta/jmeter/trunk/eclipse.readme (original)
> +++ jakarta/jmeter/trunk/eclipse.readme Sat Nov 27 13:13:21 2010
> @@ -11,7 +11,7 @@ Eclipse.classpath
>
>  The file eclipse.classpath is intended as a starter .classpath file
>  for building JMeter using Eclipse version 3.  Make sure to execute
> -the ant download_jars task to downlaad and install the jars referred
> +the ant download_jars task to download and install the jars referred
>  to in the classpath before creating the Eclipse project.
>
>  Note that Eclipse does not handle RMI compilations,
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 2 December 2010 07:34, Milamber  wrote:
> Hello,
>
> I have tested your changes from svn. I have these issues:
> * on HTTP Proxy server, in HTTP Sampler settings section, Type combo
> list says "HTTP Request" and "HTTP Request HTTPClient". Does have not
> need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)

Good point; I'll fix that.

> * On HTTP Request and HTTP Request Defaults, Content encoding's white
> box disappears when you reduce the JMeter window's width. On my screen
> (1440x900), when I launch JMeter trunk, with the initial JMeter size, on
> the HTTP Request sampler, I don't see the white box of Content encoding
> (label still visible)
> (I thinks the problem is the FlowLayout in JPanel from UrlConfigGui)

Yes, I need to fix that too.

Previously, the "Web Server" section immediately above stopped this
happening, because it has a minimum size that is slightly larger than
was needed for the Protocol/Method/Encoding

The screen is already quite tall, so I did not want to add another line to it.

I can maybe shorten some of the labels as well - e.g. change "Protocol
(default http)" to "Protocol ([http])" - this should still be clear
enough.

> Milamber
>
>
> Le 26/11/2010 00:28, sebb a ecrit :
>> On 25 November 2010 23:13, Milamber  wrote:
>>
>>> Hello,
>>>
>>> Your plan seems very well.
>>>
>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>> has three http samplers thus will introduce some confusing for a new
>>> user? (what http sampler is the best for my test?)
>>>
>> It will have to be documented.
>>
>> In theory, HC4 will be the best, but it may take a while to get the
>> JMeter interface code working correctly.
>> So I did not want to replace HC3 with HC4.
>>
>> Once it is well established, HC3 can be made optional, at which point
>> JMeter would revert to two choices again.
>>
>>
>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>
>>> Another ask: what will be the default sampler?
>>>
>> Currently it is the Java sampler, but I plan to make it configurable
>> with a JMeter property.
>>
>>
>>> AJP sampler seems not very used like sampler. Keep his independence will
>>> be good for the evolution of federated http sampler.
>>>
>>> Milamber
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not  finally decided about the AJP sampler - it can be easily
>>>> converted, but 

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 2 December 2010 12:59, sebb  wrote:
> On 2 December 2010 07:34, Milamber  wrote:
>> Hello,
>>
>> I have tested your changes from svn. I have these issues:
>> * on HTTP Proxy server, in HTTP Sampler settings section, Type combo
>> list says "HTTP Request" and "HTTP Request HTTPClient". Does have not
>> need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)
>
> Good point; I'll fix that.

Done.

>> * On HTTP Request and HTTP Request Defaults, Content encoding's white
>> box disappears when you reduce the JMeter window's width. On my screen
>> (1440x900), when I launch JMeter trunk, with the initial JMeter size, on
>> the HTTP Request sampler, I don't see the white box of Content encoding
>> (label still visible)
>> (I thinks the problem is the FlowLayout in JPanel from UrlConfigGui)
>
> Yes, I need to fix that too.

Done.

Turned out to be quite easy - just needed to set the minimum size for the panel.

> Previously, the "Web Server" section immediately above stopped this
> happening, because it has a minimum size that is slightly larger than
> was needed for the Protocol/Method/Encoding
>
> The screen is already quite tall, so I did not want to add another line to it.
>
> I can maybe shorten some of the labels as well - e.g. change "Protocol
> (default http)" to "Protocol ([http])" - this should still be clear
> enough.

Done.

>> Milamber
>>
>>
>> Le 26/11/2010 00:28, sebb a ecrit :
>>> On 25 November 2010 23:13, Milamber  wrote:
>>>
>>>> Hello,
>>>>
>>>> Your plan seems very well.
>>>>
>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>> has three http samplers thus will introduce some confusing for a new
>>>> user? (what http sampler is the best for my test?)
>>>>
>>> It will have to be documented.
>>>
>>> In theory, HC4 will be the best, but it may take a while to get the
>>> JMeter interface code working correctly.
>>> So I did not want to replace HC3 with HC4.
>>>
>>> Once it is well established, HC3 can be made optional, at which point
>>> JMeter would revert to two choices again.
>>>
>>>
>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>
>>>> Another ask: what will be the default sampler?
>>>>
>>> Currently it is the Java sampler, but I plan to make it configurable
>>> with a JMeter property.
>>>
>>>
>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>> be good for the evolution of federated http sampler.
>>>>
>>>> Milamber
>>>>
>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>
>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>> run-time choice of implementation.
>>>>>
>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>> backwards compatibility and comparison.
>>>>>
>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>> useful to be able to switch implementations easily - currently that
>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>
>>>>> The current plan is to allow the implementation to be specified on the
>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>> screen.
>>>>>
>>>>> The code is a bit involved, because the Config settings are processed
>>>>> at run-time after the test plan has been built.
>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>> store the sampler settings - and the implementation can then be
>>>>> changed.]
>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>> implementation class.
>>>>> These classes have to extend an abstract class that provides the
>>>>> necessary methods to interface with the Proxy test element and thus
>>>>> provide access to the test elemen

Re: svn commit: r1041513 - /jakarta/jmeter/trunk/build.properties

[sebb]

Yes, my mistake. Now fixed I hope!

On 3 December 2010 07:30, Milamber  wrote:
> Hello,
>
> Not found?
>
> _get_jarfile:
>     [echo] Fetching: lib/httpclient-4.1-beta1.jar
>      [get] Getting:
> http://repo2.maven.org/maven2/org/apache/httpcomponents/httpcomponents-client/httpclient-4.1-beta1.jar
>      [get] To:
> /home/milamber/W-workspaces/Workspaces-JMeter/Jmeter/build/httpclient-4.1-beta1.jar
>      [get] Error opening connection java.io.FileNotFoundException:
> http://repo2.maven.org/maven2/org/apache/httpcomponents/httpcomponents-client/httpclient-4.1-beta1.jar
>      [get] Error opening connection java.io.FileNotFoundException:
> http://repo2.maven.org/maven2/org/apache/httpcomponents/httpcomponents-client/httpclient-4.1-beta1.jar
>      [get] Error opening connection java.io.FileNotFoundException:
> http://repo2.maven.org/maven2/org/apache/httpcomponents/httpcomponents-client/httpclient-4.1-beta1.jar
>      [get] Can't get
> http://repo2.maven.org/maven2/org/apache/httpcomponents/httpcomponents-client/httpclient-4.1-beta1.jar
> to
> /home/milamber/W-workspaces/Workspaces-JMeter/Jmeter/build/httpclient-4.1-beta1.jar
>
>
> Milamber
>
> Le 02/12/2010 18:25, s...@apache.org a ecrit :
>> Author: sebb
>> Date: Thu Dec  2 18:25:15 2010
>> New Revision: 1041513
>>
>> URL: http://svn.apache.org/viewvc?rev=1041513&view=rev
>> Log:
>> Add HttpClient dependencies
>> TODO - update to non-beta version when available
>>
>> Modified:
>>     jakarta/jmeter/trunk/build.properties
>>
>> Modified: jakarta/jmeter/trunk/build.properties
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.properties?rev=1041513&r1=1041512&r2=1041513&view=diff
>> ==
>> --- jakarta/jmeter/trunk/build.properties (original)
>> +++ jakarta/jmeter/trunk/build.properties Thu Dec  2 18:25:15 2010
>> @@ -30,16 +30,18 @@
>>  # Note that all the jars (apart from velocity and the Geronimo API jars)
>>  # are contained in the JMeter binary release.
>>
>> +maven2.repo                 = http://repo2.maven.org/maven2
>> +
>>  apache-bsf.jar              = bsf-2.4.0.jar
>> -apache-bsf.loc              = http://repo2.maven.org/maven2/bsf/bsf/2.4.0
>> +apache-bsf.loc              = ${maven2.repo}/bsf/bsf/2.4.0
>>  apache-bsf.md5              = 16e82d858c648962fb5c959f21959039
>>
>>  apache-jsr223-api.jar       = bsf-api-3.1.jar
>> -apache-jsr223-api.loc       = 
>> http://repo2.maven.org/maven2/org/apache/bsf/bsf-api/3.1
>> +apache-jsr223-api.loc       = ${maven2.repo}/org/apache/bsf/bsf-api/3.1
>>  apache-jsr223-api.md5       = 147c6cb39f889f640036f096f8a4bf59
>>
>>  avalon-framework.jar        = avalon-framework-4.1.4.jar
>> -avalon-framework.loc        = 
>> http://repo1.maven.org/maven2/avalon-framework/avalon-framework/4.1.4
>> +avalon-framework.loc        = 
>> ${maven2.repo}/avalon-framework/avalon-framework/4.1.4
>>  avalon-framework.md5        = 2C5306A09B22BD06A78343C0B55D021F
>>
>>  beanshell.jar               = bsh-2.0b5.jar
>> @@ -48,61 +50,61 @@ beanshell.md5               = 02F7233691
>>
>>  # Bouncy Castle jars (compile and test only - not distributed)
>>  bcmail.jar                  = bcmail-jdk15-1.45.jar
>> -bcmail.loc                  = 
>> http://repo2.maven.org/maven2/org/bouncycastle/bcmail-jdk15/1.45
>> +bcmail.loc                  = 
>> ${maven2.repo}/org/bouncycastle/bcmail-jdk15/1.45
>>  bcmail.md5                  = 13321fc7eff7bcada7b4fedfb592025c
>>
>>  bcprov.jar                  = bcprov-jdk15-1.45.jar
>> -bcprov.loc                  = 
>> http://repo2.maven.org/maven2/org/bouncycastle/bcprov-jdk15/1.45
>> +bcprov.loc                  = 
>> ${maven2.repo}/org/bouncycastle/bcprov-jdk15/1.45
>>  bcprov.md5                  = 2062f8e3d15748443ea60a94b266371c
>>
>>  commons-codec.jar           = commons-codec-1.4.jar
>> -commons-codec.loc           = 
>> http://repo2.maven.org/maven2/commons-codec/commons-codec/1.4
>> +commons-codec.loc           = ${maven2.repo}/commons-codec/commons-codec/1.4
>>  commons-codec.md5           = 82B899580DA472BE37055DA949B731FA
>>
>>  commons-collections.jar     = commons-collections-3.2.1.jar
>> -commons-collections.loc     = 
>> http://repo2.maven.org/maven2/commons-collections/commons-collections/3.2.1
>> +commons-collections.loc     = 
>> ${maven2.repo}/commons-collections/commons-collections/3.2.1
>>  commons-collections.md5     = 13BC641AFD7FD95E09B260F69C1E4C91
>>
>&

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 6 December 2010 08:12, Milamber  wrote:
> Hello,
>
>>> Previously, the "Web Server" section immediately above stopped this
>>> happening, because it has a minimum size that is slightly larger than
>>> was needed for the Protocol/Method/Encoding
>>>
>>> The screen is already quite tall, so I did not want to add another line to 
>>> it.
>>>
>>> I can maybe shorten some of the labels as well - e.g. change "Protocol
>>> (default http)" to "Protocol ([http])" - this should still be clear
>>> enough.
>>>
>> Done.
>>
>
> Perhaps [http] is better than ([http]), more readable?

Good point, you're right - and it's shorter.

> Milamber
>
>>
>>>> Milamber
>>>>
>>>>
>>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>>
>>>>> On 25 November 2010 23:13, Milamber  wrote:
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Your plan seems very well.
>>>>>>
>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>>> has three http samplers thus will introduce some confusing for a new
>>>>>> user? (what http sampler is the best for my test?)
>>>>>>
>>>>>>
>>>>> It will have to be documented.
>>>>>
>>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>>> JMeter interface code working correctly.
>>>>> So I did not want to replace HC3 with HC4.
>>>>>
>>>>> Once it is well established, HC3 can be made optional, at which point
>>>>> JMeter would revert to two choices again.
>>>>>
>>>>>
>>>>>
>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>>
>>>>>> Another ask: what will be the default sampler?
>>>>>>
>>>>>>
>>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>>> with a JMeter property.
>>>>>
>>>>>
>>>>>
>>>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>>>> be good for the evolution of federated http sampler.
>>>>>>
>>>>>> Milamber
>>>>>>
>>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>>
>>>>>>
>>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>>> run-time choice of implementation.
>>>>>>>
>>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>>> backwards compatibility and comparison.
>>>>>>>
>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>>> useful to be able to switch implementations easily - currently that
>>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>>
>>>>>>> The current plan is to allow the implementation to be specified on the
>>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>>>> screen.
>>>>>>>
>>>>>>> The code is a bit involved, because the Config settings are processed
>>>>>>> at run-time after the test plan has been built.
>>>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>>>> store the sampler settings - and the implementation can then be
>>>>>>> changed.]
>>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>>>> implementation class.
>>>>>>> These classes have to extend an abstract class that provides the
>>>>>>> necessary methods to interface with the Proxy test element and thus
>>>>>>> provide access to the test element properties.
>&

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 6 December 2010 21:45, Milamber  wrote:
> Hello,
>
> I have got last checkout last JMeter SVN, and executed ant's task dist.
> With a simple test plan, I have this error with a new HTTP HC4 sampler:
>
> 2010/12/06 21:08:45 ERROR - jmeter.threads.JMeterThread: Error while
> processing sampler 'Page2' :
> org.apache.commons.lang.NotImplementedException: Code is not implemented
>        at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:43)
>        at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>        at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:970)
>        at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:956)
>        at
> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:369)
>        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:262)
>        at java.lang.Thread.run(Thread.java:662)
>
> Have I forgot something?

No - I've not yet finished working on the HC4 sampler.

> Milamber
>
>
>
> Le 06/12/2010 11:35, sebb a ecrit :
>>
>>>>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>>>>
>>>>>>
>>>>>>> On 25 November 2010 23:13, Milamber  wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Your plan seems very well.
>>>>>>>>
>>>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>>>>> has three http samplers thus will introduce some confusing for a new
>>>>>>>> user? (what http sampler is the best for my test?)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> It will have to be documented.
>>>>>>>
>>>>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>>>>> JMeter interface code working correctly.
>>>>>>> So I did not want to replace HC3 with HC4.
>>>>>>>
>>>>>>> Once it is well established, HC3 can be made optional, at which point
>>>>>>> JMeter would revert to two choices again.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>>>>
>>>>>>>> Another ask: what will be the default sampler?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>>>>> with a JMeter property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> AJP sampler seems not very used like sampler. Keep his independence 
>>>>>>>> will
>>>>>>>> be good for the evolution of federated http sampler.
>>>>>>>>
>>>>>>>> Milamber
>>>>>>>>
>>>>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>>>>> run-time choice of implementation.
>>>>>>>>>
>>>>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>>>>> backwards compatibility and comparison.
>>>>>>>>>
>>>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>>>>> useful to be able to switch implementations easily - currently that
>>>>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>>>>
>>>&g

Re: [Jakarta-jmeter Wiki] Update of "AdminGroup" by JMeterAdmin

[sebb]

On 30 December 2010 17:39, Antoine Levy-Lambert  wrote:
> Hi,
>
> I see that you guys are maintaining a page to prevent bad content.
> I do not know how to do it myself. I would need to do the same for Ant and
> Gump's wikis.

Just create the page "LocalBadContent".

> I was also wondering whether infra maintains a global bad content list for
> all the wikis ?

AFAIK there is no central bad content list.

There used to be one, but AIUI the code to handle it no longer worked
when the Wiki code was updated to a newer version.

> Antoine
>
> On 12/30/2010 10:24 AM, Apache Wiki wrote:
>>
>> Dear Wiki user,
>>
>> You have subscribed to a wiki page or wiki category on "Jakarta-jmeter
>> Wiki" for change notification.
>>
>> The "AdminGroup" page has been changed by JMeterAdmin.
>> http://wiki.apache.org/jakarta-jmeter/AdminGroup
>>
>> --
>>
>> New page:
>> This is a list of people who can do editing of the LocalBadContent page:
>>  * Upayavira
>>  * DanielQuinlan
>>  * JoeSchaefer
>>  * JMeterAdmin
>>
>> -
>> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: News link on Jakarta website

[sebb]

On 11 January 2011 09:25, Milamber  wrote:
> Hello,
>
> In Jakarta website, on right column at top, there is a http link to News
> with this url:
> http://jakarta.apache.org/site/news/index.html
>
> But this page (news/index.html) has only very old news. That is possible
> to change this link by (for example) this page?
> http://jakarta.apache.org/site/news/news-2010-q3.html
>
> (Or change news/index.html to a redirection to a recent news page)
>
> The link is in /site/xdocs/stylesheets/site.xml line 71

The main index (welcome) page does have the most recent news.

However, I agree that the News page needs to be updated.
As a Jakarta committer you should have sufficient karma to be able to
do this if you want. The instructions are at the bottom of the page.

If not, I may find time to do it one day ...

> Thanks
>
> Milamber
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1057347 - /jakarta/jmeter/trunk/build.xml

[sebb]

On 11 January 2011 17:40, Milamber  wrote:
> Hello,
>
> With fork=no, all test cases aren't execute when run ant tests (or
> distribution).

Thanks.

I'm looking into that now.

> Milamber
>
> Le 10/01/2011 20:28, s...@apache.org a ecrit :
>> Author: sebb
>> Date: Mon Jan 10 20:28:28 2011
>> New Revision: 1057347
>>
>> URL: http://svn.apache.org/viewvc?rev=1057347&view=rev
>> Log:
>> Try fork=no for fixing classpath issue with Gump tests
>>
>> Modified:
>>     jakarta/jmeter/trunk/build.xml
>>
>> Modified: jakarta/jmeter/trunk/build.xml
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1057347&r1=1057346&r2=1057347&view=diff
>> ==
>> --- jakarta/jmeter/trunk/build.xml (original)
>> +++ jakarta/jmeter/trunk/build.xml Mon Jan 10 20:28:28 2011
>> @@ -1859,7 +1859,8 @@ run JMeter unless all the JMeter jars ar
>>     
>>        
>>     
>> -   > failonerror="true" dir="${basedir}/bin">
>> +   
>> +   > failonerror="true" dir="${basedir}/bin">
>>        
>>          
>>          
>>
>>
>>
>> -
>> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1057347 - /jakarta/jmeter/trunk/build.xml

[sebb]

On 12 January 2011 09:20, sebb  wrote:
> On 11 January 2011 17:40, Milamber  wrote:
>> Hello,
>>
>> With fork=no, all test cases aren't execute when run ant tests (or
>> distribution).
>
> Thanks.
>
> I'm looking into that now.

The problem seems to be that the dir="${basedir}/bin" is silently
ignored when fork="no",.
This affects the classpath scanning.

I need to find a different way to fix the Gump builds.

>> Milamber
>>
>> Le 10/01/2011 20:28, s...@apache.org a ecrit :
>>> Author: sebb
>>> Date: Mon Jan 10 20:28:28 2011
>>> New Revision: 1057347
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1057347&view=rev
>>> Log:
>>> Try fork=no for fixing classpath issue with Gump tests
>>>
>>> Modified:
>>>     jakarta/jmeter/trunk/build.xml
>>>
>>> Modified: jakarta/jmeter/trunk/build.xml
>>> URL: 
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1057347&r1=1057346&r2=1057347&view=diff
>>> ==
>>> --- jakarta/jmeter/trunk/build.xml (original)
>>> +++ jakarta/jmeter/trunk/build.xml Mon Jan 10 20:28:28 2011
>>> @@ -1859,7 +1859,8 @@ run JMeter unless all the JMeter jars ar
>>>     
>>>        
>>>     
>>> -   >> failonerror="true" dir="${basedir}/bin">
>>> +   
>>> +   >> failonerror="true" dir="${basedir}/bin">
>>>        
>>>          
>>>          
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Small feature request - test start time stored in StandardJMeterEngine

[sebb]

2011/1/14 Stéphane Hoblingre :
> Hi,
>
> I'm committer in JMeter Plugins project (
> http://code.google.com/p/jmeter-plugins/) and would like to add in our
> charts relative time. For this, I need to get the test start time. Could it
> be possible to store this value in the StandardJMeterEngine object with a
> static getter ?

http://jakarta.apache.org/jmeter/usermanual/functions.html#predefinedprops

> Thanks and regards,
>
> Stephane
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1065011 - /jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties

[sebb]

On 30 January 2011 10:40, Milamber  wrote:
> Hello
>
> The documentation (component_reference) needs to be update too.

Yes, I was intending to do that later.

> In my opinion, the lower case workaround for order isn't the best choice
> for have Thread Group first. Doesn't better to change the menu factory
> to manage an optional order?

Yes, that would be better, but this works for now.
I won't object if anyone else wants to fix it - I'm not sure when I will do so.

> Milamber
>
>
>
> Le 29/01/2011 12:39, s...@apache.org a ecrit :
>> Author: sebb
>> Date: Sat Jan 29 12:39:12 2011
>> New Revision: 1065011
>>
>> URL: http://svn.apache.org/viewvc?rev=1065011&view=rev
>> Log:
>> Rename Pre and Post Thread Group labels:
>> - more like JUnit, so should be more familiar
>> - lower-case initial letter to sort after the main one
>>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMeter - include JChart2D (LGPL v2.1) to JMeter

[sebb]

On 28 February 2011 21:28, Milamber  wrote:
> Hello,
>
> Does it possible to include the jar JChart2D, under LGPL v2.1, in JMeter
> main (ASF license)?
> http://jchart2d.sourceforge.net/index.shtml

No, we cannot include the jar in JMeter downloads, see:

http://www.apache.org/legal/resolved.html#category-x

> Thanks.
>
> Milamber
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMeter - include JChart2D (LGPL v2.1) to JMeter

[sebb]

On 28 February 2011 22:50, Milamber  wrote:
> Hello,
>
> Ok no jar.
> I've developed a new graph visualiser with JChart2D. To integrate this
> element on JMeter, I must create a jar plugin/source code on a website
> like code.google.com/sourceforge?

It would probably be better at

http://apache-extras.org/

> or I can put him in Jmeter main with a
> note for download separately the J2Char2D jar file?

Possibly.

I'm trying to find out about that.

> Milamber
>
>
>
> Le 28/02/2011 22:17, sebb a ecrit :
>> On 28 February 2011 21:28, Milamber  wrote:
>>
>>> Hello,
>>>
>>> Does it possible to include the jar JChart2D, under LGPL v2.1, in JMeter
>>> main (ASF license)?
>>> http://jchart2d.sourceforge.net/index.shtml
>>>
>> No, we cannot include the jar in JMeter downloads, see:
>>
>> http://www.apache.org/legal/resolved.html#category-x
>>
>>
>>> Thanks.
>>>
>>> Milamber
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community

[sebb]

On 28 February 2011 22:35, Vince Adamo  wrote:
> Philippe,
>
> I opened an enhancement request and attached the source.
>
> See Bug 50842 - Adobe AMF Protocol Sampler based on HTTPSampler2
>
> Please feel free to e-mail me with any comments and/or questions.

Unfortunately, the BlazeDS library is LGPL 3, which cannot be included
in ASF releases.


> Thanks again,
> Vince
>
> -Original Message-
> From: Vince Adamo [mailto:vad...@tech-consortium.com]
> Sent: Monday, February 28, 2011 4:01 PM
> To: dev@jakarta.apache.org
> Subject: RE: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community
>
> Thanks!  I will create an issue, attach the code to it and update this thread 
> with the issue number.
>
> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Monday, February 28, 2011 3:59 PM
> To: dev@jakarta.apache.org
> Subject: Re: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community
>
> Hello M. Adamo,
> I am interested in integrating your library.
> Maybe you can create an issue and attach your code to it.
>
> I would try to  integrate within the next 2 months.
>
> Regards
> Philippe
>
> On Mon, Feb 28, 2011 at 10:50 PM, Vince Adamo 
> wrote:
>
>> I recently completed the development of a JMeter sampler for testing
>> Flex/BlazeDS applications using Adobe's AMF Protocol over Http.  I would
>> like to contribute this sampler to the JMeter community but it has been
>> developed as a Maven project and not as an integrated sampler in the JMeter
>> project tree.  The artifact produced by this project is a jar file
>> (ApacheJMeter_amf.jar) that is automatically deployed, during the maven
>> install phase, to the local JMeter installation's /lib/ext directory.  The
>> dependent BlazeDS jars are also copied to the local JMeter installations
>> /lib directory.
>>
>> The implementation I would like to release is a subclass of HTTPSampler2
>> and provides extension points for custom AMF messages using a mechanism
>> borrowed from the AbstractJavaSamplerClient concept.  When I began this
>> effort several months ago I searched the JMeter web site and mailing list
>> for any existing support for the AMF protocol.  I only saw recommendations
>> for using the Java sampler, in combination with the BlazeDS AmfMessage
>> class, to implement support for this protocol.  I actually went down that
>> road but found that the BlazeDS AmfMessage class uses the default Java Http
>> implementation.  This caused problems when testing with certain load
>> balancers using sticky session handling via cookies, even when handling the
>> cookies within the Java sampler.  To solve this problem I needed to ensure
>> that the connection used by the AMF sampler was not being shared with other
>> threads and preferably the one used to establish the sticky session with the
>> load balancer, which happened to be a connection established using an
>> HTTPClient sampler performing authentication for our application.  Therefore
>> I chose to extend the HTTPSampler2 class.
>>
>> In any event, I am wondering if there is a precedence for releasing open
>> source thirdparty samplers outside of the JMeter project, or whether one of
>> the current contributors would be interested and willing to integrate this
>> project into the main JMeter source tree.
>>
>> Please let me know your thoughts.
>>
>> Thanks,
>> Vince Adamo
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMETER [Bug 50943] New: Allowing concurrent downloads of embedded resources in html page

[sebb]

On 17 March 2011 23:06, Milamber  wrote:
> Hello,
>
> I would like commit this patch next week.
> Any comments are welcome.

OK by me, so long as it does not affect existing test plan behaviour
if not selected.

> Milamber
>
>
>  Original Message 
> Subject:        DO NOT REPLY [Bug 50943] New: Allowing concurrent downloads of
> embedded resources in html page
> Date:   Thu, 17 Mar 2011 18:52:34 -0400 (EDT)
> From:   bugzi...@apache.org
> Reply-To:       dev@jakarta.apache.org
> To:     notificati...@jakarta.apache.org
>
>
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50943
>
>           Summary: Allowing concurrent downloads of embedded resources in
>                    html page
>           Product: JMeter
>           Version: Nightly (Please specify date)
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: HTTP
>        AssignedTo: notificati...@jakarta.apache.org
>        ReportedBy: milam...@apache.org
>
>
> Created an attachment (id=26782)
>  --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26782)
> Patch to concurrent download embedded resources
>
> This patch add a option in HTTP Requests (Java mode, HC3/4) and HTTP Requests
> defaults to get concurrently the embedded resources (css, images, javascript,
> etc.) in html page.
> This may be useful for some tests to try to simulate multiple http connections
> like a modern browser. (in example: Firefox 3.6 use 6 parallels connections)
>
> --
> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1083962 - in /jakarta/jmeter/trunk: bin/ docs/images/screenshots/ docs/images/screenshots/http-config/ src/core/org/apache/jmeter/resources/ src/protocol/http/org/apache/jmeter/protoc

[sebb]

I get a compiler error with Java 1.5:

[javac] 
D:\eclipseworkspaces\main\JMeter_trunk\src\protocol\http\org\apache\jmeter\protocol\http\sampler\HTTPSamplerBase.java:11
90: cannot find symbol
[javac] symbol  : method
invokeAll(java.util.ArrayList)
[javac] location: class java.util.concurrent.ThreadPoolExecutor
[javac] final List>
retExec = exec.invokeAll(liste);
[javac]
^

Looks like invokeAll is Java 1.6+?

On 21 March 2011 21:20,   wrote:
> Author: milamber
> Date: Mon Mar 21 21:20:56 2011
> New Revision: 1083962
>
> URL: http://svn.apache.org/viewvc?rev=1083962&view=rev
> Log:
> Bug 50943 - Allowing concurrent downloads of embedded resources in html page
>
> Modified:
>    jakarta/jmeter/trunk/bin/jmeter.properties
>    
> jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png
>    jakarta/jmeter/trunk/docs/images/screenshots/http-request.png
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/HttpDefaultsGui.java
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>    jakarta/jmeter/trunk/xdocs/changes.xml
>    
> jakarta/jmeter/trunk/xdocs/images/screenshots/http-config/http-request-defaults.png
>    jakarta/jmeter/trunk/xdocs/images/screenshots/http-request.png
>    jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml
>
> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1083962&r1=1083961&r2=1083962&view=diff
> ==
> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
> +++ jakarta/jmeter/trunk/bin/jmeter.properties Mon Mar 21 21:20:56 2011
> @@ -682,6 +682,8 @@ beanshell.server.file=../extras/startup.
>  #httpsampler.max_redirects=5
>  # Maximum frame/iframe nesting depth (default 5)
>  #httpsampler.max_frame_depth=5
> +# Maximum await termination timeout (secs) when concurrent download embedded 
> resources (default 60)
> +#httpsampler.await_termination_timeout=60
>
>  # The encoding to be used if none is provided (default ISO-8859-1)
>  #sampleresult.default.encoding=ISO-8859-1
>
> Modified: 
> jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png?rev=1083962&r1=1083961&r2=1083962&view=diff
> ==
> Binary files - no diff available.
>
> Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-request.png
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-request.png?rev=1083962&r1=1083961&r2=1083962&view=diff
> ==
> Binary files - no diff available.
>
> Modified: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties?rev=1083962&r1=1083961&r2=1083962&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties 
> (original)
> +++ 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties 
> Mon Mar 21 21:20:56 2011
> @@ -1024,6 +1024,7 @@ web_server_domain=Server Name or IP\:
>  web_server_port=Port Number\:
>  web_testing2_source_ip=Source IP address:
>  web_testing2_title=HTTP Request HTTPClient
> +web_testing_concurrent_download=Use concurrent pool. Size:
>  web_testing_embedded_url_pattern=Embedded URLs must match\:
>  web_testing_retrieve_images=Retrieve All Embedded Resources from HTML Files
>  web_testing_title=HTTP Request
>
> Modified: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties?rev=1083962&r1=1083961&r2=1083962&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>  Mon Mar 21 21:20:56 2011
> @@ -927,6 +927,7 @@ web_server_timeout_response=R\u00E9ponse
>  web_server_timeout_title=D\u00E9lai expiration (ms)
>  web_testing2_source_ip=Adresse IP source \:
>  web_

Re: svn commit: r1083962 - in /jakarta/jmeter/trunk: bin/ docs/images/screenshots/ docs/images/screenshots/http-config/ src/core/org/apache/jmeter/resources/ src/protocol/http/org/apache/jmeter/protoc

[sebb]

The error was from Ant, using

java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode)

but I also see an error in Eclipse:

The method invokeAll(Collection>) in the type
AbstractExecutorService is not applicable for the arguments
(ArrayList)HTTPSamplerBase.java


On 21 March 2011 22:46, Milamber  wrote:
> Hello,
>
> No, invokeAll() is Java 1.5
> http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection,%20long,%20java.util.concurrent.TimeUnit%29
>
> I use 1.5 complier compliance level in Eclipse for project with a JDK
> 1.6 (on Linux)
> I will change with JDK 1.5 to search to reproduce compiler error
>
> Milamber
>
> Le 21/03/2011 22:33, sebb a ecrit :
>> I get a compiler error with Java 1.5:
>>
>>     [javac] 
>> D:\eclipseworkspaces\main\JMeter_trunk\src\protocol\http\org\apache\jmeter\protocol\http\sampler\HTTPSamplerBase.java:11
>> 90: cannot find symbol
>>     [javac] symbol  : method
>> invokeAll(java.util.ArrayList)
>>     [javac] location: class java.util.concurrent.ThreadPoolExecutor
>>     [javac]                     final List>
>> retExec = exec.invokeAll(liste);
>>     [javac]
>>             ^
>>
>> Looks like invokeAll is Java 1.6+?
>>
>> On 21 March 2011 21:20,   wrote:
>>
>>> Author: milamber
>>> Date: Mon Mar 21 21:20:56 2011
>>> New Revision: 1083962
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1083962&view=rev
>>> Log:
>>> Bug 50943 - Allowing concurrent downloads of embedded resources in html page
>>>
>>> Modified:
>>>    jakarta/jmeter/trunk/bin/jmeter.properties
>>>    
>>> jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png
>>>    jakarta/jmeter/trunk/docs/images/screenshots/http-request.png
>>>    
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
>>>    
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>>>    
>>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/HttpDefaultsGui.java
>>>    
>>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java
>>>    
>>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>>>    jakarta/jmeter/trunk/xdocs/changes.xml
>>>    
>>> jakarta/jmeter/trunk/xdocs/images/screenshots/http-config/http-request-defaults.png
>>>    jakarta/jmeter/trunk/xdocs/images/screenshots/http-request.png
>>>    jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml
>>>
>>> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
>>> URL: 
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1083962&r1=1083961&r2=1083962&view=diff
>>> ==
>>> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
>>> +++ jakarta/jmeter/trunk/bin/jmeter.properties Mon Mar 21 21:20:56 2011
>>> @@ -682,6 +682,8 @@ beanshell.server.file=../extras/startup.
>>>  #httpsampler.max_redirects=5
>>>  # Maximum frame/iframe nesting depth (default 5)
>>>  #httpsampler.max_frame_depth=5
>>> +# Maximum await termination timeout (secs) when concurrent download 
>>> embedded resources (default 60)
>>> +#httpsampler.await_termination_timeout=60
>>>
>>>  # The encoding to be used if none is provided (default ISO-8859-1)
>>>  #sampleresult.default.encoding=ISO-8859-1
>>>
>>> Modified: 
>>> jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png
>>> URL: 
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png?rev=1083962&r1=1083961&r2=1083962&view=diff
>>> ==
>>> Binary files - no diff available.
>>>
>>> Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-request.png
>>> URL: 
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-request.png?rev=1083962&r1=1083961&r2=1083962&view=diff
>>> ==
>>> Binary files - no diff availabl

Re: svn commit: r1084019 - /jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java

[sebb]

Thanks, that's fixed it.

On 21 March 2011 23:32,   wrote:
> Author: milamber
> Date: Mon Mar 21 23:32:17 2011
> New Revision: 1084019
>
> URL: http://svn.apache.org/viewvc?rev=1084019&view=rev
> Log:
> Correct a compiler error with a real JDK 1.5
> Bug 50943 - Allowing concurrent downloads of embedded resources in html page

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE][LAZY] Move Jakarta Regexp to Attic

[sebb]

On 22 March 2011 00:00, Rahul Akolkar  wrote:
> This is a vote to move Jakarta Regexp to the Apache Attic, based on
> the outcome of the most recent discussion on the topic.
>
> Since Regexp may not have enough PMC members active, this vote will be
> held by lazy consensus. If you object, please also provide a
> reasonable explanation.

+1

> Vote runs for a week, ending no sooner than Mar 28th, ~8:00 pm Eastern
> US. Vote is being held on general@jao but is being cross-posted to
> ensure we reach the full audience. Please include general@jao on any
> replies.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] JUnit sampler sample time changes

[sebb]

On 31 March 2011 19:41, Ben Cuthbert  wrote:
> All
>
> I have been looking over the code in the JUnitSampler code under the jmeter 
> source.
> I would like to make a change to use nanoTime() rather than milliseconds.

Why?

> I can see in the AnnotatedTestCase there is an elapsed time. But I can't see 
> how it
> is returned to a results table. Any ideas?

The time in AnnotatedTestCase is only used for reporting timeout errors.

The actual sample time is calculated using SampleResult.sampleStart()
and sampleEnd() which already use nanoTime().

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] JUnit sampler sample time changes

[sebb]

On 3 April 2011 08:32, Ben Cuthbert  wrote:
> I see the nanotime. But the time in the sampler results is reported in ms. So 
> when you have you data
> it just says 0. I would like it to go one further and report a low level.

Sorry, that's not possible currently.

Changing the elapsed time to nanoSecs would break compatibility, and
such a level of precision is illusory anyway for almost all of the
samplers.

It might be possible to keep a separate field for nanoSeconds and
report that, but I'm not sure there's sufficient need to warrant the
change and additional data storage.

> Regards
> On 2 Apr 2011, at 16:18, sebb wrote:
>
>> On 31 March 2011 19:41, Ben Cuthbert  wrote:
>>> All
>>>
>>> I have been looking over the code in the JUnitSampler code under the jmeter 
>>> source.
>>> I would like to make a change to use nanoTime() rather than milliseconds.
>>
>> Why?
>>
>>> I can see in the AnnotatedTestCase there is an elapsed time. But I can't 
>>> see how it
>>> is returned to a results table. Any ideas?
>>
>> The time in AnnotatedTestCase is only used for reporting timeout errors.
>>
>> The actual sample time is calculated using SampleResult.sampleStart()
>> and sampleEnd() which already use nanoTime().
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] JUnit sampler sample time changes

[sebb]

That reminds me -

Tests I've done on Windows show that nanoTime() drifts considerably
when compared with currentTimeMillis(), i.e. its clock does not appear
to run at the same rate.

Here's a simple test you can run:

public class NanoDrift {
public static void main(String[] args) throws InterruptedException {
long systemTime = System.currentTimeMillis();
long nanoTime = System.nanoTime() / 100;
long count=0;
while(true){
long systemDiff = System.currentTimeMillis() - systemTime;
long nanoDiff = System.nanoTime() / 100 - nanoTime;
long absdiff = Math.abs(systemDiff-nanoDiff);
if (absdiff > 100 || (count % 60 == 0)) {
System.out.println("@:"+count+" |S-N|:"+absdiff+"
S:"+systemDiff + " N:" + nanoDiff);
}
Thread.sleep(1000);
count++;
}
}
}

Behaviour may depend on the JVM used; on

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

I just got

@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60032 N:60032
@:120 |S-N|:1 S:120032 N:120033
@:180 |S-N|:2 S:180032 N:180034
@:240 |S-N|:6 S:240032 N:240038
@:300 |S-N|:7 S:300032 N:300039
@:360 |S-N|:13 S:360032 N:360045
@:420 |S-N|:14 S:420032 N:420046
@:480 |S-N|:15 S:480032 N:480047
@:540 |S-N|:16 S:540032 N:540048
@:600 |S-N|:17 S:600032 N:600049
@:660 |S-N|:18 S:660032 N:660050
@:720 |S-N|:19 S:720032 N:720051
@:780 |S-N|:20 S:780032 N:780052
@:840 |S-N|:21 S:840032 N:840053
@:900 |S-N|:22 S:900032 N:900054
@:960 |S-N|:23 S:960032 N:960055
@:1020 |S-N|:24 S:1020032 N:1020056
@:1080 |S-N|:21 S:1080063 N:1080084
@:1140 |S-N|:22 S:1140063 N:1140085
@:1200 |S-N|:23 S:1200063 N:1200086
@:1260 |S-N|:24 S:1260063 N:1260087
@:1320 |S-N|:21 S:1320172 N:1320193
@:1380 |S-N|:36 S:1380172 N:1380208
@:1440 |S-N|:37 S:1440172 N:1440209
@:1500 |S-N|:38 S:1500172 N:1500210
@:1560 |S-N|:40 S:1560172 N:1560212
@:1620 |S-N|:41 S:1620172 N:1620213
@:1680 |S-N|:42 S:1680172 N:1680214
@:1740 |S-N|:29 S:1740188 N:1740217
@:1800 |S-N|:30 S:1800188 N:1800218
@:1860 |S-N|:31 S:1860188 N:1860219
@:1920 |S-N|:31 S:1920188 N:1920219
@:1980 |S-N|:32 S:1980188 N:1980220
@:2040 |S-N|:33 S:2040188 N:2040221
@:2100 |S-N|:34 S:2100188 N:2100222
@:2160 |S-N|:35 S:2160188 N:2160223
@:2220 |S-N|:36 S:2220188 N:2220224
@:2280 |S-N|:37 S:2280188 N:2280225
@:2340 |S-N|:38 S:2340188 N:2340226
@:2400 |S-N|:39 S:2400188 N:2400227
@:2460 |S-N|:40 S:2460188 N:2460228
@:2520 |S-N|:41 S:2520188 N:2520229

However, on a FreeBSD system using

java version "1.6.0_03-p4"
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_17_dec_2010_05_08-b00)
Java HotSpot(TM) 64-Bit Server VM (build
1.6.0_03-p4-root_17_dec_2010_05_08-b00, mixed mode)

I see no drift:

@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60118 N:60118
@:120 |S-N|:0 S:120239 N:120239
@:180 |S-N|:1 S:180357 N:180358
@:240 |S-N|:0 S:240476 N:240476
@:300 |S-N|:0 S:300594 N:300594
@:360 |S-N|:0 S:360713 N:360713
@:420 |S-N|:0 S:420830 N:420830
@:480 |S-N|:1 S:480948 N:480949
@:540 |S-N|:0 S:541066 N:541066
@:600 |S-N|:0 S:601184 N:601184
@:660 |S-N|:0 S:661302 N:661302
@:720 |S-N|:0 S:721419 N:721419
@:780 |S-N|:0 S:781537 N:781537
@:840 |S-N|:0 S:841655 N:841655
@:900 |S-N|:0 S:901773 N:901773
@:960 |S-N|:1 S:961890 N:961891
@:1020 |S-N|:0 S:1022008 N:1022008
@:1080 |S-N|:0 S:1082126 N:1082126
@:1140 |S-N|:0 S:1142244 N:1142244
@:1200 |S-N|:1 S:1202361 N:1202362
@:1260 |S-N|:1 S:1262479 N:1262480
@:1320 |S-N|:0 S:1322600 N:1322600
@:1380 |S-N|:1 S:1382748 N:1382749
@:1440 |S-N|:0 S:1442879 N:1442879
@:1500 |S-N|:1 S:1502997 N:1502998
@:1560 |S-N|:0 S:1563115 N:1563115
@:1620 |S-N|:0 S:1623233 N:1623233
@:1680 |S-N|:0 S:1683351 N:1683351
@:1740 |S-N|:0 S:1743468 N:1743468
@:1800 |S-N|:0 S:1803586 N:1803586
@:1860 |S-N|:0 S:1863704 N:1863704
@:1920 |S-N|:1 S:1923838 N:1923839
@:1980 |S-N|:0 S:1983959 N:1983959
@:2040 |S-N|:1 S:2044077 N:2044078
@:2100 |S-N|:0 S:2104195 N:2104195
@:2160 |S-N|:0 S:2164313 N:2164313
@:2220 |S-N|:1 S:2224430 N:2224431
@:2280 |S-N|:1 S:2284548 N:2284549
@:2340 |S-N|:0 S:2344666 N:2344666
@:2400 |S-N|:1 S:2404784 N:2404785
@:2460 |S-N|:0 S:2464903 N:2464903
@:2520 |S-N|:0 S:2525020 N:2525020
@:2580 |S-N|:0 S:2585138 N:2585138
@:2640 |S-N|:0 S:2645256 N:2645256


On 3 April 2011 13:50, Peter Lin  wrote:
> Another important thing to consider is that nano time costs a lot more
> than System.currentTimeMillis().
>
> I've done some benchmarking in the past and nano time costs 30% on
> windows. On linux, the cost is higher due to differences in how it's
> implemented.
>
> On Sun, Apr 3, 2011 at 5:28 AM, sebb  wrote:
>> On 3 April 2011 08:32, Ben Cuthbert  wrote:
>>> I see the nanotime. But the time in the sampler results is reported in ms. 
>>> So when you have you data
>>&

Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/

[sebb]

On 4 April 2011 00:13,   wrote:
> Author: milamber
> Date: Sun Apr  3 23:13:09 2011
> New Revision: 1088435
>
> URL: http://svn.apache.org/viewvc?rev=1088435&view=rev
> Log:
> Bug 50170 - Bytes reported by http sampler is after GUnZip
> Add an optional property to allow change the method to get response size.
>
> Modified:
>    jakarta/jmeter/trunk/bin/jmeter.properties
>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
>    jakarta/jmeter/trunk/xdocs/changes.xml
>    jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml
>
> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1088435&r1=1088434&r2=1088435&view=diff
> ==
> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
> +++ jakarta/jmeter/trunk/bin/jmeter.properties Sun Apr  3 23:13:09 2011
> @@ -243,6 +243,16 @@ log_level.jorphan=INFO
>  #log_config=logkit.xml
>
>  #---
> +# HTTP common configuration
> +#---
> +
> +# Response size calculate method
> +# default: only data (uncompress size if deflate)
> +#http.getbytes.type=default
> +#http.getbytes.type=calculate_headers_size+default
> +#http.getbytes.type=calculate_headers_size+content-length_value

These values are a bit complicated; I'd prefer to see true/false
values if possible.

> +
> +#---
>  # HTTP Java configuration
>  #---
>
>
> Modified: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java?rev=1088435&r1=1088434&r2=1088435&view=diff
> ==
> --- jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java 
> (original)
> +++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java Sun 
> Apr  3 23:13:09 2011
> @@ -36,10 +36,12 @@ import java.util.Iterator;
>  import java.util.LinkedHashMap;
>  import java.util.List;
>  import java.util.Locale;
> +import java.util.Map.Entry;
>  import java.util.MissingResourceException;
>  import java.util.Properties;
>  import java.util.Random;
>  import java.util.ResourceBundle;
> +import java.util.Set;
>  import java.util.StringTokenizer;
>  import java.util.Vector;
>
> @@ -73,6 +75,8 @@ public class JMeterUtils implements Unit
>             new Perl5Compiler());
>
>     private static final String EXPERT_MODE_PROPERTY = "jmeter.expertMode"; 
> // $NON-NLS-1$
> +
> +    private static final String HEADER_CONTENT_LENGTH = "Content-Length"; // 
> $NON-NLS-1$
>
>     private static final String ENGLISH_LANGUAGE = 
> Locale.ENGLISH.getLanguage();
>
> @@ -1237,4 +1241,19 @@ public class JMeterUtils implements Unit
>         return linkedHeaders;
>     }
>
> +    /**
> +     * Get Content-Length value from headers
> +     * @param headers
> +     * @return Content-Length value
> +     */
> +    public static int getHeaderContentLength(String headers) {
> +        LinkedHashMap lhm = 
> JMeterUtils.parseHeaders(headers);
> +        Set> keySet = lhm.entrySet();
> +        for (Entry entry : keySet) {
> +            if (entry.getKey().equals(HEADER_CONTENT_LENGTH)) {
> +                return Integer.parseInt(entry.getValue());
> +            }
> +        }
> +        return 0; // Content-Length not found

This does not work for chunked input. It might be better to store the
actual response size when receiving the response, rather than trying
to calculate it later.

> +    }
>  }
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java?rev=1088435&r1=1088434&r2=1088435&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
>  Sun Apr  3 23:13:09 2011
> @@ -23,6 +23,7 @@ import java.net.URL;
>
>  import org.apache.jmeter.protocol.http.util.HTTPConstants;
>  import org.apache.jmeter.samplers.SampleResult;
> +import org.apache.jmeter.util.JMeterUtils;
>
>  /**
>  * This is a specialisation of the SampleResult class for the HTTP protocol.
> @@ -31,6 +32,15 @@ import org.apache.jmeter.samplers.Sampl

Re: svn commit: r1088442 - /jakarta/jmeter/trunk/build.xml

[sebb]

On 4 April 2011 00:39,   wrote:
> Author: milamber
> Date: Sun Apr  3 23:39:56 2011
> New Revision: 1088442
>
> URL: http://svn.apache.org/viewvc?rev=1088442&view=rev
> Log:
> Add HTTPClient 4 jars libraries for the binary distribution

Well spotted!

> Modified:
>    jakarta/jmeter/trunk/build.xml
>
> Modified: jakarta/jmeter/trunk/build.xml
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1088442&r1=1088441&r2=1088442&view=diff
> ==
> --- jakarta/jmeter/trunk/build.xml (original)
> +++ jakarta/jmeter/trunk/build.xml Sun Apr  3 23:39:56 2011
> @@ -328,6 +328,9 @@
>     
>     
>     
> +    
> +    
> +    
>     
>     
>     
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/

[sebb]

On 4 April 2011 20:35, Milamber  wrote:
>
> [snip]
>>> +#http.getbytes.type=default
>>> +#http.getbytes.type=calculate_headers_size+default
>>> +#http.getbytes.type=calculate_headers_size+content-length_value
>>>
>> These values are a bit complicated; I'd prefer to see true/false
>> values if possible.
>>
> Ok I change this to 2 properties true/false.

+1

>>
>>> +    /**
>>> +     * Get Content-Length value from headers
>>> +     * @param headers
>>> +     * @return Content-Length value
>>> +     */
>>> +    public static int getHeaderContentLength(String headers) {
>>> +        LinkedHashMap lhm = 
>>> JMeterUtils.parseHeaders(headers);
>>> +        Set> keySet = lhm.entrySet();
>>> +        for (Entry entry : keySet) {
>>> +            if (entry.getKey().equals(HEADER_CONTENT_LENGTH)) {
>>> +                return Integer.parseInt(entry.getValue());
>>> +            }
>>> +        }
>>> +        return 0; // Content-Length not found
>>>
>> This does not work for chunked input. It might be better to store the
>> actual response size when receiving the response, rather than trying
>> to calculate it later.
>>
>
> Ok, store in sampleresult when receiving the response. If 0 (no value),
> the response data size is used.
>
>
> With my last submission (r1088748), I try to respond to your feedback.
> Please say me if another thing to improve.

The problem of chunked responses still exists - such responses don't
have a Content-Length header.

One way round this would be to wrap the input Stream with a
org.apache.commons.io.input.CountingInputStream.
I don't think this will affect performance adversely.

Does that make sense?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 3 April 2011 23:19, Milamber  wrote:
> Hello,
>
> Currently I works to add a optional property to get response size (in
> bytes) by different methods:
> 1/ default (responses data size (uncompressed length if gzip)
> 2/ responses headers length +  default (response data size)
> 2/ responses headers length + content-length value (real size if gzip)
> See:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50170
>
> When I testing my future patch, I found this bug on HC4 Impl:
>
> When Web server (Apache 2.2) uses mod_deflate to compress response data,
> the data remains compress data (in view results tree, we have the
> compress characters and getBytes() is the compressed length)
>
> I thinks that must add a code section in sample() method when JMeter
> reads response data, to decode GZip response if needs, like HC3Impl?
> (perhaps HC4 has a specific method to do this?)

HC4 should do this automatically, I think, but there was a bug whereby
it did not recognise some encoding methods:

https://issues.apache.org/jira/browse/HTTPCLIENT-1063

As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
JMeter trunk was recently updated to use).

Can you check which version of HC4 you were using, and the
Content-type used by Apache 2.2?

> Milamber
>
>
> Le 25/11/2010 15:45, sebb a ecrit :
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not  finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 6 April 2011 23:36, Milamber  wrote:
>
>> HC4 should do this automatically, I think, but there was a bug whereby
>>
>
> I have found this problem too:
> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
> certificate (verisign, thawte, etc.) but doesn't works with self-signed
> ssl certificate.
> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?

No, I forgot.
That needs to be fixed so that all certificates are accepted, same as for HC3.
I'll fix that shortly.

> Milamber
>
>
>> it did not recognise some encoding methods:
>>
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>
>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>> JMeter trunk was recently updated to use).
>>
>> Can you check which version of HC4 you were using, and the
>> Content-type used by Apache 2.2?
>>
>>
>>> Milamber
>>>
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not  finally decided about the AJP sampler - it can be easily
>>>> converted, but I don't think there's much of a use case for switching
>>>> between AJP and another implementation.
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 6 April 2011 23:11, Milamber  wrote:
>
>>> When Web server (Apache 2.2) uses mod_deflate to compress response data,
>>> the data remains compress data (in view results tree, we have the
>>> compress characters and getBytes() is the compressed length)
>>>
>>> I thinks that must add a code section in sample() method when JMeter
>>> reads response data, to decode GZip response if needs, like HC3Impl?
>>> (perhaps HC4 has a specific method to do this?)
>>>
>> HC4 should do this automatically, I think, but there was a bug whereby
>> it did not recognise some encoding methods:
>>
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>
>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>> JMeter trunk was recently updated to use).
>>
>> Can you check which version of HC4 you were using, and the
>> Content-type used by Apache 2.2?
>>
>
> I uses last JMeter with HC v4.1.1
> httpclient-4.1.1.jar
> httpmime-4.1.1.jar
> and
> httpcore-4.1.jar
>
> Response headers (extract) :
> Server: Apache/2.2.16 (Unix) DAV/2
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 70
>
> Request Headers:
> Connection: keep-alive
> Accept-Encoding: gzip,deflate
>
> (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue)
>
> Issue too with www.google.com

Thanks, that was useful, though strangely google would not gzip until
I added a User-Agent of Firefox. Accepting gzip was not enough.

Code now fixed - HC4 does support gzip decoding, but not by default.

> Milamber
>>
>>> Milamber
>>>
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not  finally decided about the AJP sampler - it can be easily
>>>> converted, but I don't think there's much of a use case for switching
>>>> between AJP and another implementation.
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 7 April 2011 00:07, sebb  wrote:
> On 6 April 2011 23:36, Milamber  wrote:
>>
>>> HC4 should do this automatically, I think, but there was a bug whereby
>>>
>>
>> I have found this problem too:
>> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
>> certificate (verisign, thawte, etc.) but doesn't works with self-signed
>> ssl certificate.
>> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?
>
> No, I forgot.
> That needs to be fixed so that all certificates are accepted, same as for HC3.
> I'll fix that shortly.

Fixed.

>> Milamber
>>
>>
>>> it did not recognise some encoding methods:
>>>
>>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>>
>>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>>> JMeter trunk was recently updated to use).
>>>
>>> Can you check which version of HC4 you were using, and the
>>> Content-type used by Apache 2.2?
>>>
>>>
>>>> Milamber
>>>>
>>>>
>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>
>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>> run-time choice of implementation.
>>>>>
>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>> backwards compatibility and comparison.
>>>>>
>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>> useful to be able to switch implementations easily - currently that
>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>
>>>>> The current plan is to allow the implementation to be specified on the
>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>> screen.
>>>>>
>>>>> The code is a bit involved, because the Config settings are processed
>>>>> at run-time after the test plan has been built.
>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>> store the sampler settings - and the implementation can then be
>>>>> changed.]
>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>> implementation class.
>>>>> These classes have to extend an abstract class that provides the
>>>>> necessary methods to interface with the Proxy test element and thus
>>>>> provide access to the test element properties.
>>>>> That part seems to be working OK.
>>>>>
>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>> (during load) to use the new sampler.
>>>>>
>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>
>>>>> I've not  finally decided about the AJP sampler - it can be easily
>>>>> converted, but I don't think there's much of a use case for switching
>>>>> between AJP and another implementation.
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>>
>>>>
>>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Counting actual input size [was: svn commit: r1088435]

[sebb]

On 8 April 2011 07:45, Milamber  wrote:
[...]

>>> With my last submission (r1088748), I try to respond to your feedback.
>>> Please say me if another thing to improve.
>>>
>> The problem of chunked responses still exists - such responses don't
>> have a Content-Length header.
>>
>> One way round this would be to wrap the input Stream with a
>> org.apache.commons.io.input.CountingInputStream.
>> I don't think this will affect performance adversely.
>>
>> Does that make sense?
>>
>
> Yes may be a good idea.
> Since your last commit on HC4Impl, entity.getContentLength() return -1
> (unknown size) (but http response have a content-length define)
> I thinks the ResponseContentEncoding class which decompress stream is
> the cause.

That seems likely.

> On HC4, I try to use a CountingInputStream on instream, but the return
> size is uncompressed.
> //                InputStream instream = entity.getContent();
>                InputStream instream = new
> CountingInputStream(entity.getContent());
>                res.setResponseData(readResponse(res, instream, (int)
> entity.getContentLength()));
>                int cnt = ((CountingInputStream) instream).getCount();
>                log.debug("CNT=" + cnt);
>
>
> I thinks that CountingInputStream must be in more deep in code, directly
> in HttpClient, or inside the Gzip/deflate input stream?

Yes, you're right - the streams we currently use are somewhat removed
from the actual input .

For HC3 and Java, we decompress the inputstream directly, so could
wrap that with a CountingInputStream first.
However, the stream contains the de-chunked data, so the chunking
overhead would not be seen.
But it would be closer to the true size, and might be acceptable.

Ideally, one would like to intercept the input stream before
de-chunking, but I'm not sure that's possible with HC3 and Java.

However with HC3 and HC4 one can provide custom sockets, so it would
be possible to count the actual input.

One could even detect the end of the header by looking for CRLF CRLF -
but that might add an unacceptable overhead, in which case we could
use the current header calculation which would be reasonably close.

It's not possible to provide a custom socket implementation for Java
HTTP, only Java HTTPS, so this approach would not work there, so we
would have to use the CountingInputStream.

I suggest we use the simple approach of CountingInputStream (CIS) for
Java and HC3; it's easy to do and fairly accurate. No point spending
lots of time on those implementations as HC4 is better.

I'll have a look at HC4 to see what can be done - would you like to
see if CIS works OK for HC3 and Java?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 8 April 2011 14:23, sebb  wrote:
> On 8 April 2011 07:45, Milamber  wrote:
> [...]
>
>>>> With my last submission (r1088748), I try to respond to your feedback.
>>>> Please say me if another thing to improve.
>>>>
>>> The problem of chunked responses still exists - such responses don't
>>> have a Content-Length header.
>>>
>>> One way round this would be to wrap the input Stream with a
>>> org.apache.commons.io.input.CountingInputStream.
>>> I don't think this will affect performance adversely.
>>>
>>> Does that make sense?
>>>
>>
>> Yes may be a good idea.
>> Since your last commit on HC4Impl, entity.getContentLength() return -1
>> (unknown size) (but http response have a content-length define)
>> I thinks the ResponseContentEncoding class which decompress stream is
>> the cause.
>
> That seems likely.
>
>> On HC4, I try to use a CountingInputStream on instream, but the return
>> size is uncompressed.
>> //                InputStream instream = entity.getContent();
>>                InputStream instream = new
>> CountingInputStream(entity.getContent());
>>                res.setResponseData(readResponse(res, instream, (int)
>> entity.getContentLength()));
>>                int cnt = ((CountingInputStream) instream).getCount();
>>                log.debug("CNT=" + cnt);
>>
>>
>> I thinks that CountingInputStream must be in more deep in code, directly
>> in HttpClient, or inside the Gzip/deflate input stream?
>
> Yes, you're right - the streams we currently use are somewhat removed
> from the actual input .
>
> For HC3 and Java, we decompress the inputstream directly, so could
> wrap that with a CountingInputStream first.
> However, the stream contains the de-chunked data, so the chunking
> overhead would not be seen.
> But it would be closer to the true size, and might be acceptable.
>
> Ideally, one would like to intercept the input stream before
> de-chunking, but I'm not sure that's possible with HC3 and Java.
>
> However with HC3 and HC4 one can provide custom sockets, so it would
> be possible to count the actual input.
>
> One could even detect the end of the header by looking for CRLF CRLF -
> but that might add an unacceptable overhead, in which case we could
> use the current header calculation which would be reasonably close.
>
> It's not possible to provide a custom socket implementation for Java
> HTTP, only Java HTTPS, so this approach would not work there, so we
> would have to use the CountingInputStream.
>
> I suggest we use the simple approach of CountingInputStream (CIS) for
> Java and HC3; it's easy to do and fairly accurate. No point spending
> lots of time on those implementations as HC4 is better.
>
> I'll have a look at HC4 to see what can be done - would you like to
> see if CIS works OK for HC3 and Java?

HC4 keeps metrics on the connection, so it's very easy to find the
actual byte counts for header and body.

==

I think we should consider changing the default to be the total
network response size. However, this may affect some size assertions.

HTTPSampleResult (v2.4) stores the decoded body size only. Maybe we
should store the header and raw body sizes separately, rather than
combining some of them. This would give the most flexibility.

Also, consider adding the fields to SampleResult rather than
HTTPSampleResult. For non-HTTP responses, the headerSize would
normally be zero and raw body size would be the same as decoded body
size, but e.g. for POP3 perhaps it would make sense to implement
header size.

Adding the fields to SampleResult would also make it easier to display
them in the Tree View Listener (HTTPSampleResult is currently defined
in a different jar which is built later - perhaps that's a mistake).

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 13 April 2011 07:53, Milamber  wrote:
> I've updated the patch on bug 43363 since your last commit on HC4
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
>
> With your last commit on HC4Impl, the header size and body size aren't good 
> with a gzip stream ou chunked response.
> For example, with a chunked response, they are:
> HC4:
> Size in bytes: 8199
> Headers size in bytes: 8192  (=> Like a buffer reader?)
> Body size in bytes: 7
>
> Java & HC3 (good value, verified with wireshark)
> Size in bytes: 10505
> Headers size in bytes: 581
> Body size in bytes: 9924
>
>
> For a gzip response:
> HC4:
> Size in bytes: 14025 (good)
> Headers size in bytes: 1440
> Body size in bytes: 12585
>
> Java & HC3:
> Size in bytes: 14025
> Headers size in bytes: 291
> Body size in bytes: 13734
>
> It is a bug with HttpClient 4.1 too?

Possibly.

Since starting to use the metrics I've found that they are mainly
intended for use in custom keep-alive strategies, so may not always
provide the data we want, but I'm hoping to patch HC4 to provide more
useful stats in future.

If you can provide details of how you are generating the test data
above, I can take a further look at the problem.

> Milamber
>
>
> Le 10/04/2011 16:09, Milamber a ecrit :
>>
>> Le 09/04/2011 12:40, sebb a ecrit :
>>
>>> [snip]
>>>
>>>>> On HC4, I try to use a CountingInputStream on instream, but the return
>>>>> size is uncompressed.
>>>>> //                InputStream instream = entity.getContent();
>>>>>                InputStream instream = new
>>>>> CountingInputStream(entity.getContent());
>>>>>                res.setResponseData(readResponse(res, instream, (int)
>>>>> entity.getContentLength()));
>>>>>                int cnt = ((CountingInputStream) instream).getCount();
>>>>>                log.debug("CNT=" + cnt);
>>>>>
>>>>>
>>>>> I thinks that CountingInputStream must be in more deep in code, directly
>>>>> in HttpClient, or inside the Gzip/deflate input stream?
>>>>>
>>>>>
>>>> Yes, you're right - the streams we currently use are somewhat removed
>>>> from the actual input .
>>>>
>>>> For HC3 and Java, we decompress the inputstream directly, so could
>>>> wrap that with a CountingInputStream first.
>>>> However, the stream contains the de-chunked data, so the chunking
>>>> overhead would not be seen.
>>>> But it would be closer to the true size, and might be acceptable.
>>>>
>>>> Ideally, one would like to intercept the input stream before
>>>> de-chunking, but I'm not sure that's possible with HC3 and Java.
>>>>
>>>> However with HC3 and HC4 one can provide custom sockets, so it would
>>>> be possible to count the actual input.
>>>>
>>>> One could even detect the end of the header by looking for CRLF CRLF -
>>>> but that might add an unacceptable overhead, in which case we could
>>>> use the current header calculation which would be reasonably close.
>>>>
>>>> It's not possible to provide a custom socket implementation for Java
>>>> HTTP, only Java HTTPS, so this approach would not work there, so we
>>>> would have to use the CountingInputStream.
>>>>
>>>> I suggest we use the simple approach of CountingInputStream (CIS) for
>>>> Java and HC3; it's easy to do and fairly accurate. No point spending
>>>> lots of time on those implementations as HC4 is better.
>>>>
>>>> I'll have a look at HC4 to see what can be done - would you like to
>>>> see if CIS works OK for HC3 and Java?
>>>>
>>>>
>> Yes, works fine (plain response, gzip and chunked)
>>
>>
>>
>>> HC4 keeps metrics on the connection, so it's very easy to find the
>>> actual byte counts for header and body.
>>>
>>>
>> The bytes count works (with a HttpConnectionMetrics). It's the full
>> response size including the headers. To get raw response size, I must
>> subtract headers size (after calculating them).
>> I found a issue for chunked response (for example: with google homepage,
>> and disable headers manager (don't accept gzip response), the response
>> size is incorrect. I don't know why, I must search.
>>
>>
>>> ==
>>>
>>> 

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 13 April 2011 23:33, Milamber  wrote:
>
>
> Le 13/04/2011 14:26, sebb a ecrit :
>> On 13 April 2011 07:53, Milamber  wrote:
>>
>>> I've updated the patch on bug 43363 since your last commit on HC4
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
>>>
>>> With your last commit on HC4Impl, the header size and body size aren't good 
>>> with a gzip stream ou chunked response.
>>> For example, with a chunked response, they are:
>>> HC4:
>>> Size in bytes: 8199
>>> Headers size in bytes: 8192  (=> Like a buffer reader?)
>>> Body size in bytes: 7
>>>
>>> Java & HC3 (good value, verified with wireshark)
>>> Size in bytes: 10505
>>> Headers size in bytes: 581
>>> Body size in bytes: 9924
>>>
>>>
>>> For a gzip response:
>>> HC4:
>>> Size in bytes: 14025 (good)
>>> Headers size in bytes: 1440
>>> Body size in bytes: 12585
>>>
>>> Java & HC3:
>>> Size in bytes: 14025
>>> Headers size in bytes: 291
>>> Body size in bytes: 13734
>>>
>>> It is a bug with HttpClient 4.1 too?
>>>
>> Possibly.
>>
>> Since starting to use the metrics I've found that they are mainly
>> intended for use in custom keep-alive strategies, so may not always
>> provide the data we want, but I'm hoping to patch HC4 to provide more
>> useful stats in future.
>>
>> If you can provide details of how you are generating the test data
>> above, I can take a further look at the problem.
>>
>
> I've put a simple test case to show diff between plain/gzip/chunked
> response with the three http request type
>
> https://issues.apache.org/bugzilla/attachment.cgi?id=26885

Thanks!

I can see that there is definitely a problem with the HC4 counts, and
it's a bit odd.

If I put a break-point just after

long headerBytes = metrics.getReceivedBytesCount();

and another after

long totalBytes = metrics.getReceivedBytesCount();

the headerBytes value is the same as displayed when running at full
speed, but the totalBytes figure is generally much higher. Weird.

I can hopefully reproduce this directly as an HC4 test case (without
all the JMeter code) and use that to fix the issue.

Thanks for all the fixes to the other code.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 14 April 2011 00:12, sebb  wrote:
> On 13 April 2011 23:33, Milamber  wrote:
>>
>>
>> Le 13/04/2011 14:26, sebb a ecrit :
>>> On 13 April 2011 07:53, Milamber  wrote:
>>>
>>>> I've updated the patch on bug 43363 since your last commit on HC4
>>>>
>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
>>>>
>>>> With your last commit on HC4Impl, the header size and body size aren't 
>>>> good with a gzip stream ou chunked response.
>>>> For example, with a chunked response, they are:
>>>> HC4:
>>>> Size in bytes: 8199
>>>> Headers size in bytes: 8192  (=> Like a buffer reader?)
>>>> Body size in bytes: 7
>>>>
>>>> Java & HC3 (good value, verified with wireshark)
>>>> Size in bytes: 10505
>>>> Headers size in bytes: 581
>>>> Body size in bytes: 9924
>>>>
>>>>
>>>> For a gzip response:
>>>> HC4:
>>>> Size in bytes: 14025 (good)
>>>> Headers size in bytes: 1440
>>>> Body size in bytes: 12585
>>>>
>>>> Java & HC3:
>>>> Size in bytes: 14025
>>>> Headers size in bytes: 291
>>>> Body size in bytes: 13734
>>>>
>>>> It is a bug with HttpClient 4.1 too?
>>>>
>>> Possibly.
>>>
>>> Since starting to use the metrics I've found that they are mainly
>>> intended for use in custom keep-alive strategies, so may not always
>>> provide the data we want, but I'm hoping to patch HC4 to provide more
>>> useful stats in future.
>>>
>>> If you can provide details of how you are generating the test data
>>> above, I can take a further look at the problem.
>>>
>>
>> I've put a simple test case to show diff between plain/gzip/chunked
>> response with the three http request type
>>
>> https://issues.apache.org/bugzilla/attachment.cgi?id=26885
>
> Thanks!
>
> I can see that there is definitely a problem with the HC4 counts, and
> it's a bit odd.
>
> If I put a break-point just after
>
> long headerBytes = metrics.getReceivedBytesCount();
>
> and another after
>
> long totalBytes = metrics.getReceivedBytesCount();
>
> the headerBytes value is the same as displayed when running at full
> speed, but the totalBytes figure is generally much higher. Weird.
>
> I can hopefully reproduce this directly as an HC4 test case (without
> all the JMeter code) and use that to fix the issue.

Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was
not always updating the metrics.
That part of the code seems to depends on how much data is available,
so the behaviour is timing related.

I still need to fix the original issue so stats can safely be obtained
for responses with no content (e.g. HEAD)
(though we have a work-round for JMeter).

> Thanks for all the fixes to the other code.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: nightlies vs release: two files

[sebb]

On 14 April 2011 14:14, Peter Lynch  wrote:
> The nightlies require unzipping two files to make a usable runtime as
> described here http://people.apache.org/builds/jakarta-jmeter/nightly/ .
>
> Is it correct to assume that the a final release will just be one
> distributable?

Sort of.

There is a binary dist and a source dist, and each is available as zip
and tar.gz, so there are actually 4 archives (plus hashes and sigs).

However only one binary is needed to run JMeter.

Here is the download page:

http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

> -Peter
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: nightlies vs release: two files

[sebb]

On 14 April 2011 16:14, Peter Lynch  wrote:
> I'm trying to understand why the nightlies have a _bin.zip and _lib.zip
> instead of just a single .zip like the official 2.4 release did.
>
> I know the _lib.zip contains the third party jars and _bin.zip contains
> everything else - but why not a single .zip like the official release?

Because the 3rd party jars rarely change, and at the time this was set
up, broadband was not generally available.

Nightlies are intended for developers only; it's convenient not to
have to download everything each time.

> -Peter
>
>
> On Thu, Apr 14, 2011 at 9:24 AM, sebb  wrote:
>
>> On 14 April 2011 14:14, Peter Lynch  wrote:
>> > The nightlies require unzipping two files to make a usable runtime as
>> > described here http://people.apache.org/builds/jakarta-jmeter/nightly/ .
>> >
>> > Is it correct to assume that the a final release will just be one
>> > distributable?
>>
>> Sort of.
>>
>> There is a binary dist and a source dist, and each is available as zip
>> and tar.gz, so there are actually 4 archives (plus hashes and sigs).
>>
>> However only one binary is needed to run JMeter.
>>
>> Here is the download page:
>>
>> http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi
>>
>> > -Peter
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Peter Lynch
> http://blog.peterlynch.ca
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 14 April 2011 22:09, Milamber  wrote:
>
>
> Le 14/04/2011 12:14, sebb a ecrit :
>> On 14 April 2011 00:12, sebb  wrote:
>>
>>> On 13 April 2011 23:33, Milamber  wrote:
>>>
>>>>
>>>> Le 13/04/2011 14:26, sebb a ecrit :
>>>>
>>>>> On 13 April 2011 07:53, Milamber  wrote:
>>>>>
>>>>>
>>>>>> I've updated the patch on bug 43363 since your last commit on HC4
>>>>>>
>>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
>>>>>>
>>>>>> With your last commit on HC4Impl, the header size and body size aren't 
>>>>>> good with a gzip stream ou chunked response.
>>>>>> For example, with a chunked response, they are:
>>>>>> HC4:
>>>>>> Size in bytes: 8199
>>>>>> Headers size in bytes: 8192  (=> Like a buffer reader?)
>>>>>> Body size in bytes: 7
>>>>>>
>>>>>> Java & HC3 (good value, verified with wireshark)
>>>>>> Size in bytes: 10505
>>>>>> Headers size in bytes: 581
>>>>>> Body size in bytes: 9924
>>>>>>
>>>>>>
>>>>>> For a gzip response:
>>>>>> HC4:
>>>>>> Size in bytes: 14025 (good)
>>>>>> Headers size in bytes: 1440
>>>>>> Body size in bytes: 12585
>>>>>>
>>>>>> Java & HC3:
>>>>>> Size in bytes: 14025
>>>>>> Headers size in bytes: 291
>>>>>> Body size in bytes: 13734
>>>>>>
>>>>>> It is a bug with HttpClient 4.1 too?
>>>>>>
>>>>>>
>>>>> Possibly.
>>>>>
>>>>> Since starting to use the metrics I've found that they are mainly
>>>>> intended for use in custom keep-alive strategies, so may not always
>>>>> provide the data we want, but I'm hoping to patch HC4 to provide more
>>>>> useful stats in future.
>>>>>
>>>>> If you can provide details of how you are generating the test data
>>>>> above, I can take a further look at the problem.
>>>>>
>>>>>
>>>> I've put a simple test case to show diff between plain/gzip/chunked
>>>> response with the three http request type
>>>>
>>>> https://issues.apache.org/bugzilla/attachment.cgi?id=26885
>>>>
>>> Thanks!
>>>
>>> I can see that there is definitely a problem with the HC4 counts, and
>>> it's a bit odd.
>>>
>>> If I put a break-point just after
>>>
>>> long headerBytes = metrics.getReceivedBytesCount();
>>>
>>> and another after
>>>
>>> long totalBytes = metrics.getReceivedBytesCount();
>>>
>>> the headerBytes value is the same as displayed when running at full
>>> speed, but the totalBytes figure is generally much higher. Weird.
>>>
>>> I can hopefully reproduce this directly as an HC4 test case (without
>>> all the JMeter code) and use that to fix the issue.
>>>
>> Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was
>> not always updating the metrics.
>> That part of the code seems to depends on how much data is available,
>> so the behaviour is timing related.
>>
>> I still need to fix the original issue so stats can safely be obtained
>> for responses with no content (e.g. HEAD)
>> (though we have a work-round for JMeter).
>>
>
> Thanks for your works on this bug.
>
> Where download a nightly build of httpcore for test in JMeter?
> (or I must compile last trunk?)

I've created a snapshot here:

https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/

> Milamber
>>
>>> Thanks for all the fixes to the other code.
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 15 April 2011 08:21, Milamber  wrote:
>
>
> Le 14/04/2011 23:09, sebb a ecrit :
>> On 14 April 2011 22:09, Milamber  wrote:
>>
>>>
>>> Le 14/04/2011 12:14, sebb a ecrit :
>>>
>>>> On 14 April 2011 00:12, sebb  wrote:
>>>>
>>>>
>>>>> On 13 April 2011 23:33, Milamber  wrote:
>>>>>
>>>>>
>>>>>> Le 13/04/2011 14:26, sebb a ecrit :
>>>>>>
>>>>>>
>>>>>>> On 13 April 2011 07:53, Milamber  wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I've updated the patch on bug 43363 since your last commit on HC4
>>>>>>>>
>>>>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
>>>>>>>>
>>>>>>>> With your last commit on HC4Impl, the header size and body size aren't 
>>>>>>>> good with a gzip stream ou chunked response.
>>>>>>>> For example, with a chunked response, they are:
>>>>>>>> HC4:
>>>>>>>> Size in bytes: 8199
>>>>>>>> Headers size in bytes: 8192  (=> Like a buffer reader?)
>>>>>>>> Body size in bytes: 7
>>>>>>>>
>>>>>>>> Java & HC3 (good value, verified with wireshark)
>>>>>>>> Size in bytes: 10505
>>>>>>>> Headers size in bytes: 581
>>>>>>>> Body size in bytes: 9924
>>>>>>>>
>>>>>>>>
>>>>>>>> For a gzip response:
>>>>>>>> HC4:
>>>>>>>> Size in bytes: 14025 (good)
>>>>>>>> Headers size in bytes: 1440
>>>>>>>> Body size in bytes: 12585
>>>>>>>>
>>>>>>>> Java & HC3:
>>>>>>>> Size in bytes: 14025
>>>>>>>> Headers size in bytes: 291
>>>>>>>> Body size in bytes: 13734
>>>>>>>>
>>>>>>>> It is a bug with HttpClient 4.1 too?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Possibly.
>>>>>>>
>>>>>>> Since starting to use the metrics I've found that they are mainly
>>>>>>> intended for use in custom keep-alive strategies, so may not always
>>>>>>> provide the data we want, but I'm hoping to patch HC4 to provide more
>>>>>>> useful stats in future.
>>>>>>>
>>>>>>> If you can provide details of how you are generating the test data
>>>>>>> above, I can take a further look at the problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I've put a simple test case to show diff between plain/gzip/chunked
>>>>>> response with the three http request type
>>>>>>
>>>>>> https://issues.apache.org/bugzilla/attachment.cgi?id=26885
>>>>>>
>>>>>>
>>>>> Thanks!
>>>>>
>>>>> I can see that there is definitely a problem with the HC4 counts, and
>>>>> it's a bit odd.
>>>>>
>>>>> If I put a break-point just after
>>>>>
>>>>> long headerBytes = metrics.getReceivedBytesCount();
>>>>>
>>>>> and another after
>>>>>
>>>>> long totalBytes = metrics.getReceivedBytesCount();
>>>>>
>>>>> the headerBytes value is the same as displayed when running at full
>>>>> speed, but the totalBytes figure is generally much higher. Weird.
>>>>>
>>>>> I can hopefully reproduce this directly as an HC4 test case (without
>>>>> all the JMeter code) and use that to fix the issue.
>>>>>
>>>>>
>>>> Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was
>>>> not always updating the metrics.
>>>> That part of the code seems to depends on how much data is available,
>>>> so the behaviour is timing related.
>>>>
>>>> I still need to fix the original issue so stats can safely be obtained
>>>> for responses with no content (e.g. HEAD)
>>>> (though we have a work-round for JMeter).
>>>>
>>>>
>>> Thanks for your works on this bug.
>>>
>>> Where download a nightly build of httpcore for test in JMeter?
>>> (or I must compile last trunk?)
>>>
>> I've created a snapshot here:
>>
>> https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/
>>
>
>
> Thanks.
> I've tested, but don't works perfectly. With HC4, headers size always
> 1440 bytes.
> (total response size are good)
> Perhaps, we must calculate headears size like HC3 instead of use metrics?

I don't see the behaviour you are reporting; HC4 seems to work OK for
me with the snapshot build.
Did you remove/rename the existing httpcore jar?

What URL are you seeing the problem with?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Counting actual input size [was: svn commit: r1088435]

[sebb]

On 18 April 2011 22:36, Milamber  wrote:
> [snip]
>>
>>
> Thanks for your works on this bug.
>
> Where download a nightly build of httpcore for test in JMeter?
> (or I must compile last trunk?)
>
>
 I've created a snapshot here:

 https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/


>>>
>>> Thanks.
>>> I've tested, but don't works perfectly. With HC4, headers size always
>>> 1440 bytes.
>>> (total response size are good)
>>> Perhaps, we must calculate headears size like HC3 instead of use metrics?
>>>
>> I don't see the behaviour you are reporting; HC4 seems to work OK for
>> me with the snapshot build.
>>
>
> I confirm. I have this issue with test case on wiki jakarta, google home
> page.
> Sometimes with 1440 bytes ann sometimes 1338 (google, Jakarta wiki)
> I've found too: if the total response size (headers+body < 1440 (or
> 1438)) HC4 have a headers size = total size, and body size is response
> data size (old behavior)
> (site with small response : www.monip.org)

I don't see the same problem as you; wiki and monip behave OK for me.

Can you capture the site response using Wireshark?

I wonder if there is some additional buffering going on somewhere in your ISP?

>
>> Did you remove/rename the existing httpcore jar?
>>
>
> Yes. And same issue with Jdk1.5 / 6 on Linux/Windows.
>
>
>> What URL are you seeing the problem with?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 20 April 2011 22:30, Milamber  wrote:
> Hello,
>
> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
> policy: ignore cookie seems don't works)

Looks like this is a new bug - the example works correctly in JMeter 2.4.

I must have messed something up when converting the HC3.1 sampler to
the new class layout.

I'll take a look shortly.

> With JMeter trunk and HC3.1 sampler, if you test a website with a login page
> which used a auth session ID cookie to keep track user session and *without*
> a JMeter cookie manager, the connection works and we can accessed on
> protected resources.
> The normal case is: if no cookie manager, we don't have a access on
> protected resources (we have a error 408 with tomcat examples)
>
>
> (an example Webapp is provided with tomcat archive :
> http://localhost:8080/examples/jsp/security/protected/
> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml
> before running tomcat)
>
> Simple test case.

Thanks - well spotted!

> Milamber
>
> Le 25/11/2010 16:45, sebb a ecrit :
>
> Just a heads up that I'm currently working on trying to combine the
> HTTP implementations (Java, HttpClient3) into a single GUI, with
> run-time choice of implementation.
>
> The rationale for this is that HttpClient 4 is now available, and it
> would be good to add that, but I think we should keep HttpClient for
> backwards compatibility and comparison.
>
> Creating another GUI/Sampler set is easy enough, but it would be
> useful to be able to switch implementations easily - currently that
> requires switching samplers (e.g. by editting the JMX file).
>
> The current plan is to allow the implementation to be specified on the
> HTTP Request Defaults config screen as well as on the HTTP Request
> screen.
>
> The code is a bit involved, because the Config settings are processed
> at run-time after the test plan has been built.
> [But even the Sampler GUI needs to create the sampler before it can
> store the sampler settings - and the implementation can then be
> changed.]
> Currently I use a Sampler Proxy that dispatches to the appropriate
> implementation class.
> These classes have to extend an abstract class that provides the
> necessary methods to interface with the Proxy test element and thus
> provide access to the test element properties.
> That part seems to be working OK.
>
> The next phase is to ensure that existing JMX files can be converted
> (during load) to use the new sampler.
>
> The intention is to keep the existing Java and HttpClient samplers, so
> that subclasses will continue to work, but not expose them in the GUI.
>
> I've not  finally decided about the AJP sampler - it can be easily
> converted, but I don't think there's much of a use case for switching
> between AJP and another implementation.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] HTTP Sampler consolidation of implementations

[sebb]

On 21 April 2011 01:57, sebb  wrote:
> On 20 April 2011 22:30, Milamber  wrote:
>> Hello,
>>
>> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
>> policy: ignore cookie seems don't works)
>
> Looks like this is a new bug - the example works correctly in JMeter 2.4.
>
> I must have messed something up when converting the HC3.1 sampler to
> the new class layout.
>
> I'll take a look shortly.

Fixed.

>
>> With JMeter trunk and HC3.1 sampler, if you test a website with a login page
>> which used a auth session ID cookie to keep track user session and *without*
>> a JMeter cookie manager, the connection works and we can accessed on
>> protected resources.
>> The normal case is: if no cookie manager, we don't have a access on
>> protected resources (we have a error 408 with tomcat examples)
>>
>>
>> (an example Webapp is provided with tomcat archive :
>> http://localhost:8080/examples/jsp/security/protected/
>> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml
>> before running tomcat)
>>
>> Simple test case.
>
> Thanks - well spotted!
>
>> Milamber
>>
>> Le 25/11/2010 16:45, sebb a ecrit :
>>
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not  finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org