You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Ceki Gülcü <ce...@qos.ch> on 2002/12/09 17:23:00 UTC
Re: [vote] plans for turbine 2.3
> I agree on this. commons-logging is a "commons" package. I'd prefer to
> use as little from other projects (where we have no influence and
> vote) as possible.
>
> Regards
> Henning
Probably none of my business but you might want to read the following
before making up your mind. Note in particular the section on class loader
based dynamic discovery.
http://qos.ch/logging/thinkAgain.html
There is no such thing as a free lunch.
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] plans for turbine 2.3
Posted by Ceki Gülcü <ce...@qos.ch>.
At 10:04 10.12.2002 +0000, Henning P. Schmiedehausen wrote:
>Oh, I do. I simply don't see, why this might happen to Turbine. On
>Startup I initialize Log4J with the Properties configurator, then
>force all of my application code to use it by setting the necessary
>property at startup time. After this, I mainly use commons-logging to
>avoid going through the pains of having to do textual replacement on a
>bazillon files if I really want to switch logging systems.
I probably do not understand the Turbine model properly but couldn't you
face a problem when Turbine is embedded within some container, say Tomcat,
JBoss or whatever?
>ATM we do use Log4J. We only use it through an abstraction layer to
>make switching over easy. Both necessary jars (commons-logging and
>log4j) are on the classpath and if their classes are not loaded by the
>same class loader, then we're in deeper trouble anyway.
Paradoxically, having different jars loaded by different class loaders is
not usually an issue except directed accessibility problems. The problems
with commons-logging API occur when casting objects of the same class
loaded by different class loaders.
You seem to have made up your mind. All I can do is to warn you and wish
you good luck.
> Regards
> Henning
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] plans for turbine 2.3
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@qos.ch> writes:
>At 17:51 09.12.2002 +0000, Henning P. Schmiedehausen wrote:
>>Hi,
>>
>>thanks, the link is quite informative. However, some of your links
>>merely show that people either can't RTFM or simply load parts of
>>commons-logging from one jar and other parts from another jar which
>>probably has a different version and then run into problems. :-)
>Hmm, I am afraid you don't realize the severity of the problem. It's
>not users who can't RTFM or incompatible log4j versions. In java two
>classes loaded by different class loaders are totally *incompatible*
>even if the two classes are completely (i.e. bit-wise)
>identical. Thus, if you opt for c-l the behavior of your system will
>depend on external circumstances which you, as a developer, usually do not
>control. All solutions based on class loading are brittle and result
>in bugs hard (very hard) to solve.
Oh, I do. I simply don't see, why this might happen to Turbine. On
Startup I initialize Log4J with the Properties configurator, then
force all of my application code to use it by setting the necessary
property at startup time. After this, I mainly use commons-logging to
avoid going through the pains of having to do textual replacement on a
bazillon files if I really want to switch logging systems.
ATM we do use Log4J. We only use it through an abstraction layer to
make switching over easy. Both necessary jars (commons-logging and
log4j) are on the classpath and if their classes are not loaded by the
same class loader, then we're in deeper trouble anyway.
I do appreciate your comments, because they help me to decide how much
of the logging should be user configureable and how much should be
infrastructure-given.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] plans for turbine 2.3
Posted by Ceki Gülcü <ce...@qos.ch>.
At 17:51 09.12.2002 +0000, Henning P. Schmiedehausen wrote:
>Hi,
>
>thanks, the link is quite informative. However, some of your links
>merely show that people either can't RTFM or simply load parts of
>commons-logging from one jar and other parts from another jar which
>probably has a different version and then run into problems. :-)
Hmm, I am afraid you don't realize the severity of the problem. It's
not users who can't RTFM or incompatible log4j versions. In java two
classes loaded by different class loaders are totally *incompatible*
even if the two classes are completely (i.e. bit-wise)
identical. Thus, if you opt for c-l the behavior of your system will
depend on external circumstances which you, as a developer, usually do not
control. All solutions based on class loading are brittle and result
in bugs hard (very hard) to solve.
I will change the "think again" document to reflect your comments.
> Regards
> Henning
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] plans for turbine 2.3
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@qos.ch> writes:
> > I agree on this. commons-logging is a "commons" package. I'd prefer to
> > use as little from other projects (where we have no influence and
> > vote) as possible.
> >
> > Regards
> > Henning
>Probably none of my business but you might want to read the following
>before making up your mind.
Hi,
thanks, the link is quite informative. However, some of your links
merely show that people either can't RTFM or simply load parts of
commons-logging from one jar and other parts from another jar which
probably has a different version and then run into problems. :-)
While I personally would go with Log4J, many of our users, especially
those who must use one or the other container (either by specification
or company policy) will have to go with JDK 1.4, mainly because this
will become the "standard" in the commercial world. I don't want to
argue over the sanity of such a decision, mainly because my experience
is, that vendors will use everything that has a "standards label" or
"sun approved" sticking on it and JDK 1.4 has this and log4j has not.
So I'm simply proposing an agnostic approach: Support both and let the
user decide. Letting our userbase do "textual search and replace" on
the Turbine source isn't possible.
To me, this means commons-logging (I consider that the avalon logging
proposal is even further away from your ideas. :-))
The code that I plan to submit to Turbine will have a strong
(i.e. hardcoded. :-) preference for log4j. It looks like this:
[...]
String log4jFile = configuration.getString(LOG4J_CONFIG_FILE,
LOG4J_CONFIG_FILE_DEFAULT);
[...]
Properties p = new Properties();
p.load(new FileInputStream(log4jFile));
PropertyConfigurator.configure(p);
System.getProperties().setProperty(LogFactory.class.getName(),
Log4jFactory.class.getName());
[...]
I did omit some lines and this above is not really usable. But you get
the point.
Only the last two lines are really log4j specific. If you put the
JDK 1.4 factory class here, it'll use that as well.
And after this I use
Log log = LogFactory.getLog([xxx]);
in the Turbine code.
I have this as my log4j configuration file:
--- cut ---
log4j.rootLogger = INFO, application
log4j.category.org.apache.turbine = INFO, turbine
log4j.additivity.org.apache.turbine = false
log4j.category.org.apache.fulcrum = INFO, turbine
log4j.additivity.org.apache.fulcrum = false
log4j.category.org.apache.torque = INFO, torque
log4j.additivity.org.apache.torque = false
log4j.category.velocity = INFO, velocity
log4j.additivity.velocity = false
log4j.category.de.intermeta = INFO, application
log4j.additivity.de.intermeta = false
log4j.appender.turbine = org.apache.log4j.FileAppender
log4j.appender.turbine.file = ${applicationRoot}/logs/turbine.log
log4j.appender.turbine.layout = org.apache.log4j.PatternLayout
log4j.appender.turbine.layout.conversionPattern = %d [%t] %-5p %c - %m%n
log4j.appender.turbine.append = false
log4j.appender.torque = org.apache.log4j.FileAppender
log4j.appender.torque.file = ${applicationRoot}/logs/torque.log
log4j.appender.torque.layout = org.apache.log4j.PatternLayout
log4j.appender.torque.layout.conversionPattern = %d [%t] %-5p %c - %m%n
log4j.appender.torque.append = false
log4j.appender.velocity = org.apache.log4j.FileAppender
log4j.appender.velocity.file = ${applicationRoot}/logs/velocity.log
log4j.appender.velocity.layout = org.apache.log4j.PatternLayout
log4j.appender.velocity.layout.conversionPattern = %d [%t] %-5p %c - %m%n
log4j.appender.velocity.append = false
log4j.appender.application = org.apache.log4j.FileAppender
log4j.appender.application.file = ${applicationRoot}/logs/application.log
log4j.appender.application.layout = org.apache.log4j.PatternLayout
log4j.appender.application.layout.conversionPattern = %d [%t] %-5p %c - %m%n
log4j.appender.application.append = false
--- cut ---
After this, I get nice turbine.log, torque.log, velocity.log and
application.log with all the messages that I want and need.
And I have exactly this in my configuration file:
--- cut --- Turbine.properties --- cut ---
log4j.file = /WEB-INF/conf/Log4j.properties
--- cut --- Turbine.properties --- cut ---
Which references the service configuration file. I also plan to make an
optional embedded property configuration, i.e.
log4j.<log4j property> = xxx
in Turbine.properties.
> Note in particular the section on class loader based dynamic discovery.
IMHO this doesn't apply to Turbine. We must configure our logging
anyway, we don't want to configure it from the container. Or did I get
this wrong?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>