[jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash

[Frederic Allard (JIRA)]

    [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017320#comment-13017320 ] 

Frederic Allard edited comment on JBLOGGING-111 at 11/5/14 9:55 AM:
--------------------------------------------------------------------

I can explain my use case and it's probably not the best solution to use the service loader explicitly, but I think you won't be able to fix our problem for backward compatibility on your side.

We have different legacy services using log4j-1.2.6 which is not supported by jboss logging. In our recent services, we use hibernate and slf4j to decouple the log4j-1.2.6 from our services. This way, we will be able to upgrade in the future the version of log4j. The tricky part is that log4j is deployed in the lib directory of the production Web server and we need to use it for the enterprise global logging configuration (homemade console).

The problem is in your priority to select the loggerProvider. You begin by looking if the Log4jFactory is in the classloader. And of course in our case, it will find log4j because it's provided by the server. But we use in reality SLF4J, which supports log4j-1.2.6 by putting the trace level logging in the debug level for example.

It would be better if you started by looking for SLF4J because it's the abstraction layer.

That way in our case, Hibernate would defer to slf4j instead of log4j and it would work without exception like : "TRACE not found."


was (Author: psychobaatezu):
I can explain my use case and it's probably not the best solution to use the service loader explicitly, but I think you won't be able to fix our problem for backward compatibility on your side.

We have different legacy services using log4j-1.2.6 which is not supported by jboss logging. In our recent services, we use hibernate and slf4j to decouple the log4j-1.2.6 from our services. This way, we will be able to upgrade in the future the version of log4j. The tricky part is that log4j is deployed in the lib directory of the production Web server and we need to use it for the enterprise global logging configuration (homemade console).

The problem is in your priority to select the loggerProvider. You begin by looking if the Log4jFactory is in the classloader. And of course in our case, it will find log4j because it's provided by the server. But we use in reality SLF4J, which supports log4j-1.2.6 by putting the trace level logging in the debug level for example.

It would be better if you started by looking for SLF4J because it's the abstraction layer.

That way in our case, Hibernate would defer to slf4j instead of log4j and it would worked without exception like : "TRACE not found."

> LoggerProvider configured with new ServiceLoader crash
> ------------------------------------------------------
>
>                 Key: JBLOGGING-111
>                 URL: https://issues.jboss.org/browse/JBLOGGING-111
>             Project: JBoss Logging
>          Issue Type: Bug
>    Affects Versions: 3.2.0.Beta1
>         Environment: Weblogic 10.3.2.0
> Configured in ejb jar, deployed by an ear file
>            Reporter: Frederic Allard
>            Assignee: James Perkins
>
> There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging.
> org.jboss.logging.LoggerProviders snippet :
> {code}
> // Next try for a service provider
>         try {
>             final ServiceLoader<LoggerProvider> loader = ServiceLoader.load(LoggerProvider.class, cl);
>             if (loader.iterator().hasNext()) {
>                 return loader.iterator().next();
>             }
>         } catch (Throwable ignore) {
>             // TODO consider printing the stack trace as it should only happen once
>         }
> {code}
> When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider.
> {code}
> java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers ""
> 	at java.util.ServiceLoader.fail(ServiceLoader.java:207)
> 	at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
> 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
> 	at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
> 	at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70)
> 	at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32)
> 	at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:29)
> 	at org.jboss.logging.Logger.getLogger(Logger.java:2177)
> 	at org.jboss.logging.Logger$1.run(Logger.java:2277)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241)
> 	at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228)
> 	at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:176)
>         ...
> {code}
> This is caused by the fact that all JBoss providers are not public classes and are instead package classes.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)