Thank all for your input! I will try to remove the log dependence.
About the logging of native library failure, users of CRYPTO could get the information about whether native is enabled or native failure reason from org.apache.commons.crypto.utils.NativeCodeLoader#isNativeCodeLoaded() or org.apache.commons.crypto.cipher.Openssl#loadingFailureReason(), they could log these information in their system if they need. At the same time, I think we can add an option for "native only" (Currently, when loading native failed, we log native failure error and use JCE implementation as fallback directly), the property in configuration may like "ENABLE_FALLBACK_ON_NATIVE_FAILED", if user disable the option, it could throw an exception when loading native failed. Is there anyone have other opinions? Regards Dapeng -----Original Message----- From: Torsten Curdt [mailto:tcu...@vafer.org] Sent: Saturday, June 11, 2016 6:44 PM To: Commons Developers List Subject: Re: [crypto] Logging dependency On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > On Jun 10, 2016, at 2:56 PM, Torsten Curdt <tcu...@vafer.org> wrote: > > > >> Matt, there is a big difference between printing the stack trace > >> and walking it to find the info. printing it on every debug call > >> would be insane. > >> > > > > Why would anyone want to do that? > > > > > https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement. > html > > > > > > And how do you think the logging frameworks get that kind of > information? :) > > I think you missed Sebb’s suggestion of having the debug method call > printStackTrace(). > Not really - that's was my "Why would anyone want to do that?" in reference to. I was just trying to say that context information is not lost as you suggested.
