This sounds like code that belongs under *.protocol.http. Where exactly in
there would depend, but it wouldn't be wrong to put config elements under
.config, I would think :-)
Regarding setting things before sockets are created - that might be
problematic. How can you guarantee that the user hasn't done other tests
previously, and now loads up your config elements to do the HTTPS test? I
don't know if this helps, but all classes that implement
JMeterComponentModel get instantiated and have getClassLabel called on them
when JMeter's GUI is first used. So, you may have a chance to "hijack"
things in a static initializer in one of your classes. But, if this would
then require that users use your classes, that may not be a good solution.
-Mike
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 28, 2001 2:52 PM
> To: [EMAIL PROTECTED]
> Subject: Implementing new functionality
>
>
> I am in the process of adding some core functionality for
> HTTPS authentication so that we can control our own CA certs
> and Client Certs. I would like to know how I should organize
> my files. I have the following files in process:
>
> Apache TrustStore (allow you to install CA certs dynamically)
> Apache KeyStore (allow you to install client certs
> dynamically--X509 based
> for simplicity)
> Apache KeyManager (allow you to select the proper client
> key--uses the store)
> Graphical elements like HttpAuth config extension (i.e.
> Certificate selection)
>
> The TrustStore is a config element that adds CA certs to the
> CA keystore.
> The KeyStore is a config element that adds client certs to
> the keystore. It
> requires private keys or PKCS12 certs.
> The KeyManager does the same as AuthManager (i.e. matching URL to key)
>
> I believe the graphical elements are self explanitory.
>
> The biggest thing is that I need to hijack the
> SSLSocketFactory used by the
> HTTPS system. The TrustStore,KeyStore,KeyManager all have to
> be set before
> any sockets are created--so I need to know where it is best
> to place them.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
