Add a Jakarta JMS Appender #2295

[garydgregory]

Adds a Jakarta JMS Appender #2295

In order to complete an app stack's port from javax to jakarta, I need to be jakarta all the way.

[ppkarwasz]

I think we should rather proceed as in the Jakarta Mail API case:

• We create a new log4j-jakarta-jms artifact.
• We modify JmsAppender to look for JmsManager implementations via ServiceLoader.

[ppkarwasz]

I would prefer to have a single JMS plugin like we have for SMTP:

• We can have a single JmsAppender and multiple JmsManagers,
• The JmsAppender.Builder.build() method finds an implementation of JmsManagerFactory using ServiceLoader.
• If it finds nothing, the default Javax implementation is used.

[garydgregory]

I really don't want to do some service loader magic and finding this or that on the class path. I want to use the old or the new explicitly.

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	✅
build-ubuntu-latest	clean install	3.9.8	✅
build-windows-latest	clean install	3.9.8	✅

Generated by gradle/develocity-actions

[garydgregory]

Hi @ppkarwasz and all: Ready for review.

[ppkarwasz]

@garydgregory,

Honestly I would prefer for the Jakarta JMS appender to work with the "JMS" name: as far as I understand now users need to change JMS to JMS-Jakarta in their Log4j Core 2 and to change from JMS-Jakarta back to JMS once they migrate to Log4j Core 3?

Another question that we might want to discuss is the reliance on JNDI: the JmsManager actually only needs a JMS ConnectionFactory and it really doesn't matter how this factory is obtained. To configure JMS we could proceed the same way as with JDBC:

• The JMS-Jakarta plugin could have a nested ConnectionFactoryProvider element to specify how to obtain the ConnectionFactory.
• We provide an implementation of the ConnectionFactoryProvider implementation that uses JNDI.
• Third parties (e.g. ActiveMQ Artemis) could provide other ConnectionFactoryProvider. I know that Spring Boot doesn't use JNDI at all with Artemis (see ArtemisConnectionFactoryConfiguration).

What do you think? Of course if there are configuration differences between the Javax and Jakarta JMS appenders, the name change is justified.

[ppkarwasz]

I think we could use the same technique as with the Servlet Appender: document only the Jakarta version and add a collapsible paragraph "Click here if you are using Jakarta EE 8 or any version of Java EE" (see Servlet Appender documentation).

[garydgregory]

The collapsible UI to too lame to use IMO. It's hard to tell how much is expanded, maybe if it expanded into something with a border it would help. I did not want to click on the "Click here" text because I did not want to leave the page.

The true uselessness of the collapsible thingy is that when you search for text on a page in a web browser (Firefox in my case), the browser does not find the text inside the collapsed text, so using the collapsible thingy an anti-pattern as implemented (IMO). Or maybe Firefox found it but you certainly don't see it.

The new site is hard enough to use without this kind of UI to make it worse 😞... IMO

[garydgregory]

@garydgregory,

Honestly I would prefer for the Jakarta JMS appender to work with the "JMS" name: as far as I understand now users need to change JMS to JMS-Jakarta in their Log4j Core 2 and to change from JMS-Jakarta back to JMS once they migrate to Log4j Core 3?

Hi @ppkarwasz

Ouch? For 2.x, reusing the "JMS" name will force users to migrate from Javax to Jakarta, this is going to be a surprise hidden change and break existing configurations. I don't think we should do that.

The move to 3.x will require plenty of changes for non-trivial configurations IMO, especially when switching from Javax to Jakarta, adding this and that new Log4j modules that are now split out. So I'm OK with keeping the new name, supporting both styles, or renaming.

ATM, I am only concerned about an IRL 2.x use case for JMS and Jakarta. For 3.x we can do whatever.

WDYT?

Another question that we might want to discuss is the reliance on JNDI: the JmsManager actually only needs a JMS ConnectionFactory and it really doesn't matter how this factory is obtained. To configure JMS we could proceed the same way as with JDBC:

* The `JMS-Jakarta` plugin could have a nested `ConnectionFactoryProvider` element to specify how to obtain the `ConnectionFactory`.

* We provide an implementation of the `ConnectionFactoryProvider` implementation that uses JNDI.

* Third parties (e.g. ActiveMQ Artemis) could provide other `ConnectionFactoryProvider`. I know that Spring Boot doesn't use JNDI at all with Artemis (see [`ArtemisConnectionFactoryConfiguration`](https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jms/artemis/ArtemisConnectionFactoryConfiguration.java)).

What do you think? Of course if there are configuration differences between the Javax and Jakarta JMS appenders, the name change is justified.

[garydgregory]

Merging after discussion with @ppkarwasz. Keep it simple and no need for an extra mechanism to detect javax vs jakarta implementations on the classpath.