Ceki Gülcü wrote:
>
> Geir,
>
> Sam is a pain in the butt but he also happens to be right.
I agree Sam is 100% right. I didn't argue with him - just chose one of
the options.
[ And while he can be a *royal* pain in the butt, he's *our* pain in the
butt, and I believe he is *not* being a pain in the butt this time. :) ]
> It is likely that other projects use log4j in a manner similar to
> velocity. The fact that log4j is not velocity's default logger
> does not change anything.We can't afford to break backward
> compatibility without making a serious effort to preserve
> it. Cheers, Ceki
All I was saying was :
"Don't do anything because of us specifically - do what *you* need to do
- we are flexible as we have no users yet."
I was just trying to make it clear that we have no investment yet in the
way we are using log4j, so if this is something particular to us, don't
worry, we can adapt.
If in the end you change log4j such that we don't have to do anything,
that's great.
Thanks for getting to this so quickly.
geir
> At 08:48 20.03.2001 -0500, Geir Magnusson Jr. wrote:
> >Sam Ruby wrote:
> >>
> >> Background: jakarta-velocity is about to ship a release. It now uses
> >> jakarta-log4j. It is often used in combination with other subprojects.
> >
> >We don't depend upon log4j - we just this week added support for users
> >to use log4j as the logger in Velocity through a log4j adapter to the
> >Velocity logger interface.
> >
> >But its not our default logger.
> >
> >> And some of the methods velocity uses from log4j were just removed.
> >
> >So we will change today to follow suit, I think. We have no users of
> >this feature so far, and if we do, they have been using it 1 day.
> >really.
> >
> >> This means that we either need to tell people not to upgrade to the latest
> >> log4j until everybody can (a logistical nightmare), get log4j to support
> >> the old interfaces for a period of time in a deprecated fashion, or we need
> >> to find a technique that velocity can use that works with both the prior
> >> and intended future releases of log4j.
> >
> >No, we'll switch :) I don't want to tell log4j what we need when we
> >have no users :)
> >
> >I think that if we, Velocity, intend to provide log4j support to our
> >users, then it is up to us to follow log4j and provide feedback to the
> >log4j developers so they can factor that into their decisions.
> >
> >
> >> If we don't do one of these three things, then the first log4j in the
> >> classpath will likely break somebody.
> >>
> >> Note: due to a stupid error on my part, the last gump run didn't pick up
> >> the recent changes to the project definitions. Here is the set of errrors
> >> that would have been found:
> >>
> >> compile:
> >> [javac] Compiling 150 source files to D:\jakarta\jakarta-velocity\bin\classes
> >> [javac]
>D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:162:
> Incompatible type for method. Can't convert
> >> int to java.lang.String.
> >> [javac] ((RollingFileAppender)appender).setMaxFileSize(fileSize);
> >>[SNIP]
> >
> >I heart gump.
> >
> >We'll get to that today.
> >
> >For clarity, which log4j should I build with, the release?
> >
> >geir
> >
> >--
> >Geir Magnusson Jr. [EMAIL PROTECTED]
> >Developing for the web? See http://jakarta.apache.org/velocity/
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
