On 25/05/2016 12:26, Rémy Maucherat wrote:
> 2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> I've been looking at Bug 58588 [1]. It looks clear that the JULI extras
>> JARs no longer add value and I'm happy to remove them. That bug also
>> raises the question "How would users switch Tomcat's internal logging to
>> LOGBack, log4j2 or something else?".
>>
>> A quick look at the respective manuals suggest the following:
>>
>> LOGBack inserts itself via the root logger so that should be OK. In this
>> case we'd have:
>>
>> Tomcat -> JULI -> JUL -> LOGBack
>>
>> log4j2 replaces the LogManager. Providing a suitable selector (class
>> loader or JNDI was used) this should be fine. In this case we'd have:
>>
>> Tomcat -> JULI -> log4j2
>>
>> Thinking about all of this got me wondering. A primary driver for JULI
>> was the lack of class loader aware logging frameworks. This particular
>> problem appears to be solved (at least log4j and logback have solved
>> it). Do we want to consider a change to the logging framework? Possible
>> options include:
>>
>> 1. Simplified JULI that uses JUL directly but with our existing
>> LogManager and configuration extensions.
>>
>> 2. Native log4j2.
>>
>> 3. Use SLF4j API with log4j2 by default.
>>
>> 4. Use SLF4j API with logback by default.
>>
>> 5. Something else...
>>
>> 6. Do nothing.
>>
>> Currently, I'm leaning towards either doing nothing (what we have works)
>> or option 1. Options 2-5 all involved adding additional libraries which
>> I instinctively prefer not to do without a really good reason.
>>
>> Thoughts?
>>
>
> I'd vote 6. Switching is a lot of trouble with little benefit.
> What would be the changes for 1 exactly ? The thing is/was supposed to be
> simple already.
When I wrote the original e-mail I wasn't sure. All I had in my mind was
that Tomcat -> j.u.l. should be simpler than Tomcat -> CL -> j.u.l.
I've taken a quick look and what this means in terms of code is:
- We could remove o.a.juli.logging. All 92 lines of code.
- A huge amount of renaming (see the sample diff attached)
In terms of performance, the current CL layer always triggers an
exception to determine the current class and method. With direct to
j.u.l. it should be possible to avoid this if those values are not
required in the output. That could significantly speed up logging.
However, Tomcat doesn't log much unless it really has to so the real
performance benefit is probably minimal. And in debug situations, the
class and method can be very helpful.
To be sure of the performance impact, we'd need to try it. The changes
look to be fairly easy to do via global search and replace so I'll give
it a go locally and see what happens.
Mark
diff --git
a/java/org/apache/catalina/authenticator/jaspic/AuthConfigFactoryImpl.java
b/java/org/apache/catalina/authenticator/jaspic/AuthConfigFactoryImpl.java
index ba999dc..fb74840 100644
--- a/java/org/apache/catalina/authenticator/jaspic/AuthConfigFactoryImpl.java
+++ b/java/org/apache/catalina/authenticator/jaspic/AuthConfigFactoryImpl.java
@@ -28,6 +28,8 @@
import java.util.Map.Entry;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.logging.Level;
+import java.util.logging.Logger;
import javax.security.auth.message.config.AuthConfigFactory;
import javax.security.auth.message.config.AuthConfigProvider;
@@ -36,13 +38,11 @@
import org.apache.catalina.Globals;
import
org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.Provider;
import
org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.Providers;
-import org.apache.juli.logging.Log;
-import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.res.StringManager;
public class AuthConfigFactoryImpl extends AuthConfigFactory {
- private static final Log log =
LogFactory.getLog(AuthConfigFactoryImpl.class);
+ private static final Logger log =
Logger.getLogger(AuthConfigFactoryImpl.class.getName());
private static final StringManager sm =
StringManager.getManager(AuthConfigFactoryImpl.class);
private static final String CONFIG_PATH = "conf/jaspic-providers.xml";
@@ -88,8 +88,8 @@
private String doRegisterConfigProvider(String className,
@SuppressWarnings("rawtypes") Map properties, String layer, String
appContext,
String description) {
- if (log.isDebugEnabled()) {
- log.debug(sm.getString("authConfigFactoryImpl.registerClass",
+ if (log.isLoggable(Level.FINE)) {
+ log.fine(sm.getString("authConfigFactoryImpl.registerClass",
className, layer, appContext));
}
Class<?> clazz;
@@ -118,8 +118,8 @@
@Override
public String registerConfigProvider(AuthConfigProvider provider, String
layer,
String appContext, String description) {
- if (log.isDebugEnabled()) {
- log.debug(sm.getString("authConfigFactoryImpl.registerInstance",
+ if (log.isLoggable(Level.FINE)) {
+ log.fine(sm.getString("authConfigFactoryImpl.registerInstance",
provider.getClass().getName(), layer, appContext));
}
String registrationID = getRegistrarionID(layer, appContext);
@@ -181,8 +181,8 @@
private void loadPersistentRegistrations() {
synchronized (CONFIG_FILE_LOCK) {
- if (log.isDebugEnabled()) {
- log.debug(sm.getString("authConfigFactoryImpl.load",
+ if (log.isLoggable(Level.FINE)) {
+ log.fine(sm.getString("authConfigFactoryImpl.load",
CONFIG_FILE.getAbsolutePath()));
}
if (!CONFIG_FILE.isFile()) {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
