Spring Data MongoDBは_CLASS情報を無視します

Question

Spring-Data-MongoDB 1.3.3.releaseとJava 1.6を使用していくつかの問題があります。

私のセットアップはレガシーデータに対処しなければならないので、私はカスタムTypeMapper（DefaultMongoTypeMapper）と2つの異なる読み書きコンバータの組み合わせを持っています。さらに、@TypeAliasを使用して、データベース内の_class情報を設定します。

問題のあるモデルはいくつかの入れ子になったリストで構成されています、いくつかは

のように型付けされます

List<DocumentValue>

.

myObjectにオブジェクトリストを含めることができます

List<Object>

.

これは他のDocumentValueオブジェクトを含むことができます。

この設定は機能しているようです、単体テストは問題なく実行されます。オブジェクトマッピングはデバッガではかなり素晴らしく見えます。私のアプリケーションはWebアプリケーションであり、DocumentValueをコレクションに書き込むことができ、_class情報が存在します。

サーバをシャットダウンしない（マイケースのTomcat）、オブジェクトマッピングは機能します。しかし、サーバーを再起動する（新しいJVMを起動する）、DocumentValueオブジェクトは正しくマッピングされていませんが、java.util.Mapとして扱われます。 _class情報は無視されているようです。マッピングコンテキストに問題があるかもしれないと思います（春のコンテキストが開始されている間、モデルエンティティは登録されますか？）が、誤構成を見つけることができません。誰かがいくつかの類似の問題を抱えているか、いくつかの提案をしましたか？

Answer 1

あなたの返事をありがとう。 _classが無視された理由が見つかったと思います。あなたは正しいです、私はTypeMapperの珍しい組み合わせを使います。

私のカスタムタイプマッパーを見せてみましょう：

public class CustomTypeMapper extends DefaultMongoTypeMapper {

    public CustomTypeMapper (MongoMappingContext mappingContext) {

        super(DEFAULT_TYPE_KEY,
                Arrays.asList(new MappingContextTypeInformationMapper(
                        mappingContext)));
    }

    @Override
    public <T> TypeInformation<? extends T> readType(DBObject source,
            TypeInformation<T> basicType) {

        // do some custom recognition

                // or just to the common type mapping
        return super.readType(source, basicType);

    }
}

.

一般的なタイプ認識の横にある特別なことは、MappingContextTypeInformationSmapperが@TypeAliasアノテーションを使用するために使用されるコンストラクタです。

ここでのキーは、必要なMongomAppongContextです。機能的なケースでは、

のようなCustomTypeMapperを初期化しました

<bean id="customTypeMapper" class="de.flexguse.repository.CustomTypeMapper">
    <constructor-arg name="mappingContext">
        <bean class="org.springframework.data.mongodb.core.mapping.MongoMappingContext" />
    </constructor-arg>
</bean>

.

MongomapingContextの新しいインスタンスには、

でbase-package属性を設定したタイプ情報が含まれていないため、間違っていました。

<mongo:mapping-converter id="customMappingConverter" db-factory-ref="mongoDbFactory"
        type-mapper-ref="customTypeMapper" base-package="de.flexguse.model" >

    <mongo:custom-converters>
            ... some custom converters ...
    </mongo:custom-converters>

</mongo:mapping-converter>

.

残念ながら、MongomapingContextがConstructor引数として使用できるように作成される場所を理解することができませんでしたので、@Autowire

を使用してMongomapingContextを取得する単純なBean MongomapingContextProviderを発明しました。

public class MongoMappingContextProvider {

    @Autowired
    private MongoMappingContext mappingContext;

    /**
     * @return the mappingContext
     */
    public MongoMappingContext getMappingContext() {
        return mappingContext;
    }

}

.

CustomTypeMapperのスプリング構成は、この

のように見えます。

<bean id="mongoMappingContextProvider" class="de.flexguse.repository.MongoMappingContextProvider" />

<bean id="customTypeMapper" class="de.flexguse.repository.CustomTypeMapper">
    <constructor-arg name="mappingContext" value="#{mongoMappingContextProvider.mappingContext}" />
</bean>

.

この解決策は私にとって働きます。

ところで、すべてのモデルBeanではすべての型情報をすべてのモデル情報に関連付けていて、永続化されているすべてのモデルBeanに追加されました。）

おそらくこれは同様の問題がある他の誰かに役立ちます。

Christoph

Answer 2

TypeMapperの使用量とコンバータの異常な組み合わせにより、問題を疑うと考えています。 の場合、特定の種類の手動で実装されたConverterインスタンスが登録されているため、ConverterはMongoDBによって永続的かつ読みやすいオブジェクトを作成する責任があります。これは、コンバータインスタンスが型情報自体を書く必要があることを意味します。

仕事に入れることができず、小さなサンプルプロジェクトをコンパイルして問題を再現する（好ましくはテストケースが実行する）、 jira インスタンス