On Fri, Jul 30, 2010 at 4:01 PM, Unnur Gretarsdottir <[email protected]> wrote: > On Fri, Jul 30, 2010 at 3:57 PM, Unnur Gretarsdottir <[email protected]> > wrote: >> 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. >> >> > > (Sorry - this is coming in pieces because Ray was asking me about the > example I just sent out (I miss Wave)) > > Note that taking the approach you suggested to the extreme would be to > just swap out all calls of any kind to java.util.logging, in the > client code, and byte code rewrite it to my own implementation. > There's a discussion on the wave as to why we don't want to go this > route. > A - it's not trivial to do because my implementation classes are in > the java.util.logging package, so we'd have to duplicate the entire > emulation of the java.util.logging package (not impossible, but > definitely ugly) > B - Toby said that in AppEngine, they avoided this approach and > preferred the approach of just adding the prefix to create a > "pseudo-tree" of client loggers. C - It breaks "reflection" (so now rather than logger.getName() being off, logger.getClass.getName() is off). > > > >> >> >> >>> >>> >>>> >>>> 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
