Using CI to create & sign distrib. ZIP and upload to Nexus & SVN

[Volkan Yazıcı]

*[Apologies for the cross-post in BCC. I find this development important
for all Java-based ASF projects. Hence, my push to reach a wider audience.]*

In my crusade to automate whatever [practically] possible in the release
process of a Java-based ASF project, I have cracked a new puzzler:
uploading the distribution to Subversion.

*Why should you care?*

Because this implements the most easy-to-run and ASF-compliant release
process out there in the wild for Java-based ASF projects.

*Status*

At this point, `logging-log4j-tools` GitHub repository CI performs the
following tasks during a release:

   1. Build & sign artifacts
   2. Upload artifacts to Nexus
   3. Generate the release notes
   4. Generate & sign the distribution ZIP containing artifacts,
   Git-tracked sources, and the release notes
   5. Generate the vote and announcement emails (incl. the release notes)
   6. Upload the signed distribution along with the emails to SVN

I deliberately did *not* automate sending out the vote email, since that is
irreversible whereas all the steps I have shared above are. Therefore, the
RM is still in control of polishing and retrying the CI before sealing it
with a vote email.

*Future work*

Moving what is possible (GitHub Actions workflow, email generation,
BeanShell, etc.) to a separate GitHub repository and reusing it in
`logging-log4j-tools`.

*References*

   - INFRA ticket requesting SVN credentials in GitHub Secrets
   
   - CI run of a successful SVN upload
   
   - GitHub Actions Workflow (aka. CI script)
   

   - Release instructions (for the RM)
   
   - Email script (incorporating changelog and such)
   

   - BeanShell script generating the distribution (JARs + Git-tracked
   sources)
   

[log4j] Multiple applications using GetLogger with same name

[Danish Arif]

Hi Log4j2 Team,

My query is related to log4j2 working and uses of
LogManager.getLogger(String name); method.

My use case is that my application uses the above mentioned method to get
logger and log. Appender and Logger have been set in log4j2.xml file. We
stop the Logger by getting all core appenders , removing them , then
stopping them and then using the LogManager.shutdown() method.

The issue or anomaly arises when an update batch script starts the new
instance of the same application and the old instance takes some time to
exit, resulting in new instance getting the same logger using
LogManager.getLogger("AppName"); and writing in the same log file.

Once the 1st/old instance exists after a few seconds, it closes all the
logging and nothing on the file gets written even when the 2nd/new instance
is still up and running.

Kindly advise what can be done to handle this type of scenario when there
is no communication between the instances and are totally independent and
agnostic of each other.

Regards,
Danish Arif

Re: [log4j] Multiple applications using GetLogger with same name

[Ralph Goers]

Your issue is related to you starting and stopping the LoggerContext while your 
application is in an unknown state.  I can think of a few ways to deal with 
this.

1. Never shutdown the LoggerContext and only use RoutingAppenders. Each 
application should set its own key for the Route so that each uses their own 
Appenders. During shutdown of the application only shutdown the Appenders that 
apply to the applications Route.
2. Partition your application so that the main application and each batch job 
use their own ClassLoader. The ClassLoaderContextSelector (the default) will 
then create a LoggerContext for each ClassLoader and each can have its own 
configuration.
3. Use the JndiContextSelector and have each application and batch job use a 
unique JNDI name. This will allow each to have its own LoggerContext. However, 
if any of the classes use static Loggers and those classes are in a ClassLoader 
shared by the application and batch jobs then those Loggers will be tied to the 
LoggerContext used when they Loggers were first obtained. So this solution may 
not completely work for you.

Ralph



> On Jul 25, 2023, at 6:24 AM, Danish Arif  wrote:
> 
> Hi Log4j2 Team,
> 
> My query is related to log4j2 working and uses of
> LogManager.getLogger(String name); method.
> 
> My use case is that my application uses the above mentioned method to get
> logger and log. Appender and Logger have been set in log4j2.xml file. We
> stop the Logger by getting all core appenders , removing them , then
> stopping them and then using the LogManager.shutdown() method.
> 
> The issue or anomaly arises when an update batch script starts the new
> instance of the same application and the old instance takes some time to
> exit, resulting in new instance getting the same logger using
> LogManager.getLogger("AppName"); and writing in the same log file.
> 
> Once the 1st/old instance exists after a few seconds, it closes all the
> logging and nothing on the file gets written even when the 2nd/new instance
> is still up and running.
> 
> Kindly advise what can be done to handle this type of scenario when there
> is no communication between the instances and are totally independent and
> agnostic of each other.
> 
> Regards,
> Danish Arif

[log4j] `Constants` is missing `ENABLE_THREADLOCALS` and many more in `main`

[Volkan Yazıcı]

In `main`, `LegacyPluginTest` fails (after bumping
`log4j2-logstash-layout.version` to `1.0.5`
) due to missing
`ENABLE_THREADLOCALS` static field in
`org.apache.logging.log4j.core.util.Constants`. 287ee839 is responsible for
this change and there are more constants removed. Given this breaks
backward compatibility, what shall we do?

Note that my question is not merely limited to the `Constants` class.
Otherwise I would have simply introduced those fields back. I bet I can
find dozens of such breaking changes if I search long enough.