Good point about SSL - these new elements could perhaps live in
.protocol.ssl.*?
URL's are created within UrlConfig (ie getUrl()). This method is called by
the HTTPSampler class, which extracts the UrlConfig object from the Entry.
So, perhaps if your classes are config elements that are added to a test
Entry, then the sampler can retrieve them from the Entry object, and set the
appropriate properties before calling getUrl(). If the Entry object doesn't
contain your config elements, then fine, no property is set. This would
require that you modify ony the Sampler objects in question (ie HTTPSampler,
FTPSampler). Would that work?
I am not a GUI programmer either - JMeter's my one and only. But, I did have
some fun designing this gui and making this framework. It is a little
strange, perhaps, and certainly is still pretty rough. But, so far, I'm
pretty happy with it. I've been getting a lot of good suggestions from
people, and they are helping quite a bit. My only frustration is that I
simply don't know all the little sticking points about Swing and the Awt (and
there seem to be a lot of them). My strategy so far is, make the simplest
GUI I can, and hopefully a gui-guru will show up and make things better :-)
-Mike
On Tuesday 28 August 2001 20:54, you wrote:
> "Stover, Michael" wrote:
> > 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 :-)
>
> That's what I was thinking--although it is applicable at a lower level. In
> other words, the SSL code would work for FTP over SSL, RMI over SSL, SMTP
> over SSL.
>
> These are all low level things that could arguably be cross-protocol.
>
> > 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.
>
> The main thing is that it is done *before* a test run, and if the
> Hierarchical nature of JMeter is to stand true, before the URL object is
> created (unless you work strictly with Sockets....). The main thing is
> that I need to set the SSLSessionManager before the URL object is created,
> properly seeded with my TrustManager and my KeyManager.
>
> I am still trying to wrap my head around things in JMeter. Don't get me
> wrong, I like what I see--but actually implementing the things I want to
> implement is taking me some time. Part of it has to do with the fact that
> I am new to GUI programming (very well versed at Server Side programming
> though).
>
> Things are done differently here. ;)
>
> > -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]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Mike Stover
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
