Question about some code in ClassLoaderContextSelector.

[Matt Sicker <bo...@gmail.com>]

For convenience, here is the code snippets I'm looking at.

    private static final AtomicReference<LoggerContext> CONTEXT = new
AtomicReference<LoggerContext>();

// ...

    private LoggerContext getDefault() {
        final LoggerContext ctx = CONTEXT.get();
        if (ctx != null) {
            return ctx;
        }
        CONTEXT.compareAndSet(null, new LoggerContext("Default"));
        return CONTEXT.get();
    }

My question here is why is this so lazily loaded? Is constructing a default
LoggerContext that expensive? I'm mainly asking because I'm working on a
BundleContextSelector for OSGi, and it's somewhat similar in some sense to
the ClassLoaderContextSelector. I'd like to keep code duplication to a
minimum, but I also need to understand the design decisions made here, too.

-- 
Matt Sicker <bo...@gmail.com>

Re: Question about some code in ClassLoaderContextSelector.

[Ralph Goers <rg...@apache.org>]

I suspect it is because a) the LoggerContext will need to be configured and probably doesn't have a configuration so it will just use the default and b) the default LoggerContext would probably never be used.

Ralph

> On Apr 28, 2014, at 4:36 PM, Matt Sicker <bo...@gmail.com> wrote:
> 
> For convenience, here is the code snippets I'm looking at.
> 
>     private static final AtomicReference<LoggerContext> CONTEXT = new AtomicReference<LoggerContext>();
> 
> // ...
> 
>     private LoggerContext getDefault() {
>         final LoggerContext ctx = CONTEXT.get();
>         if (ctx != null) {
>             return ctx;
>         }
>         CONTEXT.compareAndSet(null, new LoggerContext("Default"));
>         return CONTEXT.get();
>     }
> 
> My question here is why is this so lazily loaded? Is constructing a default LoggerContext that expensive? I'm mainly asking because I'm working on a BundleContextSelector for OSGi, and it's somewhat similar in some sense to the ClassLoaderContextSelector. I'd like to keep code duplication to a minimum, but I also need to understand the design decisions made here, too.
> 
> -- 
> Matt Sicker <bo...@gmail.com>