You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Sam Ruby <ru...@us.ibm.com> on 2001/03/20 13:27:48 UTC
log4j changes impacting velocity
Background: jakarta-velocity is about to ship a release. It now uses
jakarta-log4j. It is often used in combination with other subprojects.
And some of the methods velocity uses from log4j were just removed.
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.
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);
[javac] ^
[javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:243: No variable SMTP_HOST_OPTION defined in class
org.apache.log4j.net.SMTPAppender.
[javac] appender.setOption(SMTPAppender.SMTP_HOST_OPTION, smtpHost);
[javac] ^
[javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:244: No variable FROM_OPTION defined in class
org.apache.log4j.net.SMTPAppender.
[javac] appender.setOption(SMTPAppender.FROM_OPTION, emailFrom);
[javac] ^
[javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:245: No variable TO_OPTION defined in class
org.apache.log4j.net.SMTPAppender.
[javac] appender.setOption(SMTPAppender.TO_OPTION, emailTo);
[javac] ^
[javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:246: No variable SUBJECT_OPTION defined in class
org.apache.log4j.net.SMTPAppender.
[javac] appender.setOption(SMTPAppender.SUBJECT_OPTION, emailSubject);
[javac] ^
[javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:247: No variable BUFFER_SIZE_OPTION defined in
class org.apache.log4j.net.SMTPAppender.
[javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize);
[javac] ^
[javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details.
[javac] 6 errors, 1 warning
- Sam Ruby
Re: log4j changes impacting velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.net
> >Developing for the web? See http://jakarta.apache.org/velocity/
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: log4j changes impacting velocity
Posted by Ceki Gülcü <cg...@qos.ch>.
Geir,
Sam is a pain in the butt but he also happens to be right. 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
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. geirm@optonline.net
>Developing for the web? See http://jakarta.apache.org/velocity/
Re: log4j changes impacting velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Anders Kristensen wrote:
>
> If these are all the errors you get it would be a small effort to modify
> log4j to support velocity in its current incarnation. The
>
> public void setMaxFileSize(long maxFileSize)
>
> should probably be added anyway, and then we're just talking about a
> bunch of constants and a single deprecated method on SMTPAppender.
> Unless I hear protests I'll make those changes sometime later today.
>
> Come to think of it, it would arguably have been better to make
> setOption deprecated everywhere instead of removing them. They're not
> usually invoked from app programs directly, though.
I appreciate the fast response!
But we are happy to move to whatever y'all suggest we do - we have no
users of this feature as of this moment - we wanted to make sure we
support the truely amazing log4j for our upcoming release.
The part that's failing is an adapter, not something core.
So we are happy to make Velocity comply with what you suggest.
The only think I would request as a user, is that we use features of the
released log4j, and not something in development that might change in
the near future.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: log4j changes impacting velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Anders Kristensen wrote:
>
> If these are all the errors you get it would be a small effort to modify
> log4j to support velocity in its current incarnation. The
>
> public void setMaxFileSize(long maxFileSize)
>
> should probably be added anyway, and then we're just talking about a
> bunch of constants and a single deprecated method on SMTPAppender.
> Unless I hear protests I'll make those changes sometime later today.
>
> Come to think of it, it would arguably have been better to make
> setOption deprecated everywhere instead of removing them. They're not
> usually invoked from app programs directly, though.
I appreciate the fast response!
But we are happy to move to whatever y'all suggest we do - we have no
users of this feature as of this moment - we wanted to make sure we
support the truely amazing log4j for our upcoming release.
The part that's failing is an adapter, not something core.
So we are happy to make Velocity comply with what you suggest.
The only think I would request as a user, is that we use features of the
released log4j, and not something in development that might change in
the near future.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: log4j changes impacting velocity
Posted by Ceki Gülcü <cg...@qos.ch>.
At 13:53 20.03.2001 +0100, Anders Kristensen wrote:
>If these are all the errors you get it would be a small effort to modify
>log4j to support velocity in its current incarnation. The
>
> public void setMaxFileSize(long maxFileSize)
>
>should probably be added anyway, and then we're just talking about a
>bunch of constants and a single deprecated method on SMTPAppender.
>Unless I hear protests I'll make those changes sometime later today.
Great!
>Come to think of it, it would arguably have been better to make
>setOption deprecated everywhere instead of removing them. They're not
>usually invoked from app programs directly, though.
Yes, setOption is not usually used directly, but when thousands of projects depend on a library, the "unusual" case still numbers in the hundreds... It took Sam a day to point out an unusual case!
Deprecating setOption seems the most reasonable course of action at this point. Ceki
>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.
>>
>> And some of the methods velocity uses from log4j were just removed.
>>
>> 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.
>>
>> 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);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:243: No variable SMTP_HOST_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.SMTP_HOST_OPTION, smtpHost);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:244: No variable FROM_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.FROM_OPTION, emailFrom);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:245: No variable TO_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.TO_OPTION, emailTo);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:246: No variable SUBJECT_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.SUBJECT_OPTION, emailSubject);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:247: No variable BUFFER_SIZE_OPTION defined in
>> class org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize);
>> [javac] ^
>> [javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details.
>> [javac] 6 errors, 1 warning
>>
>> - Sam Ruby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
Re: log4j changes impacting velocity
Posted by Ceki Gülcü <cg...@qos.ch>.
At 13:53 20.03.2001 +0100, Anders Kristensen wrote:
>If these are all the errors you get it would be a small effort to modify
>log4j to support velocity in its current incarnation. The
>
> public void setMaxFileSize(long maxFileSize)
>
>should probably be added anyway, and then we're just talking about a
>bunch of constants and a single deprecated method on SMTPAppender.
>Unless I hear protests I'll make those changes sometime later today.
Great!
>Come to think of it, it would arguably have been better to make
>setOption deprecated everywhere instead of removing them. They're not
>usually invoked from app programs directly, though.
Yes, setOption is not usually used directly, but when thousands of projects depend on a library, the "unusual" case still numbers in the hundreds... It took Sam a day to point out an unusual case!
Deprecating setOption seems the most reasonable course of action at this point. Ceki
>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.
>>
>> And some of the methods velocity uses from log4j were just removed.
>>
>> 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.
>>
>> 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);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:243: No variable SMTP_HOST_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.SMTP_HOST_OPTION, smtpHost);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:244: No variable FROM_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.FROM_OPTION, emailFrom);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:245: No variable TO_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.TO_OPTION, emailTo);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:246: No variable SUBJECT_OPTION defined in class
>> org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.SUBJECT_OPTION, emailSubject);
>> [javac] ^
>> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:247: No variable BUFFER_SIZE_OPTION defined in
>> class org.apache.log4j.net.SMTPAppender.
>> [javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize);
>> [javac] ^
>> [javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details.
>> [javac] 6 errors, 1 warning
>>
>> - Sam Ruby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: log4j changes impacting velocity
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
If these are all the errors you get it would be a small effort to modify
log4j to support velocity in its current incarnation. The
public void setMaxFileSize(long maxFileSize)
should probably be added anyway, and then we're just talking about a
bunch of constants and a single deprecated method on SMTPAppender.
Unless I hear protests I'll make those changes sometime later today.
Come to think of it, it would arguably have been better to make
setOption deprecated everywhere instead of removing them. They're not
usually invoked from app programs directly, though.
Anders
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.
>
> And some of the methods velocity uses from log4j were just removed.
>
> 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.
>
> 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);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:243: No variable SMTP_HOST_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.SMTP_HOST_OPTION, smtpHost);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:244: No variable FROM_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.FROM_OPTION, emailFrom);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:245: No variable TO_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.TO_OPTION, emailTo);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:246: No variable SUBJECT_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.SUBJECT_OPTION, emailSubject);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:247: No variable BUFFER_SIZE_OPTION defined in
> class org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize);
> [javac] ^
> [javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details.
> [javac] 6 errors, 1 warning
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
How about log4j.layout in configure file?
Posted by Jin Zhao <jz...@qcorps.com>.
I meet such a condition when configure log4j using an extended
PropertyConfigurator.
There are more than two dozens of Appenders use one same layout.
What I did is just copy and pasted them. However, evertime I make
some changes to the layout, I need to copy and past again.
Can we configure layout in the similar way as for appenders ? We may
define a layout first and let appenders to make reference to that
layout, just like we define an appender first and let categories to
reference it.
It seems need to change the current log4j source.
Or any work around for the condition I meet?
Any responses are appreciated.
Jin
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: log4j changes impacting velocity
Posted by Ceki Gülcü <cg...@qos.ch>.
Geir,
Sam is a pain in the butt but he also happens to be right. 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
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. geirm@optonline.net
>Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
How about log4j.layout in configure file?
Posted by Jin Zhao <jz...@qcorps.com>.
I meet such a condition when configure log4j using an extended
PropertyConfigurator.
There are more than two dozens of Appenders use one same layout.
What I did is just copy and paste them. However, everytime I make
changes to the layout, I need to copy and paste again.
Can we configure layout in the similar way as for appenders ? We may
define a layout first and let appenders to make reference to that
layout, just like we define an appender first and let categories to
reference it.
It seems need to change the current log4j source.
Or any work around for the condition I meet?
Any responses are appreciated.
Jin
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: log4j changes impacting velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: log4j changes impacting velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: log4j changes impacting velocity
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
If these are all the errors you get it would be a small effort to modify
log4j to support velocity in its current incarnation. The
public void setMaxFileSize(long maxFileSize)
should probably be added anyway, and then we're just talking about a
bunch of constants and a single deprecated method on SMTPAppender.
Unless I hear protests I'll make those changes sometime later today.
Come to think of it, it would arguably have been better to make
setOption deprecated everywhere instead of removing them. They're not
usually invoked from app programs directly, though.
Anders
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.
>
> And some of the methods velocity uses from log4j were just removed.
>
> 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.
>
> 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);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:243: No variable SMTP_HOST_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.SMTP_HOST_OPTION, smtpHost);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:244: No variable FROM_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.FROM_OPTION, emailFrom);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:245: No variable TO_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.TO_OPTION, emailTo);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:246: No variable SUBJECT_OPTION defined in class
> org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.SUBJECT_OPTION, emailSubject);
> [javac] ^
> [javac] D:\jakarta\jakarta-velocity\bin\src\org\apache\velocity\runtime\log\Log4JLogSystem.java:247: No variable BUFFER_SIZE_OPTION defined in
> class org.apache.log4j.net.SMTPAppender.
> [javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize);
> [javac] ^
> [javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details.
> [javac] 6 errors, 1 warning
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org