Reconsider enablement of JNDIPropertySource by default [SPR-14026]

[spring-projects-issues]

Mike Noordermeer opened SPR-14026 and commented

#13189 enabled JndiPropertySource by default. Looking at some profiler results, I'm wondering if it would be wise to at least add a warning to the documentation about the potential performance impact of this.

The attached call tree shows that for 8800 property lookups, 89% of the time is spent in the JndiPropertySource (JndiTemplate creates an InitialContext on each lookup, etc. etc.). All other property sources are way faster, and I never anticipated JNDI being so slow (and this is using Tomcat, other app servers are known for having even slow JNDI access).

This was tested against 4.2.1, but it seems nothing changed since then, and I assume it affects 4.2.5 as well.

---

Affects: 4.2.5

Attachments:

• calltree.png (210.58 kB)

Referenced from: commits d2c0885

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

Since default JNDI searches in Servlet and Portlet environments on a Java EE server do make sense, I've rather refined our way of identifying such a default JNDI environment: Our JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable() check, as used by StandardServlet/PortletEnvironment when deciding whether to register a JndiPropertySource, has a corresponding Spring library property now: "spring.jndi.ignore".

So if you'd like to avoid any such default JNDI fallback searches, simply specify spring.jndi.ignore=true in a spring.properties file at the root of the Spring library classpath level, or alternatively as a JVM system property. I hope this makes sense for your purposes...

Juergen

[quaff]

Please reconsider:

1. JNDI is vulnerable
2. JndiPropertySource is non-enumerable cause some weird behavior in spring-boot, see Configuration properties cannot be bound to DruidDataSource when the environment contains a non-enumerable property source spring-boot#39840 and Creation of auto-configured DataSource fails when using UCP and the environment contains a non-enumerable property source such as JndiPropertySource spring-boot#38514
3. Poor performance
4. JNDI is not widely used in practice now.