[JAVA-3402] Unable to use mongo+srv scheme when java.naming.provider.url JNDI property is invalid Created: 26/Aug/19 Updated: 28/Oct/23 Resolved: 19/Jun/20 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Configuration |
| Affects Version/s: | 3.11.0 |
| Fix Version/s: | 4.1.0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Daniel John Gomez | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
When creating a MongoClient with mongo+srv scheme and that java.naming.provider.url JNDI property is set to a file URL, the driver throws
There are two issues here. First is that the exception message is misleading. DefaultDnsResolver.createDnsDirContext assumes all NamingException}}s are caused by the unavailability of DnsContextFactory. Checking the causing exception, it fails because I have this JNDI property
which is not supported by the DnsContextFactory.
To reproduce: 1. Add jndi.properties file to the classpath with content
2. Run the following code
|
| Comments |
| Comment by Jeffrey Yemin [ 21/Mar/21 ] | |||||
|
rishabh@supertokens.io the PR referenced above fixed the issue for the original reporter and was therefore closed, so it's likely you're running into something slightly different. If you'd like to pursue it further please open a new issue. Also, here are some other resources where you can get help:
Thank you! | |||||
| Comment by Rishabh Poddar [ 21/Mar/21 ] | |||||
|
I updated the version to 4.2.2 and I still get the same error. Is there something I am supposed to be doing other than an update? | |||||
| Comment by Jeffrey Yemin [ 19/Jun/20 ] | |||||
|
Fixed by https://github.com/mongodb/mongo-java-driver/pull/554
Thanks djgomez23@gmail.com! | |||||
| Comment by Daniel John Gomez [ 19/Jun/20 ] | |||||
|
Sorry it took a while for me to get back on this issue. It turns out this can be fixed by explicitly setting java.naming.provider.url to dns: I noticed this is also done on the DNS resolver of Netflix' eureka-client. I made a PR for this. | |||||
| Comment by Rishabh Poddar [ 18/May/20 ] | |||||
|
I am facing this issue on Windows, using OpenJDK 12.0.2. However, using the mongodb:// format works fine though. I am using the following in my build.gradle
| |||||
| Comment by VoiceIt DevOps [ 25/Apr/20 ] | |||||
|
I am having the same problem. We are using AdoptOpenJDK 8 with Java Play 2.4.3 at the moment. | |||||
| Comment by Jeffrey Yemin [ 07/Oct/19 ] | |||||
|
Since you are in a good position to test this, feel free to make the change and submit a pull request. | |||||
| Comment by Daniel John Gomez [ 03/Oct/19 ] | |||||
|
Another way is to set clear java.naming.provider.url on the environment used by InitialDirContext such that DnsContextFactory will not fail not initialize. | |||||
| Comment by Daniel John Gomez [ 03/Oct/19 ] | |||||
|
We are using org.apache.xbean.spring.jndi.SpringInitialContextFactory to load JNDI properties from an XML file. The problem here is that the initialization of InitialDirContext also retrieves those properties by default and causes the said exception. Well, since the driver is using InitialDirContext just to use com.sun.jndi.dns.DnsContextFactory, why not use that class directly and retrieve the resolved URLs from there:
This way you also prevent loading of application resource files. | |||||
| Comment by Jeffrey Yemin [ 03/Oct/19 ] | |||||
|
That is not very promising, given the documentation. I would really hesitate to make use of something documented as an internal environment property, and one with a totally different purpose that we'd be intending it for, in the driver. Can you explain a bit what you're using Apache XBean for? Perhaps there is a workaround on that side of things. At the least, I suggest opening an issue in their Jira bug tracker and see if they have any suggestions. | |||||
| Comment by Daniel John Gomez [ 02/Oct/19 ] | |||||
|
Unfortunately I couldn't find any proper documentation either. This is just something that I found while trying to see where InitialDirContext does the retrieval of jndi.properties. However, there is a bit of a javadoc on it on com.sun.naming.internal.ResourceManager
| |||||
| Comment by Jeffrey Yemin [ 02/Oct/19 ] | |||||
|
Can you point us to any documentation for that property? My searching has turned up nothing authoritative so far. | |||||
| Comment by Daniel John Gomez [ 02/Oct/19 ] | |||||
|
What I can suggest is disable the application resource files lookup such that jndi.properties is not considered when building the InitialDirContext on DnsResolver.createDnsDirContext(). This can be done by adding this:
I can also confirm that I can successfully use a SRV connection with this. | |||||
| Comment by Jeffrey Yemin [ 30/Sep/19 ] | |||||
|
At this point we don't have a good idea how to fix this. As a workaround, I suggest that you switch to using non-SRV connection strings (which should be available in Atlas if you choose the Java driver "3.4 or later" option (see attachment). | |||||
| Comment by Jeffrey Yemin [ 23/Sep/19 ] | |||||
|
cstrobl you are so right. Sorry for the false alarm. | |||||
| Comment by Christoph Strobl [ 23/Sep/19 ] | |||||
|
As far as we can tell there is nothing in there that we (Spring Data) provide in the first place. The Integration is provided by Apache XBean, isn't it? | |||||
| Comment by Jeffrey Yemin [ 12/Sep/19 ] | |||||
|
Waiting to hear back from cstrobl from Spring Data team about this. | |||||
| Comment by Daniel John Gomez [ 28/Aug/19 ] | |||||
|
Hi, This is because we're using a initial factory based on SpringInitialContextFactory which requires a file path set for java.naming.provider.url. This is all set on our jndi.properties:
Basically, when you do new InitialDirContext(envProps) on DefaultDnsResolver it will take all the properties set on the jndi.properties which may fail since this may contain application-specific properties. | |||||
| Comment by Jeffrey Yemin [ 26/Aug/19 ] | |||||
|
I'm not clear what the second issue is. Can you provide some context as to why your application sets that system property to a file URL, and what the content of that file is? |