Given 2 generic POJOs that include references to each other such as:

package com.example;

public class Course {
    Student _student;

    public void setStudent(Student student) {
      _student = student;
    }

    public Student getStudent() {
      return _student;
    }
}

package com.example;

public class Student {
    private Course _course;

    public void setCourse(Course course) {
      _course = course;
    }
    public Course getCourse() {
      return _course;
    }
}

It would be useful to have a configuration mechanism to prevent Maximum serialization depth exceeded exceptions from being thrown.

package com.example;

import com.mongodb.ConnectionString;
import com.mongodb.MongoClientSettings;
import com.mongodb.client.MongoClient;
import com.mongodb.client.MongoClients;
import com.mongodb.client.MongoCollection;
import com.mongodb.client.MongoDatabase;

import org.bson.Document;
import org.bson.codecs.configuration.CodecRegistry;
import org.bson.codecs.pojo.PojoCodecProvider;

import static org.bson.codecs.configuration.CodecRegistries.fromProviders;
import static org.bson.codecs.configuration.CodecRegistries.fromRegistries;

public class App {
  public static void main(final String[] args) {
    CodecRegistry pojoCodecRegistry = fromProviders(PojoCodecProvider.builder().automatic(true).build());
    CodecRegistry codecRegistry = fromRegistries(MongoClientSettings.getDefaultCodecRegistry(),
    pojoCodecRegistry);
    MongoClientSettings clientSettings = MongoClientSettings.builder()
    .applyConnectionString(new ConnectionString("mongodb://localhost:27017"))
    .codecRegistry(codecRegistry)
    .build();

    MongoClient mongoClient = MongoClients.create(clientSettings);
        MongoDatabase database = mongoClient.getDatabase("test");

        MongoCollection<Student> students = database.getCollection("students", Student.class);
        MongoCollection<Course> courses = database.getCollection("courses", Course.class);

        students.deleteMany(new Document());
        courses.deleteMany(new Document());

        Student student = new Student();
        Course course = new Course();

        student.setCourse(course);
        course.setStudent(student);

        students.insertOne(student);
        courses.insertOne(course);

        System.out.println(students.find(new Document()).first());
        System.out.println(courses.find(new Document()).first());
  }
}

The above would result in the following:

Exception in thread "main" org.bson.BsonSerializationException: Maximum serialization depth exceeded (does the object being 
serialized have a circular reference?).
        at org.bson.AbstractBsonWriter.writeStartDocument(AbstractBsonWriter.java:285)
        at com.mongodb.internal.connection.BsonWriterDecorator.writeStartDocument(BsonWriterDecorator.java:48)
        at com.mongodb.internal.connection.LevelCountingBsonWriter.writeStartDocument(LevelCountingBsonWriter.java:42)      
        at com.mongodb.internal.connection.IdHoldingBsonWriter.writeStartDocument(IdHoldingBsonWriter.java:78)
        at org.bson.codecs.pojo.PojoCodecImpl.encode(PojoCodecImpl.java:94)
        at org.bson.codecs.pojo.LazyPojoCodec.encode(LazyPojoCodec.java:47)
        at org.bson.codecs.EncoderContext.encodeWithChildContext(EncoderContext.java:91)
        at org.bson.codecs.pojo.PojoCodecImpl.encodeValue(PojoCodecImpl.java:181)
        at org.bson.codecs.pojo.PojoCodecImpl.encodeProperty(PojoCodecImpl.java:169)
        at org.bson.codecs.pojo.PojoCodecImpl.encode(PojoCodecImpl.java:106)
        at org.bson.codecs.pojo.LazyPojoCodec.encode(LazyPojoCodec.java:47)
        at org.bson.codecs.EncoderContext.encodeWithChildContext(EncoderContext.java:91)
....... etc

I am working on a mongodb connector for the Apache Flink project - https://flink.apache.org/

Internally, Flink is using java serialization to save the records it is working on in a state which in turn used to recover from failures etc, as well as for passing records between different tasks in the pipeline.
I have noticed the mongodb client model classes are not Serializable for instance, classes such as WriteModel https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/WriteModel.java and its subclasses or the different Options like ReplaceOptions https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/ReplaceOptions.java

is there a reason for these classes to not be declared Serializable? Is there a way to contribute to the Java driver project by opening a PR that addresses this?

Currently we can update multiple documents with one query if all documents belong to the same collection as shown below;

dB.collection.bulkWrite([ query1, query2, query3, query4 ])

This feature is wonderful but it is paramount if mongodb can enable us to use this query or something similar to update multiple documents from different collections with the one query instead of having to send and await each query one at a time as is currently the case.

The truth is, mongodb only needs to enable this feature of being able to update multiple documents with one query from different collections and then it will certainly be superior to the SQL databases and will get much more market share.

Please modify your drivers so our java applications can encrypt and decrypt from the mainframe (zOS) UNIX environment. This missing feature is a road-block to our migration to Atlas.

We have multiple Java applications that run on an IBM mainframe. Those applications read and write into MongoDB collections, like inserting Mainframe data into MongoDB collections. The mongo-crypt driver for CSFLE does not work on the Mainframe UNIX environment.

Company policy states we have to encrypt all PHI/PII data prior to inserting the data into Atlas.

I had opened a support ticket with MongoDB and the final reply was you do not support zOS and to put in this request. (Case number 00802484)

Here is the error message I shared with MongoDB:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/z/os-s390/libjnidispatch.so) not found in resource path (Ýfile:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/,
file:/ST/usr/lpp/java/IBM/J8.0/lib/, file:/ST/usr/lpp/java/IBM/J8.0/lib/ext/,
file:/ST/usr/lpp/java/json/org.json-20120521.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/CDRMigrateAccumsToAtlas.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/bson-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/jna-5.6.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/json-20160810.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-classic-1.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-core-1.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-crypt-1.2.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-core-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-sync-4.2.3.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/recordio.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/slf4j-api-1.7.6.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/vault-java-driver-5.1.0.jar,
file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/*.mar¨)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1032)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.<clinit>(Native.java:195)

We would like to suggest a feature improvement where connection parameters can be dynamically changed so that no restart of client application infrastructure is needed.

Currently, when changing connection configuration, this usually requires the restart of a considerable number of pods or containers with the unavoidable consequence of a sudden surge in connection attempts.

Our request specifically would be to provide a way for drivers to read both connection string and connection parameters information from a source that can be easily managed and that's not necessarily embedded in the code, and

Drivers should also detect when this configuration has changed and gradually refresh connections to reflect the new configuration. Ideally there would be ways of forcing the driver to be more aggressive or more gradual, which should accommodate for emergency situations or tuning scenarios that are not urgent. This is the part that would avoid any client infrastructure restart, and avoid sudden surges in connection attempts.

Note: This post was inspired by my attempts to find a direct download for the MongoDB Java driver, but I've left the category as "Unspecified" because it could apply to any driver download for which the official sites say to "Just use Maven/etc"

Right now the documentation for the MongoDB Java driver (https://mongodb.github.io/mongo-java-driver/4.2/driver/getting-started/installation/) indicates that "The recommended way to get started using one of the drivers in your project is with a dependency management system." However, as far as I could tell from my own research, the official MongoDB sites have no official direct download link for the driver/dependency jar files - only the Maven groupId/artifactId are provided. If for some reason a developer is restricted such that they cannot use a dependency manager for their project and must obtain the jar files as a direct download, they must find the official Apache Maven repository on their own, and download the files from there.

I understand that this seems like a problem that can be solved by saying "just suck it up and use Maven", but please understand that at its core, this actually constitutes a security issue, as it makes it difficult for developers to find a download that they know they can trust.

Consider the following situation: Due to some situation, a developer is unable to use a dependency manager for their project. They must use a direct download of the driver/dependency jar files for the MongoDB Java driver in order to do their job. The first thing they will likely do (rightfully so) is go to the official MongoDB sites to try and find a download. They will not find it, and will instead look elsewhere.

Performing a Google search for "mongodb java driver" returns first the official MongoDB sites, which the developer already knows will not help them, and then returns an unofficial Maven Repository browser (mvnrepository). I haven't looked into the validity of this site, and I'm usually one to assume the best of intentions, but the fact remains that it's run by a person who is not affiliated with Apache/Maven or MongoDB, from which the developer will likely download several unverified jar files and include them with their project. This is a big security risk, as theoretically speaking, for all we know this site could be malicious, but it remains the most convenient option for the developer, because the official MongoDB sites do not include one. The safest option for the developer is to use the official Maven repository at search.maven.org, but this site only appears at the very bottom of the first page of the Google results, and the developer may not even see this during their search.

I feel like this problem could be fully solved by creating a section on the "Downloads" page (https://www.mongodb.com/try/download) for drivers, and including the most recent normally-supported release of each driver, including its dependencies. This may not be the recommended method, and it could very well include prominent text encouraging developers to consider using a dependency manager if possible, but it would effectively remove the potential for developers to accidentally download a malicious jar file from an unverified source and include it with their project.

TL;DR: If you don't include a direct downloads for MongoDB drivers/dependencies, a malicious actor on the internet will.

Hi,

We are currently using a pattern where we use a find(query).limit(x) and a count(query) with $near to find x results and display the overall count. Using this pattern, we are able to pass the same query to find and count. However that count method was removed in SCALA-517 and replaced by estimatedDocumentCount and countDocuments. The problem is that countDocuments will not work with $near. There is a workaround to use $geowithin with $center/$centerSphere, however this doesn't return the results sorted as $near did. We would like to have the option to pass the same query to count as we do to our find, even if there are risks associated as there was with count, an estimatedDocumentCount or unSafeCount, if you will, that accepts the same filter as our query.