On Fri, Jul 30, 2010 at 3:51 PM, Unnur Gretarsdottir <[email protected]> wrote: > > > On Fri, Jul 30, 2010 at 3:44 PM, Scott Blum <[email protected]> wrote: >> >> Okay, taking this all together, I'm wondering if the following approach >> works, or if there's a flaw in it: >> - Rewrite any calls that would utilize or return the default LogManager. >> (LogManager.getLogManager(), Logger.getLogger()). >> - Return your own subclass of LogManager instead, which would serve as an >> isolated world completely detached from the real JRE (maybe the old >> DevModeLogManager already does this correctly?) >> So basically, you get the effect of replacing the system property, but >> without actually replacing the system property. Since you can't rewrite the >> JRE method bodies (Logger.getLogger()), you just intercept those calls. >> Should just be a handful, right? >> I'm not necessarily saying this is the best route, but would it result in a >> solid system? > > I think that would only work if I rewrote every function whose internal (JRE) > implementation included a call to LogManager.getLogManager(). I can take a > closer look, but this seems kind of dicey to me...
For example, let's say I rewrite Logger.getLogger(), but it still returns a Logger object (as I'm currently doing). Now, someone calls logger.setLevel(SEVERE); in the JRE implementation of that method (which would be used, because this is a Logger object, and I didn't rewrite the setLevel() method), there's a call to: logManager.setLevelRecursively(this, newLevel); Now this code, since it's JRE code and didn't get bytecode rewritten, has the java.util.logging.LogManager. Not only will this log manager not delegate correctly, it actually doesn't know anything about this logger, because when I created it (by calling Logger.getLogger()), I diverted to a different LogManager, that put this logger in a completely different tree of loggers. > > >> >> On Fri, Jul 30, 2010 at 6:19 PM, Unnur Gretarsdottir <[email protected]> >> wrote: >>> >>> >>> On Fri, Jul 30, 2010 at 2:39 PM, <[email protected]> wrote: >>>> >>>> All of the dev and GWT stuff LGTM. I don't really understand all the >>>> nuances of the logging plumbing, though. You might want a second pair >>>> of eyes, unless you're really confident in that part. >>>> >>>> Questions: >>>> >>>> 1) Why do you need to prefix the logger name at all? If we've got our >>>> own LogManager in DevMode, it can be its own isolated world right? It's >>>> very muddy to me to what extent this implementation creates an isolated >>>> logger world per client vs. tries to integrate with the JRE. The former >>>> option seems cleaner and wouldn't seem to require the unique thread id >>>> stuff. >>>> >>> We no longer have our own LogManager - that code/hack is now removed >>> because there's no way to reliably swap in the DevModeLogManager in a way >>> that works for GAE apps in dev mode (and we have no idea if other crazy >>> configurations would have the same issue). >>> >>>> >>>> 2) Are you subclassing LogManager on the back side to remove the >>>> aforementioned prefix? >>> >>> No - see the previous comment. The hack to use the DevModeLogManager by >>> setting the system property will not work with GAE apps. We can't use the >>> DevModeLogManager by bytecode rewriting because the primary class that >>> calls the LogManager is the Logger class, and the Logger class won't get >>> bytecode rewritten since it is a JRE class. >>> >>>> >>>> Seems like you'd want to, otherwise >>>> Logger.getName() doesn't return the right value relative to user >>>> expectation. >>> >>> >>> Yes - this is true - I mentioned this in the wave. Also - >>> LogManager.getLoggger() will not work as expected. In reality, >>> LogManager.getLogger() is rarely used - I'm considering just removing it >>> from the set of functions that GWT logging emulates. For Logger.getName(), >>> it's more complicated - for now, we're just living with the fact that the >>> logger name is different in Dev mode... >>> >>>> >>>> 3) Are there GWTTestCases for Logging that need update? >>>> >>>> >>>> http://gwt-code-reviews.appspot.com/725801/show >>> >> > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
