Bug 52131 - Eliminate JmeterKeyStore and simplify code
Summary: Eliminate JmeterKeyStore and simplify code
Status: NEW
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 2.5.1
Hardware: PC Windows XP
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
Depends on:
Reported: 2011-11-03 18:06 UTC by Sebb
Modified: 2016-02-21 22:15 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Sebb 2011-11-03 18:06:21 UTC
The JmeterKeyStore class is not really needed any more, and could be dropped in favour of DefaultKeyStore.

This would then allow the ctor to be extended to include the indexes, which could then be final variables.

Alternatively, merge DefaultKeyStore into JmeterKeyStore and make that class concrete. That would probably mean fewer changes.

Comment 1 Philippe Mouawad 2011-11-04 20:59:02 UTC
First solution seems fine for me.
Comment 2 Sebb 2011-11-05 01:33:49 UTC
Decided to merge implementation code into JMeterKeyStore instead.

URL: http://svn.apache.org/viewvc?rev=1197862&view=rev
Bug 52131 - Eliminate DefaultKeyStore and simplify code - part 1


URL: http://svn.apache.org/viewvc?rev=1197863&view=rev
Bug 52131 - Eliminate DefaultKeyStore and simplify code - part 1b


Still need to tidy code that uses the class
Comment 3 Philippe Mouawad 2011-11-20 18:26:07 UTC
From dev list discussion, implementation requirements:
>> In earlier versions of JMeter, the client keystore relied on the
>> system property javax.net.ssl.keyStore.
>> This could either be set by the user prior to starting the test, or
>> the SSL Manager Option menu item could be used to set the system
>> property which would be picked up later.
>> There is also the javax.net.ssl.keyStoreType property which is
>> normally used to determine the store type, and
>> javax.net.ssl.keyStorePassword for the password.
>> See
>> http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Customization
>> I think it would probably make sense to use these properties to
>> directly configure the key and trust stores.
>> So I propose to change KeyStore Config so it behaves like the SSL
>> Manager Option dialogue, i.e. it will just save any settings as System
>> or JMeter properties.
> Not sure I understand this part.
> If you're talking about the popup that asks for password when it does not
> find System property ,
>  I don't find it very "User friendly" and I remember being a bit confused
> about it when I started using JMeter with HTTPS.
> It would make also make sense to merge it with the SSL Manager dialogue.

Sorry, what I meant was:
- use the code strategy from SSL Manager Option, i.e. save filename as
system property
- extend the new KeyStore Config to include other config options.

>> This is currently only of use in GUI test runs - it cannot be saved
>> with a test plan.
>> KeyStore Config should probably be renamed as SSL Config, and would
>> have additional fields to define the other SSL System properties.
>> This would be entirely optional - users could define the system or
>> JMeter properties instead - but would be more flexible as the settings
>> would be stored in the plan, not in external file(s).
> I agree with this if you mean  SSL Config component will store:
> - Current options
> - + System properties used to configure Keystore path, password and others

Yes, that's the plan.

>> The properties can be defined in the SSL Config testStarted() method
>> as that runs before the HTTP Sampler testStarted() method.
>> The latter can be used to preload the SSLManager if required; this
>> would allow SSL Config to be omitted, provided that the appropriate
>> JMeter property was set.
>> To summarise:
>> - keystore and truststore would be initialised based purely on System
>> or JMeter property settings
> Do you mean these properties can be defined:
> - In System properties

Yes, for javax.ssl properties

> - In JMeter properties

Yes, for JMeter-specific properties (e.g. alias indexes, loading strategy)

> - IN SSL config that would override default settings

Yes, the new SSL Config would overwrite any existing properties.

Just realised there's an issue with how to handle pre-existing settings.
If the user provides a value in the GUI, we should use that.
However, if no value is provided, does that mean the property should
be left alone, or does that mean it should be removed?

The NOT_UNDEFINED setting could be used for this. If enabled, the user
can choose "Undefined", in which case the existing setting should be
Otherwise, if the user does not provide a value, any default will be used.

There's also an minor issue with multiple test runs (GUI mode only) -
if the Config element changes any system properties, then a subsequent
run will pick up the new settings. If the user previously defined (or
undefined) a property, they would need to be aware of this, and change
the settings accordingly.

>> - SSL Config GUI would allow the settings to be overridden as necessary
>> Does this all make sense?
> I agree it's a good idea to have on Config Element in test plan to
> configure these properties if it's what you mean.


> In my opinion, we should remove the popup in SSLManager#getPassword,
> because it makes a different behaviour
> wether you are in GUI mode or NON GUI:

Yes, the plan was to remove it.

>   - In GUI mode you will be asked for password so you will think your test
>   works
>   - In Non GUI you will have a failure

Exactly, that's the problem now.

Comment 4 The ASF infrastructure team 2022-09-24 20:37:47 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2636