Re: Converting custom Appender to Log4j v2
Have you tried running under the debugger with a breakpoint at setFile()?
That should show you the call stack and whether you really got there
through that main. If it was then that main would show up in the list of
processes that are running, although you might not be able to tell how it
was invoked.
You should also be able to disassemble SandcastleService. I know Ihtellij
does that automatically and I expect other IDEs do as well.
Ralph
> On Sep 9, 2022, at 7:49 AM, Joel Griffith wrote:
>
> I've followed my application's usage of the `setFile()` command up the
> chain of invocations to try to figure out what it's doing so that I can
> implement something different for Log4j v2.
>
> Ultimately, the function is invoked by the `main()` method of a file
> `SandcastleService.jar`, where it is used to change the FileAppender output
> file of the Root Logger. I don't know enough about Java to investigate
> further, and I need help.
>
> It is obvious from the structure and nature of the library I'm working on
> that no one was ever expected to type `$ java SandcastleService` at the
> command line to invoke this, which is the only use of the `main()` method I
> know about.
>
> When the library is built, it is part of a JAR file `beaches.jar`. That
> JAR file has a manifest that includes a field `Main-Class:
> org.file.path.tides.scheduler`. So, `SandcastleService.main()` is not used
> for that purpose.
>
> Does anyone have any ideas for how I can figure out what
> `SandcastleService.main()` is doing with the Log4j v1 `setFile()` method?
> The string "SandcastleService.main(" doesn't appear anywhere else in the
> code base, so it's not directly invoked anywhere.
>
> Joel
>
>
> On Fri, Aug 26, 2022 at 6:21 PM Ralph Goers
> wrote:
>
>>
>>
>>> On Aug 26, 2022, at 1:45 PM, Joel Griffith wrote:
>>>
>>>
>>> Its purpose is to change the output file of the Root Logger's
>> FileAppender
>>> (we assume it has only one), or to add a new FileAppender to the Root
>>> Logger if one does not already exist. I can eliminate this use of
>>> FileAppender.setFile() by rewriting the entire function for Log4j v2.
>> How
>>> changing a FileAppender's output file done in v2? I cannot find any hint
>>> online. I read some about Lookups, which someone mentioned, but the only
>>> page I found was all configuration, no code.
>>>
>>
>> The only way to change the output destination would be to create a new
>> Appender with the new target file and replace the current appender with it.
>> The file attribute of a FileAppender in Log4j 2 is immutable. In the
>> RollingFileAppender
>> you cannot change the name of the target file but the file being written
>> to is
>> moved and a new file with the same name is created when a rollover occurs.
>>
>> In order to have the ability to change the file at any time locking would
>> be
>> required and Log4j 2 minimizes locking wherever it can.
>>
>> But rather than just copying code and trying to figure out how to emulate
>> it
>> with Log4j 2 it would be better to figure out what the requirement is that
>> is
>> driving the need to change the file name and then ask how that requirement
>> can be met.
>>
>> Ralph
>>
>>
>>
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>>
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Converting custom Appender to Log4j v2
I've followed my application's usage of the `setFile()` command up the
chain of invocations to try to figure out what it's doing so that I can
implement something different for Log4j v2.
Ultimately, the function is invoked by the `main()` method of a file
`SandcastleService.jar`, where it is used to change the FileAppender output
file of the Root Logger. I don't know enough about Java to investigate
further, and I need help.
It is obvious from the structure and nature of the library I'm working on
that no one was ever expected to type `$ java SandcastleService` at the
command line to invoke this, which is the only use of the `main()` method I
know about.
When the library is built, it is part of a JAR file `beaches.jar`. That
JAR file has a manifest that includes a field `Main-Class:
org.file.path.tides.scheduler`. So, `SandcastleService.main()` is not used
for that purpose.
Does anyone have any ideas for how I can figure out what
`SandcastleService.main()` is doing with the Log4j v1 `setFile()` method?
The string "SandcastleService.main(" doesn't appear anywhere else in the
code base, so it's not directly invoked anywhere.
Joel
On Fri, Aug 26, 2022 at 6:21 PM Ralph Goers
wrote:
>
>
> > On Aug 26, 2022, at 1:45 PM, Joel Griffith wrote:
> >
> >
> > Its purpose is to change the output file of the Root Logger's
> FileAppender
> > (we assume it has only one), or to add a new FileAppender to the Root
> > Logger if one does not already exist. I can eliminate this use of
> > FileAppender.setFile() by rewriting the entire function for Log4j v2.
> How
> > changing a FileAppender's output file done in v2? I cannot find any hint
> > online. I read some about Lookups, which someone mentioned, but the only
> > page I found was all configuration, no code.
> >
>
> The only way to change the output destination would be to create a new
> Appender with the new target file and replace the current appender with it.
> The file attribute of a FileAppender in Log4j 2 is immutable. In the
> RollingFileAppender
> you cannot change the name of the target file but the file being written
> to is
> moved and a new file with the same name is created when a rollover occurs.
>
> In order to have the ability to change the file at any time locking would
> be
> required and Log4j 2 minimizes locking wherever it can.
>
> But rather than just copying code and trying to figure out how to emulate
> it
> with Log4j 2 it would be better to figure out what the requirement is that
> is
> driving the need to change the file name and then ask how that requirement
> can be met.
>
> Ralph
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
Re: Converting custom Appender to Log4j v2
> On Aug 26, 2022, at 1:45 PM, Joel Griffith wrote: > > > Its purpose is to change the output file of the Root Logger's FileAppender > (we assume it has only one), or to add a new FileAppender to the Root > Logger if one does not already exist. I can eliminate this use of > FileAppender.setFile() by rewriting the entire function for Log4j v2. How > changing a FileAppender's output file done in v2? I cannot find any hint > online. I read some about Lookups, which someone mentioned, but the only > page I found was all configuration, no code. > The only way to change the output destination would be to create a new Appender with the new target file and replace the current appender with it. The file attribute of a FileAppender in Log4j 2 is immutable. In the RollingFileAppender you cannot change the name of the target file but the file being written to is moved and a new file with the same name is created when a rollover occurs. In order to have the ability to change the file at any time locking would be required and Log4j 2 minimizes locking wherever it can. But rather than just copying code and trying to figure out how to emulate it with Log4j 2 it would be better to figure out what the requirement is that is driving the need to change the file name and then ask how that requirement can be met. Ralph - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Converting custom Appender to Log4j v2
I've found this code which also uses the missing FileAppender.setFile()
method:
```
public static void setFileAppenderOutput(String filename) {
File file = new File(filename);
FileAppender fa = null;
Enumeration e = Logger.getRootLogger().getAllAppenders();
while (e.hasMoreElements()) {
Appender a = (Appender) e.nextElement();
if ((FileAppender.class).isAssignableFrom(a.getClass())) {
fa = (FileAppender) a;
}
}
if (fa == null) {
fa = new FileAppender();
Layout l = new PatternLayout("%d{-MM-dd HH:mm:ss,SSSZ} %-5p
%c{1} %m%n");
fa.setLayout(l);
fa.setThreshold(Level.DEBUG);
Logger.getRootLogger().addAppender(fa);
}
fa.setFile(file.getAbsolutePath());
}
```
Its purpose is to change the output file of the Root Logger's FileAppender
(we assume it has only one), or to add a new FileAppender to the Root
Logger if one does not already exist. I can eliminate this use of
FileAppender.setFile() by rewriting the entire function for Log4j v2. How
changing a FileAppender's output file done in v2? I cannot find any hint
online. I read some about Lookups, which someone mentioned, but the only
page I found was all configuration, no code.
Joel
On Wed, Aug 24, 2022 at 3:51 PM Ralph Goers
wrote:
> In Log4j 1.2 a Category was the base class for a Logger. So this would
> simply be
> looking for all the Appenders attached to the Logger. If a Category/Logger
> has no
> Appenders then it searches the parent hierarchy until it finds one. Note
> that even
> if it finds one if the Logger is configured as additive (the default) then
> the event will
> also be passed to the Logger’s parents.
>
> I haven’t looked at the code recently but I’d bet getAllAppenders only
> returns the
> Appenders directly attached to the Logger/Category.
>
> Ralph
>
> > On Aug 23, 2022, at 1:15 PM, Joel Griffith wrote:
> >
> > I'm still trying to parse some Log4j v1 code for the update, and I hit
> > something I can't find.
> >
> > The docs here:
> >
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#getAllAppenders()
> > say that the Logger.getAllAppenders() method "Get[s] the appenders
> > contained in this category as an Enumeration." There is no definition of
> > what it means for an appender to be "contained in" a category, however,
> so
> > I'm unable to predict exactly what the method will return.
> >
> > As precisely as possible, what defines the set of appenders that are
> > "contained in" a category like a logger? In particular, does a child
> > logger contain appenders assigned to its parent? Does a parent logger
> > contain appenders assigned to its child?
> >
> > Thanks,
> > Joel
> >
> >
> >
> >
> >
> > On Tue, Aug 16, 2022 at 3:37 AM Markus Dimmerling <
> markus.dimmerl...@ppi.de>
> > wrote:
> >
> >>> As for delaying creating the file, that can be accomplished just by
> >> specifying createOnDemand=“true”.
> >> Keep in mind, that this is not true for parent folders. Parent folders
> >> will be created on initialization even before createOnDemand. (At least
> for
> >> RollingFileAppenders)
> >>
> >> This was my workaround for that issue: A RoutingAppender wrapping the
> >> RollingFileAppender and routing all logging to null until the value is
> not
> >> empty anymore.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >> fileName="${ctx: parent.folder}/Logging.log"
> >> filePattern="${ctx: parent.folder}/Logging.log.%i"
> >> createOnDemand="true">
> >>...
> >>
> >>
> >>
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
Re: Converting custom Appender to Log4j v2
In Log4j 1.2 a Category was the base class for a Logger. So this would simply
be
looking for all the Appenders attached to the Logger. If a Category/Logger has
no
Appenders then it searches the parent hierarchy until it finds one. Note that
even
if it finds one if the Logger is configured as additive (the default) then the
event will
also be passed to the Logger’s parents.
I haven’t looked at the code recently but I’d bet getAllAppenders only returns
the
Appenders directly attached to the Logger/Category.
Ralph
> On Aug 23, 2022, at 1:15 PM, Joel Griffith wrote:
>
> I'm still trying to parse some Log4j v1 code for the update, and I hit
> something I can't find.
>
> The docs here:
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#getAllAppenders()
> say that the Logger.getAllAppenders() method "Get[s] the appenders
> contained in this category as an Enumeration." There is no definition of
> what it means for an appender to be "contained in" a category, however, so
> I'm unable to predict exactly what the method will return.
>
> As precisely as possible, what defines the set of appenders that are
> "contained in" a category like a logger? In particular, does a child
> logger contain appenders assigned to its parent? Does a parent logger
> contain appenders assigned to its child?
>
> Thanks,
> Joel
>
>
>
>
>
> On Tue, Aug 16, 2022 at 3:37 AM Markus Dimmerling
> wrote:
>
>>> As for delaying creating the file, that can be accomplished just by
>> specifying createOnDemand=“true”.
>> Keep in mind, that this is not true for parent folders. Parent folders
>> will be created on initialization even before createOnDemand. (At least for
>> RollingFileAppenders)
>>
>> This was my workaround for that issue: A RoutingAppender wrapping the
>> RollingFileAppender and routing all logging to null until the value is not
>> empty anymore.
>>
>>
>>
>>
>>
>>
>>
>> > fileName="${ctx: parent.folder}/Logging.log"
>> filePattern="${ctx: parent.folder}/Logging.log.%i"
>> createOnDemand="true">
>>...
>>
>>
>>
>>
>>
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Converting custom Appender to Log4j v2
I'm still trying to parse some Log4j v1 code for the update, and I hit
something I can't find.
The docs here:
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#getAllAppenders()
say that the Logger.getAllAppenders() method "Get[s] the appenders
contained in this category as an Enumeration." There is no definition of
what it means for an appender to be "contained in" a category, however, so
I'm unable to predict exactly what the method will return.
As precisely as possible, what defines the set of appenders that are
"contained in" a category like a logger? In particular, does a child
logger contain appenders assigned to its parent? Does a parent logger
contain appenders assigned to its child?
Thanks,
Joel
On Tue, Aug 16, 2022 at 3:37 AM Markus Dimmerling
wrote:
> > As for delaying creating the file, that can be accomplished just by
> specifying createOnDemand=“true”.
> Keep in mind, that this is not true for parent folders. Parent folders
> will be created on initialization even before createOnDemand. (At least for
> RollingFileAppenders)
>
> This was my workaround for that issue: A RoutingAppender wrapping the
> RollingFileAppender and routing all logging to null until the value is not
> empty anymore.
>
>
>
>
>
>
>
> fileName="${ctx: parent.folder}/Logging.log"
>filePattern="${ctx: parent.folder}/Logging.log.%i"
>createOnDemand="true">
> ...
>
>
>
>
>
RE: Converting custom Appender to Log4j v2
> As for delaying creating the file, that can be accomplished just by > specifying createOnDemand=“true”. Keep in mind, that this is not true for parent folders. Parent folders will be created on initialization even before createOnDemand. (At least for RollingFileAppenders) This was my workaround for that issue: A RoutingAppender wrapping the RollingFileAppender and routing all logging to null until the value is not empty anymore. ...
Re: Converting custom Appender to Log4j v2
This code appears to doing two things:
1. Provide a custom setFile method to set the file name, buffer size,
and the append and bufferedIO flags. It also always sets immediateFlush
to false.
2. Only opens the file when fileNameConfigured is called.
Other than that it is just the standard FileAppender.
Given that, there really is no need for this in Log4j2.
I haven’t seen the code that calls setFile but you can use custom
Lookups if required to provide the values for the file name, buffer
size and flags. To be honest though, I’d be surprised if custom
Lookups are really required. I’d guess you can probably accomplish
what you need with the standard lookups.
As for delaying creating the file, that can be accomplished just by
specifying createOnDemand=“true”.
Ralph
.
> On Aug 15, 2022, at 10:09 AM, Joel Griffith wrote:
>
> I guess I can. 90 lines isn't too big for an email, is it?
>
> * start code *
>
> import java.io.BufferedWriter;
> import java.io.File;
> import java.io.FileNotFoundException;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.Writer;
>
> import org.apache.logging.log4j.core.appender.FileAppender;
> import org.apache.logging.log4j.status.StatusLogger;
>
> public class LazyFileAppender extends FileAppender {
>/**
> * Override FileAppender.setFile to avoid creating an empty log file
> before
> * the code has a chance to customize the file name.
> */
>public synchronized void setFile(String fileName, boolean append,
> boolean bufferedIO, int bufferSize)
>throws IOException {
>StatusLogger.debug("setFile called: {}, {}", fileName, append);
>
>if (this.qw != null) {
>return;
>}
>
>// set a stdout writer just in case
>reset();
>Writer fw = createWriter(System.out);
>this.setQWForFiles(fw);
>
>this.fileName = fileName;
>this.fileAppend = append;
>this.bufferedIO = bufferedIO;
>this.bufferSize = bufferSize;
>StatusLogger.debug("setFile ended");
>}
>
>/**
> * Calling this method will signal this class that the log file name
> * has been configured and that the file can now be opened.
> * @throws IOException
> */
>public void fileNameConfigured() throws IOException {
>StatusLogger.debug("fileNameConfigured called");
>
>// It does not make sense to have immediate flush and bufferedIO.
>if (this.bufferedIO) {
>setImmediateFlush(false);
>}
>
>// Save file name since reset() sets it to null
>String fileName = this.fileName;
>
>// Set to null to prevent parent class from closing System.out
>this.qw = null;
>reset();
>this.fileName = fileName;
>FileOutputStream ostream = null;
>try {
>//
>// attempt to create file
>//
>ostream = new FileOutputStream(this.fileName, this.fileAppend);
>}
>catch (FileNotFoundException ex) {
>//
>// if parent directory does not exist then
>// attempt to create it and try to create file
>// see bug 9150
>//
>String parentName = new File(this.fileName).getParent();
>if (parentName != null) {
>File parentDir = new File(parentName);
>if (!parentDir.exists() && parentDir.mkdirs()) {
>ostream = new FileOutputStream(this.fileName,
> this.fileAppend);
>}
>else {
>throw ex;
>}
>}
>else {
>throw ex;
>}
>}
>Writer fw = createWriter(ostream);
>if (this.bufferedIO) {
>fw = new BufferedWriter(fw, this.bufferSize);
>}
>this.setQWForFiles(fw);
>writeHeader();
>StatusLogger.debug("fileNameConfigured ended");
>}
> }
>
> * end code *
>
> Joel
>
> On Mon, Aug 15, 2022 at 11:33 AM Ralph Goers
> wrote:
>
>> This is a problem. Log4j supports Lookups, which usually eliminate the
>> need
>> to override things like setFile since you can create a custom lookup to do
>> whatever needs to be done.
>>
>> Is there any chance you can post the code so we can figure out what it
>> does?
>>
>> Ralph
>>
>>> On Aug 15, 2022, at 8:21 AM, Joel Griffith wrote:
>>>
>>> I don't know what the old appender does, in part because I'm not a good
>>> enough programmer to interpret it, and in part because the bulk of what
>> it
>>> does is contained in the source code of the classes that it subclasses,
>> and
>>> I don't have that v1 source code.
>>>
>>> One thing I've figured out that it does is override the v1 FileAppender's
>>> setFile() method. I've also figured out that the v2 FileAppender doesn't
>>> have that method. So... I don't know what to do about that.
>>>
>>> Joel
>>>
Re: Converting custom Appender to Log4j v2
I guess I can. 90 lines isn't too big for an email, is it?
* start code *
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.Writer;
import org.apache.logging.log4j.core.appender.FileAppender;
import org.apache.logging.log4j.status.StatusLogger;
public class LazyFileAppender extends FileAppender {
/**
* Override FileAppender.setFile to avoid creating an empty log file
before
* the code has a chance to customize the file name.
*/
public synchronized void setFile(String fileName, boolean append,
boolean bufferedIO, int bufferSize)
throws IOException {
StatusLogger.debug("setFile called: {}, {}", fileName, append);
if (this.qw != null) {
return;
}
// set a stdout writer just in case
reset();
Writer fw = createWriter(System.out);
this.setQWForFiles(fw);
this.fileName = fileName;
this.fileAppend = append;
this.bufferedIO = bufferedIO;
this.bufferSize = bufferSize;
StatusLogger.debug("setFile ended");
}
/**
* Calling this method will signal this class that the log file name
* has been configured and that the file can now be opened.
* @throws IOException
*/
public void fileNameConfigured() throws IOException {
StatusLogger.debug("fileNameConfigured called");
// It does not make sense to have immediate flush and bufferedIO.
if (this.bufferedIO) {
setImmediateFlush(false);
}
// Save file name since reset() sets it to null
String fileName = this.fileName;
// Set to null to prevent parent class from closing System.out
this.qw = null;
reset();
this.fileName = fileName;
FileOutputStream ostream = null;
try {
//
// attempt to create file
//
ostream = new FileOutputStream(this.fileName, this.fileAppend);
}
catch (FileNotFoundException ex) {
//
// if parent directory does not exist then
// attempt to create it and try to create file
// see bug 9150
//
String parentName = new File(this.fileName).getParent();
if (parentName != null) {
File parentDir = new File(parentName);
if (!parentDir.exists() && parentDir.mkdirs()) {
ostream = new FileOutputStream(this.fileName,
this.fileAppend);
}
else {
throw ex;
}
}
else {
throw ex;
}
}
Writer fw = createWriter(ostream);
if (this.bufferedIO) {
fw = new BufferedWriter(fw, this.bufferSize);
}
this.setQWForFiles(fw);
writeHeader();
StatusLogger.debug("fileNameConfigured ended");
}
}
* end code *
Joel
On Mon, Aug 15, 2022 at 11:33 AM Ralph Goers
wrote:
> This is a problem. Log4j supports Lookups, which usually eliminate the
> need
> to override things like setFile since you can create a custom lookup to do
> whatever needs to be done.
>
> Is there any chance you can post the code so we can figure out what it
> does?
>
> Ralph
>
> > On Aug 15, 2022, at 8:21 AM, Joel Griffith wrote:
> >
> > I don't know what the old appender does, in part because I'm not a good
> > enough programmer to interpret it, and in part because the bulk of what
> it
> > does is contained in the source code of the classes that it subclasses,
> and
> > I don't have that v1 source code.
> >
> > One thing I've figured out that it does is override the v1 FileAppender's
> > setFile() method. I've also figured out that the v2 FileAppender doesn't
> > have that method. So... I don't know what to do about that.
> >
> > Joel
> >
> > On Fri, Aug 12, 2022 at 7:18 PM Gary Gregory
> wrote:
> >
> >> Joel,
> >>
> >> Is it possible to use Log4j 2's much richer feature set as is? Perhaps
> you
> >> could explain what is it your old appender does that requires custom
> code.
> >>
> >> Gary
> >>
> >> On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote:
> >>
> >>> I have a Java application containing a package written to use Log4j v1.
> >> I
> >>> am struggling to update this package to use Log4j v2 to remediate its
> >>> security vulnerabilities.
> >>>
> >>> The package contains a custom Appender that subclasses Log4j v1's
> >>> FileAppender. I am stumped at how to convert this file to Log4j v2.
> In
> >>> Log4j v2, the FileAppender class is 'final' and cannot be subclassed,
> so
> >> I
> >>> cannot create a new version of the custom Appender that mirrors the
> >> first.
> >>> More importantly, perhaps, is that the Log4j v2 FileAppender is a
> Plugin
> >>> and completely different in structure from the Log4j v1 FileAppender.
Re: Converting custom Appender to Log4j v2
This is a problem. Log4j supports Lookups, which usually eliminate the need to override things like setFile since you can create a custom lookup to do whatever needs to be done. Is there any chance you can post the code so we can figure out what it does? Ralph > On Aug 15, 2022, at 8:21 AM, Joel Griffith wrote: > > I don't know what the old appender does, in part because I'm not a good > enough programmer to interpret it, and in part because the bulk of what it > does is contained in the source code of the classes that it subclasses, and > I don't have that v1 source code. > > One thing I've figured out that it does is override the v1 FileAppender's > setFile() method. I've also figured out that the v2 FileAppender doesn't > have that method. So... I don't know what to do about that. > > Joel > > On Fri, Aug 12, 2022 at 7:18 PM Gary Gregory wrote: > >> Joel, >> >> Is it possible to use Log4j 2's much richer feature set as is? Perhaps you >> could explain what is it your old appender does that requires custom code. >> >> Gary >> >> On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote: >> >>> I have a Java application containing a package written to use Log4j v1. >> I >>> am struggling to update this package to use Log4j v2 to remediate its >>> security vulnerabilities. >>> >>> The package contains a custom Appender that subclasses Log4j v1's >>> FileAppender. I am stumped at how to convert this file to Log4j v2. In >>> Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so >> I >>> cannot create a new version of the custom Appender that mirrors the >> first. >>> More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin >>> and completely different in structure from the Log4j v1 FileAppender. >>> >>> I found this page that ostensibly explains how to extend Log4j: >>> https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders >>> but it contains no information about actually extending Appenders or >>> procedures for accomplishing an equivalent goal. >>> >>> Is there any reasonable way of converting this custom Appender from Log4j >>> v1 to v2? >>> >>> Thanks, >>> Joel >>> >> - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Converting custom Appender to Log4j v2
Thanks for the code and information, even though it's a dispiriting
answer. If I have to write a new file, it'll likely take me most of a
year, if I'm even able to do it at all. It looks like the only feasible
way to remediate this code is either to remove logging altogether or maybe
see if running in bridge mode indefinitely will work.
Thanks again!
Joel
On Fri, Aug 12, 2022 at 8:01 PM Stephen Johns
wrote:
> Actually created new logger from scratch through code:
>
> Here is relevant code
>
> where pLogFilename is something like "MyServer.log"
>
>
>
> public static void initialize(String pLogFilename, String
> pConfigurationFilename) throws IOException {
> // Make sure the filename has the proper date format and is escaped
> to
> // allow passing through a SimpleDateFormat
> String _strPrefix = "";
> String _strSuffix = "";
> int i = pLogFilename.lastIndexOf('.');
> if (i >= 0) {
> _strPrefix = pLogFilename.substring(0, i);
> _strSuffix = pLogFilename.substring(i);
> } else {
> _strPrefix = pLogFilename;
> }
>
> pLogFilename = "'" + _strPrefix + "'MMdd";
> if (_strSuffix.length() > 0)
> pLogFilename += "'" + _strSuffix + "'";
>
> createLogger(pConfigurationFilename, _strPrefix, "MMdd",
> _strSuffix);
> }
>
>
> public static void createLogger(String pConfigFilename,
> String plogFilenamePrefix,
> String pLogFilenameDateFormat,
> String pLogFileNameSuffix) throws
> IOException {
> SimpleDateFormat _sdf = new
> SimpleDateFormat(pLogFilenameDateFormat);
> String _filename = plogFilenamePrefix + _sdf.format(new Date()) +
> pLogFileNameSuffix;
> createLogger(pConfigFilename, _filename,
> plogFilenamePrefix + "%d{" + pLogFilenameDateFormat + "}" +
> pLogFileNameSuffix);
> }
>
>
> /**
> * @param pConfigurationFilename
> * @param pLogFilename
> * @param pLogFilenamePattern
> * @throws IOException
> */
> public static void createLogger(String pConfigurationFilename,
> String pLogFilename,
> String pLogFilenamePattern) throws
> IOException {
>
> FileInputStream fileInputStream = new
> FileInputStream(pConfigurationFilename);
> ConfigurationSource configurationSource = new
> ConfigurationSource(fileInputStream);
>
> ConfigurationBuilder configurationBuilder =
> ConfigurationBuilderFactory.newConfigurationBuilder();
> configurationBuilder.setConfigurationSource(configurationSource);
>
> AppenderComponentBuilder log4jFileAppenderBuilder =
> configurationBuilder.
> newAppender("DailyRollingFileAppender", "RollingFile");
> log4jFileAppenderBuilder.addAttribute("filename", pLogFilename);
> log4jFileAppenderBuilder.addAttribute("filePattern",
> pLogFilenamePattern);
>
> // set up roll-over
> ComponentBuilder triggeringPolicy =
> configurationBuilder.newComponent("Policies")
>
>
> .addComponent(configurationBuilder.newComponent("TimeBasedTriggeringPolicy").addAttribute("interval",
> "1"));
> log4jFileAppenderBuilder.addComponent(triggeringPolicy);
>
> // Configure the PatternLayout
> LayoutComponentBuilder layoutComponentBuilder =
> configurationBuilder.newLayout("PatternLayout").addAttribute("pattern",
> "%d{ABSOLUTE} %-5p %m%n");
> log4jFileAppenderBuilder.add(layoutComponentBuilder);
>
> // Add it back into configuration
> configurationBuilder.add(log4jFileAppenderBuilder);
>
> // Set up root
> RootLoggerComponentBuilder rootLogger =
> configurationBuilder.newRootLogger().
>
> add(configurationBuilder.newAppenderRef("DailyRollingFileAppender"));
> configurationBuilder.add(rootLogger);
>
> // Actually use it
> Configurator.reconfigure(configurationBuilder.build());
> //System.out.println("\n***
> LOG CONFIG ");
> // this is for debug - will print out what was created
> configurationBuilder.writeXmlConfiguration(System.out);
>
> }
>
>
> On Fri, Aug 12, 2022 at 6:18 PM Gary Gregory
> wrote:
>
> > Joel,
> >
> > Is it possible to use Log4j 2's much richer feature set as is? Perhaps
> you
> > could explain what is it your old appender does that requires custom
> code.
> >
> > Gary
> >
> > On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote:
> >
> > > I have a Java application containing a package written to use Log4j v1.
> > I
> > > am struggling to update this package to use Log4j v2 to remediate its
> > > security vulnerabilities.
> > >
> > > The package contains a custom Appender that subclasses Log4j v1's
> > > FileAppender. I am stumped at how to convert
Re: Converting custom Appender to Log4j v2
I don't know what the old appender does, in part because I'm not a good enough programmer to interpret it, and in part because the bulk of what it does is contained in the source code of the classes that it subclasses, and I don't have that v1 source code. One thing I've figured out that it does is override the v1 FileAppender's setFile() method. I've also figured out that the v2 FileAppender doesn't have that method. So... I don't know what to do about that. Joel On Fri, Aug 12, 2022 at 7:18 PM Gary Gregory wrote: > Joel, > > Is it possible to use Log4j 2's much richer feature set as is? Perhaps you > could explain what is it your old appender does that requires custom code. > > Gary > > On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote: > > > I have a Java application containing a package written to use Log4j v1. > I > > am struggling to update this package to use Log4j v2 to remediate its > > security vulnerabilities. > > > > The package contains a custom Appender that subclasses Log4j v1's > > FileAppender. I am stumped at how to convert this file to Log4j v2. In > > Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so > I > > cannot create a new version of the custom Appender that mirrors the > first. > > More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin > > and completely different in structure from the Log4j v1 FileAppender. > > > > I found this page that ostensibly explains how to extend Log4j: > > https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders > > but it contains no information about actually extending Appenders or > > procedures for accomplishing an equivalent goal. > > > > Is there any reasonable way of converting this custom Appender from Log4j > > v1 to v2? > > > > Thanks, > > Joel > > >
Re: Converting custom Appender to Log4j v2
Actually created new logger from scratch through code:
Here is relevant code
where pLogFilename is something like "MyServer.log"
public static void initialize(String pLogFilename, String
pConfigurationFilename) throws IOException {
// Make sure the filename has the proper date format and is escaped
to
// allow passing through a SimpleDateFormat
String _strPrefix = "";
String _strSuffix = "";
int i = pLogFilename.lastIndexOf('.');
if (i >= 0) {
_strPrefix = pLogFilename.substring(0, i);
_strSuffix = pLogFilename.substring(i);
} else {
_strPrefix = pLogFilename;
}
pLogFilename = "'" + _strPrefix + "'MMdd";
if (_strSuffix.length() > 0)
pLogFilename += "'" + _strSuffix + "'";
createLogger(pConfigurationFilename, _strPrefix, "MMdd",
_strSuffix);
}
public static void createLogger(String pConfigFilename,
String plogFilenamePrefix,
String pLogFilenameDateFormat,
String pLogFileNameSuffix) throws
IOException {
SimpleDateFormat _sdf = new
SimpleDateFormat(pLogFilenameDateFormat);
String _filename = plogFilenamePrefix + _sdf.format(new Date()) +
pLogFileNameSuffix;
createLogger(pConfigFilename, _filename,
plogFilenamePrefix + "%d{" + pLogFilenameDateFormat + "}" +
pLogFileNameSuffix);
}
/**
* @param pConfigurationFilename
* @param pLogFilename
* @param pLogFilenamePattern
* @throws IOException
*/
public static void createLogger(String pConfigurationFilename,
String pLogFilename,
String pLogFilenamePattern) throws
IOException {
FileInputStream fileInputStream = new
FileInputStream(pConfigurationFilename);
ConfigurationSource configurationSource = new
ConfigurationSource(fileInputStream);
ConfigurationBuilder configurationBuilder =
ConfigurationBuilderFactory.newConfigurationBuilder();
configurationBuilder.setConfigurationSource(configurationSource);
AppenderComponentBuilder log4jFileAppenderBuilder =
configurationBuilder.
newAppender("DailyRollingFileAppender", "RollingFile");
log4jFileAppenderBuilder.addAttribute("filename", pLogFilename);
log4jFileAppenderBuilder.addAttribute("filePattern",
pLogFilenamePattern);
// set up roll-over
ComponentBuilder triggeringPolicy =
configurationBuilder.newComponent("Policies")
.addComponent(configurationBuilder.newComponent("TimeBasedTriggeringPolicy").addAttribute("interval",
"1"));
log4jFileAppenderBuilder.addComponent(triggeringPolicy);
// Configure the PatternLayout
LayoutComponentBuilder layoutComponentBuilder =
configurationBuilder.newLayout("PatternLayout").addAttribute("pattern",
"%d{ABSOLUTE} %-5p %m%n");
log4jFileAppenderBuilder.add(layoutComponentBuilder);
// Add it back into configuration
configurationBuilder.add(log4jFileAppenderBuilder);
// Set up root
RootLoggerComponentBuilder rootLogger =
configurationBuilder.newRootLogger().
add(configurationBuilder.newAppenderRef("DailyRollingFileAppender"));
configurationBuilder.add(rootLogger);
// Actually use it
Configurator.reconfigure(configurationBuilder.build());
//System.out.println("\n***
LOG CONFIG ");
// this is for debug - will print out what was created
configurationBuilder.writeXmlConfiguration(System.out);
}
On Fri, Aug 12, 2022 at 6:18 PM Gary Gregory wrote:
> Joel,
>
> Is it possible to use Log4j 2's much richer feature set as is? Perhaps you
> could explain what is it your old appender does that requires custom code.
>
> Gary
>
> On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote:
>
> > I have a Java application containing a package written to use Log4j v1.
> I
> > am struggling to update this package to use Log4j v2 to remediate its
> > security vulnerabilities.
> >
> > The package contains a custom Appender that subclasses Log4j v1's
> > FileAppender. I am stumped at how to convert this file to Log4j v2. In
> > Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so
> I
> > cannot create a new version of the custom Appender that mirrors the
> first.
> > More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin
> > and completely different in structure from the Log4j v1 FileAppender.
> >
> > I found this page that ostensibly explains how to extend Log4j:
> > https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders
> > but it contains no information about actually extending Appenders or
> > procedures for accomplishing an equivalent goal.
> >
> > Is there any reasonable way of
Re: Converting custom Appender to Log4j v2
Yeah. You can't do that. I had that problem too - you have to find a new way to do in log4j. I can't look now, but I will find what I did and post it tomorrow. Don't waste time trying to find a similar mechanism - it was something rather different. On Fri, Aug 12, 2022 at 6:18 PM Gary Gregory wrote: > Joel, > > Is it possible to use Log4j 2's much richer feature set as is? Perhaps you > could explain what is it your old appender does that requires custom code. > > Gary > > On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote: > > > I have a Java application containing a package written to use Log4j v1. > I > > am struggling to update this package to use Log4j v2 to remediate its > > security vulnerabilities. > > > > The package contains a custom Appender that subclasses Log4j v1's > > FileAppender. I am stumped at how to convert this file to Log4j v2. In > > Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so > I > > cannot create a new version of the custom Appender that mirrors the > first. > > More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin > > and completely different in structure from the Log4j v1 FileAppender. > > > > I found this page that ostensibly explains how to extend Log4j: > > https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders > > but it contains no information about actually extending Appenders or > > procedures for accomplishing an equivalent goal. > > > > Is there any reasonable way of converting this custom Appender from Log4j > > v1 to v2? > > > > Thanks, > > Joel > > > -- ☮
Re: Converting custom Appender to Log4j v2
Joel, Is it possible to use Log4j 2's much richer feature set as is? Perhaps you could explain what is it your old appender does that requires custom code. Gary On Fri, Aug 12, 2022, 15:35 Joel Griffith wrote: > I have a Java application containing a package written to use Log4j v1. I > am struggling to update this package to use Log4j v2 to remediate its > security vulnerabilities. > > The package contains a custom Appender that subclasses Log4j v1's > FileAppender. I am stumped at how to convert this file to Log4j v2. In > Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so I > cannot create a new version of the custom Appender that mirrors the first. > More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin > and completely different in structure from the Log4j v1 FileAppender. > > I found this page that ostensibly explains how to extend Log4j: > https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders > but it contains no information about actually extending Appenders or > procedures for accomplishing an equivalent goal. > > Is there any reasonable way of converting this custom Appender from Log4j > v1 to v2? > > Thanks, > Joel >
