Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-1620

2.12.x breaks compatibility with mongoDB v1.8

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

      Using the Java driver 2.12.x against a mongoDB version 1.8 fails at startup due to com.mongodb.MongoTimeoutException caused by java.lang.NullPointerException (see stack trace below).

      The root cause seems to be the expected existence of "versionArray" in com.mongodb.ServerStateNotifier.getVersion(final CommandResult buildInfoResult) (v. 2.12.0, later moved to ServerMonitor.getVersion in 2.12.2)

      Apparently, mongoDB v1.8 doesn't provide the version as array.

      Is having a structured ServerVersion class really worth breaking backwards compatibility? Looks rather accidental to me.

      com.mongodb.MongoTimeoutException: Timed out after 10000 ms while waiting to connect. Client view of cluster state is {type=Unknown, servers=[{address=127.0.0.1:27017, type=Unknown, state=Connecting, exception={java.lang.NullPointerException}}]
      at com.mongodb.BaseCluster.getDescription(BaseCluster.java:128)
      at com.mongodb.DBTCPConnector.getClusterDescription(DBTCPConnector.java:396)
      at com.mongodb.DBTCPConnector.getType(DBTCPConnector.java:569)
      at com.mongodb.DBTCPConnector.isMongosConnection(DBTCPConnector.java:370)
      at com.mongodb.Mongo.isMongosConnection(Mongo.java:645)
      at com.mongodb.DBCollection.findOne(DBCollection.java:865)
      at com.mongodb.DBCollection.findOne(DBCollection.java:843)
      at com.mongodb.DBCollection.findOne(DBCollection.java:789)
      at com.sap.sse.security.userstore.mongodb.impl.DomainObjectFactoryImpl.loadSettingTypes(DomainObjectFactoryImpl.java:199)
      at com.sap.sse.security.userstore.mongodb.UserStoreImpl.<init>(UserStoreImpl.java:55)
      at com.sap.sse.security.userstore.mongodb.impl.Activator.start(Activator.java:30)
      at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
      at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
      at java.security.AccessController.doPrivileged(Native Method)
      at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
      at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
      at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
      at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
      at org.eclipse.osgi.container.Module.doStart(Module.java:571)
      at org.eclipse.osgi.container.Module.start(Module.java:439)
      at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
      at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
      at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
      at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
      at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
      at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
      at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

            Assignee:
            Unassigned Unassigned
            Reporter:
            jens.rommel Jens Rommel
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: