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 <jgrif...@nd.edu> 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 <ralph.go...@dslextreme.com>
> wrote:
>
>>
>>
>>> On Aug 26, 2022, at 1:45 PM, Joel Griffith <jgrif...@nd.edu> 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
