I guess you can't please everybody. Sent from my iPad
> On Aug 7, 2015, at 2:00 AM, Xen <[email protected]> wrote: > > Quoting Ralph Goers <[email protected]>: > >> To achieve what you want just get the LoggerConfig you want to modify, >> change its level and then call the updateLoggers() method of the >> LoggerContext. > > I'm sorry. Maybe this seems lazy or unwarranted, but... > > The only quick resource I could find was StackOverflow. And I hate that site, > but it seemed to indicate that the public API as exposed in the javadocs is > not the complete API of these objects/interfaces? > > You are not telling me you have forged the Javadocs to be inconsistent with > the real classes, are you? :-/. > > Interface "org.apache.logging.log4j.spi.LoggerContext" has these four methods > (in the javadoc): > > - getExternalContext() > - getLogger() > - getLogger() > - hasLogger() > > But now a SO example shows this code: > > LoggerContext ctx = (LoggerContext) LogManager.getContext(false); > Configuration conf = ctx.getConfiguration(); > conf.getLoggerConfig(LogManager.ROOT_LOGGER_NAME).setLevel(Level.DEBUG); > ctx.updateLoggers(conf); > > These are also methods/techniques you have indicated or seem to have pointed > at, mr. Ralph Goers. But LoggerContext.getConfiguration() is then an > invisible or hidden method :). > > I wish I had found a better resource to discover this information (you can > never be sure about such unofficial or second hand sources, I guess). > > However, a quick decompile suggests that this is mistaken. And indeed, that > code doesn't compile. > > My apologies for finding such a devious way of verifying the veracity of your > words ;-). > > So. > > I checked out your sample at > log4j-samples/configuration/src/main/java/org/apache/logging/log4j/configuration/CustomConfiguration.java, > but it goes deeply into the core mechanics, as you may have indicated. > > However, even updateLoggers() doesn't exist: > > --- > LogTest.java:15: error: cannot find symbol > Configuration conf = ctx.getConfiguration(); > ^ > symbol: method getConfiguration() > location: variable ctx of type LoggerContext > LogTest.java:17: error: cannot find symbol > ctx.updateLoggers(conf); > ^ > symbol: method updateLoggers(Configuration) > location: variable ctx of type LoggerContext > 2 errors > --- > > There is nothing in the public API that gives access to this stuff. As > designed ;-) :) :P. > > Haha. My god. > > Okay. Core API. > > Aah, now we see all those classes exist there as well, expanded, full, but > how do we get there? :P. A simple thought comes to mind. But there is no > LogManager in there. I still don't know how to get a fucking Context :P lol. > > Such a separation is not really helpful or needed even, I guess, if those are > the words. If the Public API have methods that give access to the Core API, > then by agreement, if those methods return objects that are outside of the > Public API, they still mostly honour the contract that any /methods/ in the > Public API remain consistent and trusted across releases. So it would be a > "use at your own risk" but the essential method from within the Public API > that is being used does not break away from the consistency Interface > agreement that you have with your users. > > I may have found the answer in that Configurator.initialize() rewards a > LoggerContext and it seems to be as simple as providing a default name and a > config file location. From there on it would be possible to get a > LoggerContext (out of Core) and then the world should open up ;-D. > > But that means I should have left Default Land far behind and entered Anomaly > Land in full :D. Which is not all that shabby to me (or shappy). It means > that once I enter the Core I can /never/ get back to Public. I love being a > Red Pill guy but this seems rather drastic lol. > > Oh my. > > So the Public API is truly just a view onto the Core, or a Window onto the > Core that reveales a much smaller subset but provides a helper class > (LogManager) that seems to make life easier. However, the LoggerContext can > do the same. And one of the tasks of the LogManager is to provide a > LoggerContext anyway. > > There is just a difference between. > > org.apache.logging.log4j.spi.LoggerContext and > org.apache.logging.log4j.core.LoggerContext. > > But this /also/ means I only have to supply one jar file with my application! > It gets better all the time lol. > > Now, maybe I should go do something useful again. Wait! I have to test > something.. > > Oooh... the madness. By changing the line: > > import org.apache.logging.log4j.spi.LoggerContext; > > to > > import org.apache.logging.log4j.core.LoggerContext; > > now suddenly the example works. The LoggerContext you get returned from the > LogManager is just a plain Core LoggerContext, and an appropriate cast will > reveal its methods. > > The interface just shields many methods from the user. > > I was tricked! My apologies people, sometimes I am just a turd. > > Happy coding. > > Bye. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
