Split JNDI support out of `log4j-jdbc`

[ppkarwasz]

Currently the log4j-jdbc appender has an optional dependency on log4j-jndi.

In order to remove this optional dependency, I propose to:

• create a new module log4j-jdbc-jndi and depends on log4j-jdbc and log4j-jndi and contains the DataSourceConnectionSource and inlined code from JndiUtil,
• remove the dependency on log4j-jndi from log4j-jdbc.

From a user perspective:

• most users will require just the log4j-jdbc-dbcp2 module,
• some Java EE/Jakarta EE users will require the log4j-jdbc-jndi module,
• the log4j-jdbc module could be considered as an internal dependency.

[vy]

@ppkarwasz, could you share what are the pros/cons this change will bring? I mean, what are the functional goals we want to achieve and how will this change contribute to that in which way?

[ppkarwasz]

@vy,

The pros are mostly:

• we lose an optional dependency. Optional dependencies are always hard to deal with correctly. Without testing I can't easily tell if DataSourceConnectionSource will catch all LinkageErrors if log4j-jndi is not present. I believe that the NoClassDefFoundError will propagate to the user.
• we psychologically reassure users that tremble, when they head JNDI. Static code analysis tools might also give false positives.

The cons:

• we have yet another module that users need to add to their dependencies. However in 3.x users need to add log4j-jdbc anyway, so they might just replace it with log4j-jdbc-jndi.

[vy]

Thanks, got it. Then I support the proposal.

That said, shouldn't we first practice the same for log4j-core?

[ppkarwasz]

Yes, splitting the async, JMX, JANSI and compression support from log4j-core should have a higher priority.

[rgoers]

@ppkarwasz in 3.x I presume? I think we should not mess with 2.x at this point. This reminds me I still have to vote on your proposal.

[ppkarwasz]

Fixed by #2915.