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:
Clients of this logger are all sorts of views, presenters and UI components. They usually obtain an instance by field or constructor injection:
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 asmight have logging lines for entering and exiting. However and its counterpart exiting methods aren't supported in client. Moreover, a more generic method for this purpse is undefined for the type Logger too. Any pretty solution?
-- 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);
@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);
Logger::entering(String sourceClass, String sourceMethod)
logp(Level level, String sourceClass, String sourceMethod, String msg)
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