You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good point. However, the additional getEnvironment() call doesn't actually seem to help on Linux and Windows: The corresponding test fails both on the CI server and on my local development machine, with the getEnvironment() call apparently returning normally and therefore still suggesting the availability of a default JNDI environment... Could it be that it only helps on Mac OS? This may be a good enough effect but it isn't really a strong backport candidate then.
It would be good to find a consistent way to detect JNDI. The test is used to add a JndiPropertySource which ends up just catching NamingException each time.
As per our research, the problem seems to be a side effect from other JNDI tests in our test suite since the test does pass in isolation on Windows as well. We'll fix the test arrangements accordingly and will keep the stronger JNDI environment check in place for 4.1.1 then.
Phil Webb opened SPR-12223 and commented
Calling
JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable()
always seems to return true.Affects: 4.1 GA
Referenced from: commits 2667956, 7f8d611, 2077388
The text was updated successfully, but these errors were encountered: