You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Curt Arnold <ca...@apache.org> on 2005/03/08 06:43:24 UTC
log4j 1.3 compatibility
I'm a log4j committer and have been investigating Gump projects that
have been configured to use log4j 1.2 instead of tracking the
development leading to log4j 1.3.
From a quick review of the mailing list and the code, the only thing
that appears to prevent the building velocity using log4j 1.3 is the
use of the org.apache.log4j.RollingFileAppender class which has been
replaced by the org.apache.log4j.rolling.RollingFileAppender class.
The new .rolling.RollingFileAppender is substantially improved,
unfortunately at the moment there is no bridge to allow code using the
log4j 1.2 RFA to work with 1.3.
I've floated a proposal on log4j-dev to add an emulator of the old RFA
in 1.3 that would delegate to the new RFA implementation. Would this
be sufficient to address the issues that motivated the setting the Gump
configuration to using log4j 1.2? Is abandoning log4j 1.2 an option?
Is there another approach you would recommend?
When I first looked at the Velocity code, I thought that its use of the
ancient, long deprecated, Category class would cause compilation
problems with log4j 1.3. However, I was surprised to learn that they
were still exposed in log4j 1.3, however that may be subject to change.
The Logger class replaced Category way back in 2001. The following
changes should work fine with any post-2001 version of log4j.
RCS file:
/home/cvspublic/jakarta-velocity/examples/logger_example/
Log4jCategoryExample.java,v
retrieving revision 1.3
diff -r1.3 Log4jCategoryExample.java
20c20
< import org.apache.log4j.Category;
---
> import org.apache.log4j.Logger;
44c44
< Category log = Category.getInstance( CATEGORY_NAME );
---
> Logger log = Logger.getLogger( CATEGORY_NAME );
Index:
src/java/org/apache/velocity/runtime/log/SimpleLog4JLogSystem.java
===================================================================
RCS file:
/home/cvspublic/jakarta-velocity/src/java/org/apache/velocity/runtime/
log/SimpleLog4JLogSystem.java,v
retrieving revision 1.11
diff -r1.11 SimpleLog4JLogSystem.java
21,22c21,22
< import org.apache.log4j.Category;
---
> import org.apache.log4j.Logger;
51c51
< protected Category logger = null;
---
> protected Logger logger = null;
70c70
< logger = Category.getInstance( categoryname );
---
> logger = Logger.getLogger( categoryname );
112c112
< logger = Category.getInstance(this.getClass().getName());
---
> logger = Logger.getLogger(this.getClass().getName());
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: log4j 1.3 compatibility
Posted by Curt Arnold <ca...@apache.org>.
I'm going to bow out now and unsubscribe from the list. At this point
as far as I can tell with the recent changes on log4j's CVS HEAD, the
existing velocity code will work with either 1.2 or the forthcoming
1.3. If there are any problems, please report them on the log4j-dev
mailing list or Bugzilla.
I'm out of my depth on the whole JCL debate. My comment on the
Bugzilla was strictly to point out an option of which I thought you
might be unaware. I was wrong on that point.
On Mar 10, 2005, at 3:03 AM, Henning P. Schmiedehausen wrote:
> Shinobu Kawai <sh...@gmail.com> writes:
>
>> Hey guys,
>
>> Might also be a good time to discuss Bug 19140 (RFE: switch to
>> commons-logging)
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=19140
>
>> Then, we can remove the whole Log4j dependency. :)
>
> I already have code for this. Stay tuned.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: log4j 1.3 compatibility
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Shinobu Kawai <sh...@gmail.com> writes:
>Hey guys,
>Might also be a good time to discuss Bug 19140 (RFE: switch to commons-logging)
> http://issues.apache.org/bugzilla/show_bug.cgi?id=19140
>Then, we can remove the whole Log4j dependency. :)
I already have code for this. Stay tuned.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Now you can start with implementation and integration and do the
requirements later". -- Prof. Dr. Dr. h.c. Manfred Broy about the new
german federal software development standard "V-Model XT"
(found at http://de.biz.yahoo.com/050207/299/4en0t.html)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: log4j 1.3 compatibility
Posted by Shinobu Kawai <sh...@gmail.com>.
Hey guys,
Might also be a good time to discuss Bug 19140 (RFE: switch to commons-logging)
http://issues.apache.org/bugzilla/show_bug.cgi?id=19140
Then, we can remove the whole Log4j dependency. :)
On Mon, 7 Mar 2005 23:43:24 -0600, Curt Arnold <ca...@apache.org> wrote:
> I'm a log4j committer and have been investigating Gump projects that
> have been configured to use log4j 1.2 instead of tracking the
> development leading to log4j 1.3.
>
> From a quick review of the mailing list and the code, the only thing
> that appears to prevent the building velocity using log4j 1.3 is the
> use of the org.apache.log4j.RollingFileAppender class which has been
> replaced by the org.apache.log4j.rolling.RollingFileAppender class.
> The new .rolling.RollingFileAppender is substantially improved,
> unfortunately at the moment there is no bridge to allow code using the
> log4j 1.2 RFA to work with 1.3.
>
> I've floated a proposal on log4j-dev to add an emulator of the old RFA
> in 1.3 that would delegate to the new RFA implementation. Would this
> be sufficient to address the issues that motivated the setting the Gump
> configuration to using log4j 1.2? Is abandoning log4j 1.2 an option?
> Is there another approach you would recommend?
>
> When I first looked at the Velocity code, I thought that its use of the
> ancient, long deprecated, Category class would cause compilation
> problems with log4j 1.3. However, I was surprised to learn that they
> were still exposed in log4j 1.3, however that may be subject to change.
> The Logger class replaced Category way back in 2001. The following
> changes should work fine with any post-2001 version of log4j.
>
> RCS file:
> /home/cvspublic/jakarta-velocity/examples/logger_example/
> Log4jCategoryExample.java,v
> retrieving revision 1.3
> diff -r1.3 Log4jCategoryExample.java
> 20c20
> < import org.apache.log4j.Category;
> ---
> > import org.apache.log4j.Logger;
> 44c44
> < Category log = Category.getInstance( CATEGORY_NAME );
> ---
> > Logger log = Logger.getLogger( CATEGORY_NAME );
> Index:
> src/java/org/apache/velocity/runtime/log/SimpleLog4JLogSystem.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-velocity/src/java/org/apache/velocity/runtime/
> log/SimpleLog4JLogSystem.java,v
> retrieving revision 1.11
> diff -r1.11 SimpleLog4JLogSystem.java
> 21,22c21,22
> < import org.apache.log4j.Category;
> ---
> > import org.apache.log4j.Logger;
> 51c51
> < protected Category logger = null;
> ---
> > protected Logger logger = null;
> 70c70
> < logger = Category.getInstance( categoryname );
> ---
> > logger = Logger.getLogger( categoryname );
> 112c112
> < logger = Category.getInstance(this.getClass().getName());
> ---
> > logger = Logger.getLogger(this.getClass().getName());
Best regards,
-- Shinobu
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org