qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: ProtonJ - Bouncy Castle Dependency
Date Thu, 05 May 2016 09:19:24 GMT
I can't speak to why BC is used, but if it is then using provided
scope instead of reflection seems reasonable. The file history shows
it used to be a hard dependency and was later changed to use
reflection to make it a runtime dependency. Its not clear if folks
were even aware of provided/optional dependencies at the time.


On 4 May 2016 at 23:04, Day, Jem <jday@paypal.com.invalid> wrote:
> Rob,
> I was also wondering that; my assumption was that BC was being leveraged to reduce configuration
concerns with JCE providers etc and to keep everything “in house”.
> I do have a question on style/approach : The class in question jumps through reflection
hoops to, I assume, remove the need for a hard dependency on the BC libraries. In reality
though the code DOES have an absolute dependency on those classes to function correctly so
one might argue it would be better to declare a maven <scope>provided</scope>
dependency on BC. This would simplify the code greatly without changing the usage model for
existing users of the proton-j library (it won’t result in everybody downloading BC, and
it won’t result in version conflicts) - you should get the best of both worlds so long as
the code is constructed in manner where it fails gracefully if the desired dependencies aren’t
> I do, of course, have a subtle hidden agenda here as the changes required to use the
more recent versions of BC seems to require leveraging more of their capabilities, and doing
that by via reflection just seems wrong ...
> Opinions/Comments ???
> On 5/4/16, 7:19 AM, "Rob Godfrey" <rob.j.godfrey@gmail.com> wrote:
>>As an aside, I think it should be possible to eliminate the bouncy castle
>>dependency entirely, it's pretty easy to convert PEM files into the binary
>>encoding which can then be used directly by Java (and in the Certificates
>>case, the Java X509 CertificateFactory will work directly off PEM files).
>>-- Rob
>>On 4 May 2016 at 15:01, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
>>> On 3 May 2016 at 22:38, Day, Jem <jday@paypal.com.invalid> wrote:
>>> > Hi Guys,
>>> >
>>> > ‘SslEngineFacadeFactory’ uses reflection on some bouncy-castle classes
>>> to load certificates and keys from the configured PEM files.
>>> >
>>> > Currently the code expects to find ‘org.bouncycastle.openssl.PEMReader’
>>> but this has been removed and as far as I can tell
>>> ‘org.bouncycastle.openssl.PEMParser’ should be used in its place - as a
>>> side note it looks like this functionality has been around for quite a
>>> while and the PEMReader had been flagged for deprecation.
>>> >
>>> > I’m happy to provide a patch but wanted to ensure nobody else was was
>>> addressing this.
>>> >
>>> > —
>>> > Jem
>>> > Principal Architect, Core Payments
>>> >
>>> >
>>> >
>>> Nobody is working on that (or at least hasn't said so if they are), feel
>>> free.
>>> Robbie
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message