ppkarwasz opened a new issue, #4351: URL: https://github.com/apache/logging-log4j2/issues/4351
## Description The documentation of [`log4j2.enableJndiJms`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.enableJndiJms) says: > When `true`, a Log4j JMS Appender can use JNDI to retrieve the necessary components using the `java:` protocol. This suggests that only local `java:` resources are reachable, but the JMS appender also accepts `factoryName` and `providerUrl`, which `JndiManager.createProperties` passes to the `InitialContext` as `Context.INITIAL_CONTEXT_FACTORY` and `Context.PROVIDER_URL`. `JndiManager.lookup` only restricts the **name** (no scheme or `java:`), so a scheme-less name is resolved by whichever JNDI provider `factoryName`/`providerUrl` point to, including a remote one. This is the intended use of these attributes (e.g. a broker's own JNDI provider), but the documentation should say so, so that users understand what they enable: - the `log4j2.enableJndiJms` description should mention that, together with `factoryName` and `providerUrl`, the appender connects to the configured JNDI provider, and that these attributes must only point to trusted providers; - the JMS appender reference (`message-queue.adoc`) could repeat this next to `factoryName` and `providerUrl`. ## Configuration **Version:** 2.26.1 (and `2.x` at `d631e82`) **Operating system:** any **JDK:** any ## Logs None. ## Reproduction Documentation only. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
