Hi Kolinko,

On Thu, May 2, 2013 at 6:26 PM, Konstantin Kolinko
<knst.koli...@gmail.com>wrote:

> 2013/5/2 Lakmali Baminiwatta <lakmali8...@gmail.com>:
> > Hi all,
> >
> > I am using Tomcat Juli.
> >
> > In org.apache.juli.ClassLoaderLogManager class, when reading the
> > configuration from the specified classLoaders through below method,
> >
> > *readConfiguration(ClassLoader classLoader)*
> > *
> > *
> > *It checks whether the current classLoader and System Class Loader is
> same
> > before reading the global logging configuration file. *
> > *
> > *
> >  if ((is == null) && *(classLoader ==
> ClassLoader.getSystemClassLoader()*))
> > {
> >             String configFileStr =
> > System.getProperty("java.util.logging.config.file");
> >             if (configFileStr != null) {
> >                 try {
> >                     is = new FileInputStream(replace(configFileStr));
> >                 } catch (IOException e) {
> >                     // Ignore
> >                 }
> >             }
> >             // Try the default JVM configuration
> >             if (is == null) {
> >                 File defaultFile = new File(new
> > File(System.getProperty("java.home"), "lib"),
> >                     "logging.properties");
> >                 try {
> >                     is = new FileInputStream(defaultFile);
> >                 } catch (IOException e) {
> >                     // Critical problem, do something ...
> >                 }
> >             }
> >         }
> >
> > I am really greatful if the reason why such a check [*classLoader ==
> > ClassLoader.getSystemClassLoader()*] is required, can be clarified?
> >
> > I am asking this because, I have a scenario which this condition fails
> due
> > to unequality of the classLoaders. But removing that check fixed the
> issue
> > and logging happens as expected.
> >
> > Appreciate if you can point me out the possibility of an issue with my
> > change or why that check is there.
> >
>
> Thanks for your explanation.

>
> The code there tries
> a) per-webapp configuration (aka per-classloader configuration)
> which is given by classLoader.getResourceAsStream("logging.properties")
>
> b) global configuration, which is specified by
> System.getProperty("java.util.logging.config.file") setting.
> That is the fragment that you cited.
>
> c) asks parent classloader
>
> Note that c) also happens in different places like in getProperty(String).
>
> The condition in b) that you are asking about is needed for c) to
> work. That is, the global configuration is read only by the top
> classloader in the chain. If you change that, there will be several
> copies of configuration,  such as several Loggers writing to the same
> file in parallel.
>

ok, understood the requirement of that condition.

>
> It seems that there is assumption that the root of classloaders chain
> is the system classloader. Is that not true for you?
>

Yes, system classloader and webapp classloaders are in seperate hierachies.


>
> I should also note that "getClassLoaderInfo(current)" during c)
> results in readConfiguration( ) call for that parent classloader,  and
> "getClassLoaderInfo(null)" would read the one for the system
> classloader.  So maybe one has to add such call to the loop in c)
> instead of fixing the condition in b), but I cannot say without
> looking how this configuration is used in other methods.
>

So what you suggest is to pass null to the , getClassLoaderInfo instead of
current as below? It also gave the expected logging.

            if (is == null) {
            // Retrieve the root logger of the parent classloader instead
            ClassLoader current = classLoader.getParent();
            ClassLoaderLogInfo info = null;
            while (current != null && info == null) {
                info = getClassLoaderInfo(null);
                current = current.getParent();
            }
            if (info != null) {
                localRootLogger.setParent(info.rootNode.logger);
            }
        }

Thanks,
Lakmali

>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to