Jetty logging initialization does not wait for :init

[kumarshantanu]

I initialize logging in a custom way in the :init function, which has no effect because Jetty already initializes SLF4j/Logback logging ahead of :init. lein-ring should not directly refer to the Jetty classes (to avoid logging initialization) until the :init function is executed.

[kumarshantanu]

Currently, I'm working around this issue by creating a file test/jetty-logging.properties with the following content:

org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog

This forces Jetty to log to STDERR, without initializing any other logging.

[MichaelBlume]

I think it should absolutely be possible to ensure that no side effects occur before the user's init is run. @weavejester is there any reason I'm missing to prefer the current behavior?

[weavejester]

None that I can think of.

[MichaelBlume]

Actually, @kumarshantanu can you give me some more help replicating this? How are you running your server? Are you deploying a war or a jar?

If you're building a war, jetty is fundamentally in charge and running our code when it wants to, so we may not be able to avoid the init that's giving you trouble (we may be able to, I'm not sure, would need to replicate first)

[kumarshantanu]

I deploy a simple uberjar, where the main class

1. reads config file
2. uses some of the config to initialize SLF4j/Logback
3. loads rest of the application that logs via SLF4j

in that order. My Logback config is complex and parameterized, however, let's take a simple example - I want the value of immediateFlush to be true in dev (using lein-ring) and false in prod (using http-kit), so I use a variable there (as in <immediateFlush>${immediate.flush}</immediateFlush>) that I must configure in lein-ring's :init function.

I will be happy to test any unreleased changes toward fixing this issue.

[MichaelBlume]

I'm a little confused -- Are you using `lein ring uberjar

…

On Tue, Aug 1, 2017 at 10:13 AM Shantanu Kumar ***@***.***> wrote: I deploy a simple uberjar, where the main class 1. reads config file 2. uses some of the config to initialize SLF4j/Logback 3. loads rest of the application that logs via SLF4j in that order. My Logback config is complex and parameterized, however, let's take a simple example - I want the value of immediateFlush <https://logback.qos.ch/manual/appenders.html> to be true in dev (using lein-ring) and false in prod (using http-kit), so I use a variable there (as in <immediateFlush>${immediate.flush}</immediateFlush>) that I must configure in lein-ring's :init function. I will be happy to test any unreleased changes toward fixing this issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#190 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMv1ZDCYvmayPYO_TSrurdpGX2wd01Kks5sT1y4gaJpZM4OfGaO> .

[MichaelBlume]

Sorry, sent prematurely

…

-- or are you managing your main class yourself and calling run-jetty?

On Thu, Aug 3, 2017 at 9:39 PM Michael Blume ***@***.***> wrote: I'm a little confused -- Are you using `lein ring uberjar On Tue, Aug 1, 2017 at 10:13 AM Shantanu Kumar ***@***.***> wrote: > I deploy a simple uberjar, where the main class > > 1. reads config file > 2. uses some of the config to initialize SLF4j/Logback > 3. loads rest of the application that logs via SLF4j > > in that order. My Logback config is complex and parameterized, however, > let's take a simple example - I want the value of immediateFlush > <https://logback.qos.ch/manual/appenders.html> to be true in dev (using > lein-ring) and false in prod (using http-kit), so I use a variable there > (as in <immediateFlush>${immediate.flush}</immediateFlush>) that I must > configure in lein-ring's :init function. > > I will be happy to test any unreleased changes toward fixing this issue. > > — > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub > <#190 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAMv1ZDCYvmayPYO_TSrurdpGX2wd01Kks5sT1y4gaJpZM4OfGaO> > . >

[kumarshantanu]

@MichaelBlume I use lein-ring only during development. For production, I create the uberjar using lein uberjar with my own AOT main class/namespace.

[MichaelBlume]

Ah, and the problem you are having is at development time?

[kumarshantanu]

Yes, that's right. I see the problem only at development time.

[MichaelBlume]

Ok, so I think with a bit of redirection I could ensure that init runs before any libraries are loaded. My concern is that this behavior will probably be different from what we see if a project is deployed to a jetty server with lein war, say. In general I'd prefer for the same project to behave the same way if run with various lein-ring commands.