GWT provides java.util.logging.Logger but my source code was depending in apache-commons logging. So I reimplemented apache-commons logging based on the logging facilities of GWT. The same can be done if your code depends on log4j or slf4j. You can keep the same packaging structures so you can easiliy move staff from GWT to normal java.
On Tue, Nov 8, 2016 at 12:32 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On Tuesday, November 8, 2016 at 4:36:20 AM UTC+1, vitrums wrote: >> >> Recently I found, that some log4j-like functionality in my client's code >> could be handy. So with the GWT logging module I can pretty much have a >> shared logging code, which is very convenient to use on both sides. The >> tutorial is here http://www.gwtproject.org/doc/ >> latest/DevGuideLogging.html . However, I instantly ran into multiple >> questions: >> >> 1) How many loggers *(Logger.getLogger("logger-name")) *should I >> typically get away with in an average size project? What will their >> hierarcy and naming convention *("" -> "Parent-name" -> >> "Parent-name.Child-name") *be? And therefore which one should be the >> most common across the code for debugging and user's feedback during >> troubleshooting *(is it some "parent.child.grandson...Adam"?)* // *see >> 2)* >> > > The common practice (with almost any Java logging framework) is to have > your loggers as static final fields and using the class name as the logger > name (some logging frameworks even have static factory methods taking a > java.lang.Class<?> as "name"). > > >> 2) I'm developing my projects with GIN, and since a call like >> *Logger.getLogger("logger-name")* has a string constant *"logger-name"*, >> then any logger should definitely become a subject of injection (in my >> opinion). Hence, I created providers - one per *"logger-name"* - and >> bound *Logger.class* to them with an annotation, just like this: >> bind(Logger.class).annotatedWith(DefaultLogger.class).toProvider( >> DefaultLoggerProvider.class).in(Singleton.class); >> Clients of this logger are all sorts of views, presenters and UI >> components. They usually obtain an instance by field or constructor >> injection: >> @Inject @DefaultLogger private java.util.logging.Logger logger; >> I would like to know the *pros and cons* of this solution from your >> point of view. Again, any best practices are very much welcome. >> > > Re. the common practice above, you won't generally inject loggers. > Guice (but not GIN AFAIK) has custom support for java.util.logging.Logger > and will inject them without the need for any configuration: > https://github.com/google/guice/wiki/BuiltInBindings#loggers Note that > this is only to remove some boilerplate, and Guice would inject a logger > whose name is the name of the class it's injected in (see 1 above re. the > common practice for naming loggers) > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at https://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- Vassilis Virvilis -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
