Tracking here: https://issues.apache.org/jira/browse/BCEL-316
Gary On Fri, Apr 12, 2019 at 8:58 AM Gary Gregory <garydgreg...@gmail.com> wrote: > I'm going to take the same lame-ish approach as > org.apache.bcel.classfile.JavaClass.debug. It's a hack, but we have a > precedent here; until we come to a better solution. I think JUL is ... not > great. > > Gary > > On Wed, Apr 10, 2019 at 8:01 PM Bruno P. Kinoshita > <brunodepau...@yahoo.com.br.invalid> wrote: > >> +1 for dropping or improving. [imaging] will go out in 1.0 with j.u.l if >> I recall correctly. Maybe a similar approach would work here, if we decide >> to keep the logs. >> CheersBruno >> >> On Thursday, 11 April 2019, 11:58:40 am NZST, Rob Tompkins < >> chtom...@gmail.com> wrote: >> >> >> >> > On Apr 10, 2019, at 7:46 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > >> >> On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <chtom...@gmail.com> >> wrote: >> >> >> >> >> >> >> >>> On Apr 10, 2019, at 7:20 PM, Gary Gregory <garydgreg...@gmail.com> >> >> wrote: >> >>> >> >>> Hi All: >> >>> >> >>> In BCEL, we log a warning to the console: >> >>> >> >>> >> >> >> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240 >> >>> >> >>> Which you can't really do anything about since it does not tell you >> what >> >>> class file it is complaining about. >> >>> >> >>> 1) Should remove the logging? >> >> >> >> Uncertain here. In the general case, I feel like we should either do >> >> nothing or throw an exception. But the logic feels like it warrants >> some >> >> explanation, so I don’t know >> >> >> >>> or, >> >>> 2) Should we improve the logging? >> >> >> >> This should be our minimal plan, if removing it doesn’t make sense. >> >> >> >>> or, >> >>> 3) Do nothing? >> >> >> >> Because you brought it up, it feels like something should be done? >> >> >> > >> > I see these possible solutions: >> > >> > 1) Remove the logging (simple) >> > 2) Make logging configurable (bleh) >> > 3) Use a logging API (Log4j 2 for example) >> > 4) Throw an exception in the next major version if this is _really_ an >> > incorrect state but that does not seem like it would help anyone. >> > >> > I favor (1). >> >> +1, particularly with Mark’s context. -Rob >> > >> > Gary >> > >> > >> >>> >> >>> Gary >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >