You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2003/10/28 12:29:31 UTC
more logging
While hoping that we can shelve the c-l discussion for a little while
to get some thinking done, I thought I'd share this.
I never believe in appealing to authority (or mob rule) is better than
a technical discussion (otherwise we'd all be using .NET under
windows), but I found this and thought some would enjoy. It's true
that he can go overboard, but there tends to be a grain of truth to
things, and generally driven by practical experience.
http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 28, 2003, at 03:08 PM, Jeff Schnitzer wrote:
> Geir Magnusson Jr. wrote:
>
>> While hoping that we can shelve the c-l discussion for a little while
>> to get some thinking done, I thought I'd share this.
>
> Oops :-)
>
>> http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
>
> Who is this guy?
>
> It's hard to imagine that he has a lot of experience with different
> appservers if he thinks that "In practice, the least painful
> deployment experience has always been with appservers that use almost
> no popular components, and that use their own internal logging system
> and other services, rather than a bunch of opensource products cobbled
> together by bits of frayed string." That's the stupidest thing I've
> heard all week. I'm sure almost anyone that has ever deployed
> applications on both JBoss and WebLogic would agree with me.
That's one of his standard patterns. He has to be taken with a
(sometimes big) grain of salt.
>
> The centralized, dynamic Log4J configuration in JBoss is one of its
> best features. The log4j xml file format isn't as clean as I would
> prefer, but you learn it once and then you can do anything. It beats
> the hell out of learning how to configure fifteen different loggers.
> Plus, the defaults work sensibly - I can unzip a fresh JBoss install
> and deploy my app into it and logs go the right places, at reasonable
> sensitivity, with rotation and everything!
Really? One of the best features of JBoss is it's logging? Go
Geronimo, Go!
>
> His point about JARhell is true though. Sun simply hasn't addressed
> the issue; Java was designed from the start to have lots of little
> standalone JVMs. You couldn't even write a modern appserver without
> the classloader features added in JDK1.2. But this has almost nothing
> to do with logging and everything to do with shared code. The only
> real solution to JARhell is to never reuse any code across
> applications, which based on his notion of the ideal appserver seems
> to be what he's advocating. Get to work on reimplementing...
> EVERYTHING, mr. blogger.
>
> BTW, Jive's solution is cheesey at best. It basically means
> "statically link everything". jive.jar is four megabytes, and
> includes obsolete versions of pretty much everything. There is a
> reason we invented dynamic linking and suffer with its problems... if
> every third-party library I used included a full copy of every one of
> *its* dependencies, our applications would be hundreds of megabytes
> each. And those classes occupy RAM too...
Yes, I've seen that trick more and more. When I was updating the
powered-by page this weekend, I was going and getting stuff that I was
putting on the page to check them out. Sometimes, I couldn't find
velocity. jar tf <distro.jar> and there it was...
Not a terribly healthy approach, but understandable - that's why I
still use the vel-dep.jar...
>
> Jeff
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by Jeff Schnitzer <je...@infohazard.org>.
Geir Magnusson Jr. wrote:
> While hoping that we can shelve the c-l discussion for a little while to
> get some thinking done, I thought I'd share this.
Oops :-)
> http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
Who is this guy?
It's hard to imagine that he has a lot of experience with different
appservers if he thinks that "In practice, the least painful deployment
experience has always been with appservers that use almost no popular
components, and that use their own internal logging system and other
services, rather than a bunch of opensource products cobbled together by
bits of frayed string." That's the stupidest thing I've heard all week.
I'm sure almost anyone that has ever deployed applications on both
JBoss and WebLogic would agree with me.
The centralized, dynamic Log4J configuration in JBoss is one of its best
features. The log4j xml file format isn't as clean as I would prefer,
but you learn it once and then you can do anything. It beats the hell
out of learning how to configure fifteen different loggers. Plus, the
defaults work sensibly - I can unzip a fresh JBoss install and deploy my
app into it and logs go the right places, at reasonable sensitivity,
with rotation and everything!
His point about JARhell is true though. Sun simply hasn't addressed the
issue; Java was designed from the start to have lots of little
standalone JVMs. You couldn't even write a modern appserver without the
classloader features added in JDK1.2. But this has almost nothing to do
with logging and everything to do with shared code. The only real
solution to JARhell is to never reuse any code across applications,
which based on his notion of the ideal appserver seems to be what he's
advocating. Get to work on reimplementing... EVERYTHING, mr. blogger.
BTW, Jive's solution is cheesey at best. It basically means "statically
link everything". jive.jar is four megabytes, and includes obsolete
versions of pretty much everything. There is a reason we invented
dynamic linking and suffer with its problems... if every third-party
library I used included a full copy of every one of *its* dependencies,
our applications would be hundreds of megabytes each. And those classes
occupy RAM too...
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 30, 2003, at 12:48 AM, Daniel L. Rall wrote:
> Jeff Schnitzer wrote:
>> Serge Knystautas wrote:
>>> Here is my favorite pro-log4j/anti-c-l rant:
>>>
>>> http://www.qos.ch/logging/thinkAgain.html
>> If the option of "just use Log4J directly in Velocity" was on the
>> table, I wouldn't complain. But I suspect a lot of other people
>> would....
>
> Now that's my kind of solution! ;)
I've suggested to Ceki that he create a lightweight jar, say
log4j-lw.jar, that does what c-l does but hopefully w/o the classloader
complexity... :D
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jeff Schnitzer wrote:
> Serge Knystautas wrote:
>
>> Here is my favorite pro-log4j/anti-c-l rant:
>>
>> http://www.qos.ch/logging/thinkAgain.html
>
> If the option of "just use Log4J directly in Velocity" was on the table,
> I wouldn't complain. But I suspect a lot of other people would....
Now that's my kind of solution! ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by Jeff Schnitzer <je...@infohazard.org>.
Serge Knystautas wrote:
> Here is my favorite pro-log4j/anti-c-l rant:
>
> http://www.qos.ch/logging/thinkAgain.html
If the option of "just use Log4J directly in Velocity" was on the table,
I wouldn't complain. But I suspect a lot of other people would....
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by Serge Knystautas <se...@lokitech.com>.
To ask some follow-ups...
Geir Magnusson Jr. wrote:
> Well, the dependency issue is important, but not the only one. It
> certainly isn't a show stopper. Others are versioning, as you noted,
> and then also what this inflicts on users is another in terms of having
> to change how their applications' logging works.
1. Dependency issues... what do you think are reasonable guidelines to
determine when to include code with velocity core? For example, the
1.3.1 velocity.jar includes anakia and texen, as well as some test
cases, so there does seem to be a way to justify bundling with velocity
(not counting velocity-dep).
> Versioning is something we have no real solution for other than careful
> management of what we do - just a fact of Java life.
Yeah, though to your point, dependencies create the opportunity for
versioning issues. Fortunately though, I can't say I've had much
real-world problems with that as library authors (and the JDK) have been
pretty good about limiting their changes.
> Another one, is the lock-in to an API. Right now it's a nice API, but
> the moment that log4j does something we want to steal, support or can't
> live w/o, we have a problem, right?
This is an interesting point. So it's not necessarily that
commons-logging is the LCD now, but it locks us into an LCD that can't grow.
The trade-off with this though is devoting extra effort to maintain
that. Your comparing a dependency on log4j with c-l, when to be fair it
should be compared with LogSystem. Granted you *can* LogSystem more
easily, but it hasn't much.
> I'll be the first to admit that we can improve LogSystem. I think we
> can do it to get the benefits people point out (like doing the
> isLEVELEnabled() to eliminate un-needed msg contruction, for example)
> w/o having to switch to c-l, especially if we can provide c-l support
> with an adapter, like we support everything else (and users support
> themselves).
Sure, although if you do a c-l adapter, you might as well make a log4j
adapter too. :)
> Well, if our impl is private, then we can, as time goes on, track
> whatever feature-set from whatever logger we want to. I'm assuming that
> it will be log4j, as the JDK moves with glacial speed and
> System.out.println() is a fairly complete API :). How will c-l track
> innovations in logging? I think it can't, because any feature that has
> no analogue in other loggers will not be able to be expressed in the c-l
> API, unless it has a set of log4j-specific methods, and then we're just
> using log4j anyway. This is sheer supposition - we have to wait and see.
Right, but a fair point.
Do you think Velocity has suffered though because there has been little
or no inclusion of new logging features over the past 1-2 years? Not to
suggest innovation happens at a consistent pace, but assessing the gap
between modern logging libraries and LogSystem that has emerged over the
past 1-2 years could suggest how much this will change in the future.
> I realize that this sounds like a pro-log4j rant, but it isn't. It's
> just that log4j introduced the logging pattern that c-l uses, log4j was
> more or less copied (badly) for the JDK1.4 logger, and the System.out
> guy has retired from Sun :)
>
> Seriously - I think that the log4j team will keep innovating, and I'd
> love to be able to take advantage of new things they invent.
>
> Again - I'm still going to read c-l and give it a good think. There's
> nothing I would enjoy more than coming over to the dark side.
Here is my favorite pro-log4j/anti-c-l rant:
http://www.qos.ch/logging/thinkAgain.html
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 28, 2003, at 04:10 PM, Serge Knystautas wrote:
> Geir Magnusson Jr. wrote:
>> While hoping that we can shelve the c-l discussion for a little while
>> to get some thinking done, I thought I'd share this.
>> I never believe in appealing to authority (or mob rule) is better
>> than a technical discussion (otherwise we'd all be using .NET under
>> windows), but I found this and thought some would enjoy. It's true
>> that he can go overboard, but there tends to be a grain of truth to
>> things, and generally driven by practical experience.
>> http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
>
> Geir,
>
> Many of your posts (seem to me) to be objecting to C-L because it
> created a dependency for Velocity. Is that a fair assumption? Would
> you say it's because it increases the jar you need for "just
> Velocity", because of intra-component versioning issues, or what else?
Well, the dependency issue is important, but not the only one. It
certainly isn't a show stopper. Others are versioning, as you noted,
and then also what this inflicts on users is another in terms of having
to change how their applications' logging works.
Versioning is something we have no real solution for other than careful
management of what we do - just a fact of Java life.
Another one, is the lock-in to an API. Right now it's a nice API, but
the moment that log4j does something we want to steal, support or can't
live w/o, we have a problem, right?
I'll be the first to admit that we can improve LogSystem. I think we
can do it to get the benefits people point out (like doing the
isLEVELEnabled() to eliminate un-needed msg contruction, for example)
w/o having to switch to c-l, especially if we can provide c-l support
with an adapter, like we support everything else (and users support
themselves).
I promised that I would give c-l a good read and a think, and I haven't
done that yet.
>
> Some of your posts also complain that C-L is a logging LCD. How
> significant is that to you compared to the dependency issue? Do you
> have an example of what you'd like to do with Velocity's logging that
> would be hard with C-L but easier with mods to LogSystem?
Well, if our impl is private, then we can, as time goes on, track
whatever feature-set from whatever logger we want to. I'm assuming
that it will be log4j, as the JDK moves with glacial speed and
System.out.println() is a fairly complete API :). How will c-l track
innovations in logging? I think it can't, because any feature that has
no analogue in other loggers will not be able to be expressed in the
c-l API, unless it has a set of log4j-specific methods, and then we're
just using log4j anyway. This is sheer supposition - we have to wait
and see.
I realize that this sounds like a pro-log4j rant, but it isn't. It's
just that log4j introduced the logging pattern that c-l uses, log4j was
more or less copied (badly) for the JDK1.4 logger, and the System.out
guy has retired from Sun :)
Seriously - I think that the log4j team will keep innovating, and I'd
love to be able to take advantage of new things they invent.
Again - I'm still going to read c-l and give it a good think. There's
nothing I would enjoy more than coming over to the dark side.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by Serge Knystautas <se...@lokitech.com>.
Geir Magnusson Jr. wrote:
> While hoping that we can shelve the c-l discussion for a little while to
> get some thinking done, I thought I'd share this.
>
> I never believe in appealing to authority (or mob rule) is better than a
> technical discussion (otherwise we'd all be using .NET under windows),
> but I found this and thought some would enjoy. It's true that he can go
> overboard, but there tends to be a grain of truth to things, and
> generally driven by practical experience.
>
> http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
Geir,
Many of your posts (seem to me) to be objecting to C-L because it
created a dependency for Velocity. Is that a fair assumption? Would
you say it's because it increases the jar you need for "just Velocity",
because of intra-component versioning issues, or what else?
Some of your posts also complain that C-L is a logging LCD. How
significant is that to you compared to the dependency issue? Do you
have an example of what you'd like to do with Velocity's logging that
would be hard with C-L but easier with mods to LogSystem?
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: more logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> While hoping that we can shelve the c-l discussion for a little while
> to get some thinking done, I thought I'd share this.
...
> http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
be sure to read the comments below the article too. they provide some insight
into the causal issues behind his complaint, not just the symptoms bothering
him. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org