Hello, Sun, Dapeng <dapeng....@intel.com> schrieb am Mo., 20. Juni 2016 um 04:54 Uhr:
> >>Do I understand correctly that Crypto should fall back to JCE if native > code could not be loaded? > > Yes, if "ENABLE_FALLBACK_ON_NATIVE_FAILED" is true(by default), it would > fall back to JCE > Sounds like a pretty clear protocol to me: if "ENABLE_FALLBACK_ON_NATIVE_FAILED" is and true, default to JCE. Throw an exception otherwise. Benedikt > Regards > Dapeng > > -----Original Message----- > From: Benedikt Ritter [mailto:brit...@apache.org] > Sent: Saturday, June 18, 2016 12:43 AM > To: Commons Developers List > Subject: Re: [crypto] Logging dependency > > Hello Dapeng, > > Sun, Dapeng <dapeng....@intel.com> schrieb am Mi., 15. Juni 2016 um > 11:22 Uhr: > > > 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? > > > > Do I understand correctly that Crypto should fall back to JCE if native > code could not be loaded? > > Benedikt > > > > > > > > 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. > > >
