1

少し複雑なオブジェクトを含む Web サービスで JAXB を使用しています。オブジェクトの 1 つである Sensor には、通信できる他のオブジェクトのリストがあり、必然的にそれ自体 (変更できない動作) を含めることができるため、XML へのマーシャリング中に循環参照が発生します。

@XmlAccessorType(XmlAccessType.FIELD)
public class Sensor extends BaseObject {
    private ArrayList<SensorCommLink> sensorCommLinks;
}

@XmlAccessorType(XmlAccessType.FIELD)
public class SensorCommLink {

    @XmlIDREF
    private BaseObject receiver;
    @XmlIDREF
    private Sensor cueingSensor;
}

@XmlAccessorType(XmlAccessType.FIELD)
public abstract class BaseObject {

    @XmlElement 
    @XmlID
    private String id;
}

上記のように、 @XmlIDREF と @XmlID を使用してこれを解決しましたが、非常にうまく機能します。

wsimport によって生成されたクライアント側コードは、オブジェクトを XML にマーシャリングし、サーバーはそれらを完全にアンマーシャリングできます。

私が経験している問題は、センサー オブジェクトをマーシャリングしようとすると、何らかの理由でサーバー側で循環参照例外が発生することです。腹立たしいのは、wsimport がクライアント側コードを作成するために使用する JAXB 注釈がサーバー側コードに含まれていることです。これはうまく機能しますが、サイクルのためにサーバー側センサーをマーシャリングできません。

JAXB がクライアント側のコードに追加するすべての余分な注釈をサーバー側のクラスにコピーしようとしましたが、おそらく JAXB に @XmlIDREF 注釈の適切な適用を妨げていたランタイム バグがあると考えました。そこには運がありません。

おそらく、ここで欠けている非常に基本的なものがありますが、この問題は私を少しバタバタさせており、それを理解しようとしている間、私は完全に停止しています.

調査中に気づいたことの 1 つは、コードは機能しますが、生成されたクライアント側オブジェクトの名前空間の一部が期待どおりではないということです。サーバー上の名前空間の問題が原因で IDREF マーシャリングが爆破されているかどうかを知りたいです。

4

1 に答える 1

1

サーバー側では、フィールド（インスタンス変数）ではなくプロパティ（get / set）を処理している可能性があります。次の方法でフィールドアクセスを強制できます。

@XmlAccessorType（XmlAccessType.FIELD）パブリッククラスSensorCommLink {

@XmlIDREF 
private BaseObject receiver; 
@XmlIDREF 
private Sensor cueingSensor;

}

または、getメソッドに注釈を付けることもできます。

于 2010-07-20T14:31:54.597 に答える