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 https://github.com/spring-projects/spring-framework/commit/d2c0885e2979e9708d5d700f6a3e131bc9a770b1

0 votes, 5 watchers

Comment From: 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

Comment From: quaff

Please reconsider: 1. JNDI is vulnerable 2. JndiPropertySource is non-enumerable cause some weird behavior in spring-boot, see https://github.com/spring-projects/spring-boot/issues/39840 and https://github.com/spring-projects/spring-boot/issues/38514 3. Poor performance 4. JNDI is not widely used in practice now.