Add or port the JMS Appender for Jakarta

[garydgregory]

The 2.x JmsAppender uses the javax API.

I need a jarkarta version.

I'd like to do this work in 2.x, so that would be a new class and we can deprecated the old one.

For 3.0, we can only support the jarkarta version.

Where is the code for JMS in 3.0?

[vy]

This work has already been done: see logging-log4j-jakarta repository. It will be released in tandem with 3.0.0 Op vr 20 sep 2024 om 19:25 schreef Gary Gregory ***@***.***>

…

The JMS Appender is still on javax. This issue is for porting it to jakarta. I am assuming we do *not* want to support both at the same time. — Reply to this email directly, view it on GitHub <#2995>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARTSIQZTDJG4HHHAJFBIDZXRK7NAVCNFSM6AAAAABOSO6OS2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZTSMRZGMZDSMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[garydgregory]

Ah, thank you for the reference.

This is another great example of the sad state of having split Log4j into an unknown number of repositories.

Is there documentation of what is where now? There is no mention JMS on https://logging.apache.org/log4j/3.x/manual/appenders.html like there is on https://logging.apache.org/log4j/2.x/manual/appenders.html

Worse, we've released 2 betas of 3.0 and logging-log4j-jakarta has been released 0 times. There is zero versions of log4j-jakarta-jms on Maven Central.

If we had kept it all in one place, we would not be in this mess :-(

[ppkarwasz]

Worse, we've released 2 betas of 3.0 and logging-log4j-jakarta has been released 0 times. There is zero versions of log4j-jakarta-jms on Maven Central.

If we had kept it all in one place, we would not be in this mess :-(

We don't have a Jakarta JMS mainly because, I don't have enough experience with JMS to make meaningful contribution to its 3.0 version. I would need your help and expertise to:

• Merge the documentation of the 2.x JMS Appender into the documentation of the 3.x JMS Appender.
• Explain what JNDI parameters (like factoryName) should the user provide to use JNDI safely. Should we even keep these JNDI parameters or should the runtime environment take care of that?
• Explain why should users use the JMS Appender instead of activemq-log4j-appender. What are the differences between the two?

[garydgregory]

Hello @ppkarwasz

Explain why should users use the JMS Appender instead of activemq-log4j-appender. What are the differences between the two?

Well, it's completely difference from ours, not functionally equivalent, so not compatible, at all.

I need a version of our 2.x JMS Appender that uses the Jakarta API instead of the Javax API, that's all. I'll create a PR...

[ppkarwasz]

@garydgregory,

I need a version of our 2.x JMS Appender that uses the Jakarta API instead of the Javax API, that's all. I'll create a PR...

Maybe you could release Log4j Jakarta? Next week I'll be back from my workation and I can look at the documentation of og4j Jakarta. I am also planning a release of Log4j 3.0.0-beta3 by the end of October.

[garydgregory]

Hi @ppkarwasz

Maybe you could release Log4j Jakarta?

Not helpful since it does not work with 2.x.

[ppkarwasz]

If you need a 2.x version, you can do something like log4j-jakarta-smtp: you only implement a JmsManager in another module. JmsAppender can search for a JmsManager using ServiceLoader and if it does not find anything, it will use the Java EE one.