You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2011/11/03 19:06:21 UTC
DO NOT REPLY [Bug 52131] New: Eliminate JmeterKeyStore and simplify
code
https://issues.apache.org/bugzilla/show_bug.cgi?id=52131
Bug #: 52131
Summary: Eliminate JmeterKeyStore and simplify code
Product: JMeter
Version: 2.5.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: HTTP
AssignedTo: issues@jmeter.apache.org
ReportedBy: sebb@apache.org
Classification: Unclassified
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.
Thoughts?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52131] Eliminate DefaultKeyStore and simplify code
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52131
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Eliminate JmeterKeyStore |Eliminate DefaultKeyStore
|and simplify code |and simplify code
--- Comment #2 from Sebb <se...@apache.org> 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
Log:
Bug 52131 - Eliminate DefaultKeyStore and simplify code - part 1
Modified:
jmeter/trunk/src/core/org/apache/jmeter/util/keystore/JmeterKeyStore.java
URL: http://svn.apache.org/viewvc?rev=1197863&view=rev
Log:
Bug 52131 - Eliminate DefaultKeyStore and simplify code - part 1b
Removed:
jmeter/trunk/src/core/org/apache/jmeter/util/keystore/DefaultKeyStore.java
Still need to tidy code that uses the class
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52131] Eliminate DefaultKeyStore and simplify code
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52131
--- Comment #3 from Philippe Mouawad <p....@ubik-ingenierie.com> 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
ignored.
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.
Yes.
> 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.
>
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52131] Eliminate JmeterKeyStore and simplify code
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52131
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> 2011-11-04 20:59:02 UTC ---
First solution seems fine for me.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.