Monday, November 7, 2016

GWT Logger: your best practices, tips and reasonings.

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)

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.

3) Consider e.g. an app designed within Activities&Places framework. It's not uncommon to have some supporting logging in activities in order to assure the correctness of your MVP under development. Therefore methods such as
com.google.gwt.activity.shared.Activity::start(AcceptsOneWidget panel, EventBus eventBus);
might have logging lines for entering and exiting. However
Logger::entering(String sourceClass, String sourceMethod)
and its counterpart exiting methods aren't supported in client. Moreover, a more generic method for this purpse
logp(Level level, String sourceClass, String sourceMethod, String msg)
is undefined for the type Logger too. Any pretty solution?

There might be more interesting issues concerning java.util.logging.Logger you ran into during the development of your projects. So, please feel free to mention them in this discussion as well, as the practices you found handy correspondingly.

--
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+unsubscribe@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.

No comments:

Post a Comment