Hello Alexey,
we changed our decision and now make use of the jul -> slf4j bridge as we found
more components that otherwise would need to be adapted to slf4j. This way we
can remove our current logging modifications from Grizzly and catch all the
future projects that still use jul and have to be integrated. Furthermore we
make use of slf4j's LevelChangePropagator to hopefully eliminate performance
problems. Future tests will have to prove this though.
Adding a logging abstraction to Grizzly where a slf4j based implementation does
more or less what the existing jul -> slf4j bridge does without making use of
the advanced features doesn't look really worthwile to me. We had such an
adapter for jul -> jcl and looked at implementing a jul -> slf4j variant which
lead to my initial e-mail.
We tried
> On 09 December 2013 at 22:46 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
> wrote:
>
>
> Hi Marc,
>
> we didn't have any plans w.r.t. logging changes.
> We briefly discussed this with Ryan... we're agree that standard Java
> logging API is far from being perfect, on other side we don't want to
> introduce hard dependencies on 3rd party projects.
> So the only solution we see at the moment is to introduce a Grizzly
> logging abstraction, which default implementation will use standard Java
> logging framework, but at the same time it would be possible to provide
> implementations backed by SLF4J or different logging framework.
>
> What do you think? Will appreciate your feedback and help.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On 06.12.13 04:38, Marc Arens wrote:
> > Hello,
> >
> > i just wanted to ask if there are any thoughts/plans about moving grizzly
> > from
> > java.util.logging to something like slf4j?
> > We already had to adapt the current
> > org.glassfish.grizzly.Grizzly.logger(Class)
> > method to return a commons.logging based logger to fulfill customer
> > requirements
> > but are currently moving our logging from JCL to SLF4J.
> > I'll have a look at the slf4j migrator http://www.slf4j.org/migrator.html as
> > we'd like to avoid the java.util.logging bridge because of the performance
> > issues mentioned at [1] but i would like to hear your opinions on this.
> >
> > [1] http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
> >
> > Best regards,
> > Marc
>
Best regards,
Marc