On 02/06/2008, Ralf Hauser <[EMAIL PROTECTED]> wrote: > Hi developers, > > Since we are very happy about the fixes on SSL-recording and SizeAssertion > from last week that makes Jmeter our choice for testing in many areas, we > are motivated to invest more in secure mail testing with JMeter. Therefore, > I just wanted to raise the question of > https://issues.apache.org/bugzilla/show_bug.cgi?id=38387 again: > > 1) If we extend the already contributed SMTP-Sampler (bug 45053), will it > have equal chance to get into the SVN Head if we use BouncyCastle (BC) > http://www.bouncycastle.org/ for crypto operations or not? >
BouncyCastle is already used by some other projects so I don't think that is a problem. But ideally the code should use standard Java APIs as far as possible. > 2) If not, are there any recommendations (under the assumption that 45053 > SMTP-Sampler makes it relatively soon) to make life as easy as possible for > a non-BC part to coexist with a BC extension to it? > I see some hints on > p.13 of http://jakarta.apache.org/jmeter/extending/jmeter_tutorial.pdf, > but is there > a) an easy way to extend a current Sampler with those extra features without > having to remove the smtpSampler.jar from the Jmeter installation once we > also want to locally run the extra .class'es that contain BC in our > environment If you are prepared to create a new class, then there should be no problem with that co-existing. I'm not sure it's possible to provide a replacement class if the class already exists in one of the jars. > b) would it be still interesting for the Jmeter project that we add all the > non-BC signing/encryption stuff to the SMTP-Sampler sources (like a GUI for > the encryption/signature key files, etc. and interfaces to use them... - > perhaps someone else will come up to write classes for under the apache > license instead - we currently unfortunately don't have the resources to do > this) even though they won't really be usable immediately for non-BC users. It's possible to depend on jars that are not distributed with JMeter - e.g. BeanShell and Javamail. So long as the jars are optional - i.e. JMeter can be used without them - then it is not likely to be a problem. User who want to use the optional functionality would have to download the jars themselves - and thus agree to any licenses that are required. This may require using reflection or catching ClassNotFound exceptions to ensure that JMeter behaves OK without the jar. For example, all BeanShell access is through a single class that uses reflection. But this is all moot as BC looks OK. > Many thanks for any hints in advance! As the code contributions are quite substantial, it would be helpful if the contributor(s) could sign ICLAs. It might also be useful for the company to provide a CCLA. For details, please see: http://www.apache.org/licenses/#clas > Ralf > > P.S.: If we are successful on this, we probably ought to add signature > verification/decryption to the pop-sampler as well... > > > > > --------------------------------------------------------------------- > 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]
