Custom IDResolver gets wrong target type with IDREF collections

[Tomas-Kraus]

The issue is described in the forum: http://forums.java.net/jive/thread.jspa?threadID=45481&tstart=120

When using IDREFed collections:

@XmlIDREF Set ySet;

the resolve() method of a custom IDResolver gets Object.class as targetType, but it should be Y.class. This results on wrong ID resolving.

If I use an empty derived class instead:

class YSet extends HashSet {} ... @XmlIDREF YSet ySet;

then I get the right targetType in the resolve() method.

Environment

Operating System: All Platform: All

Affected Versions

[2.1.7]

[Tomas-Kraus]

• Issue Imported From: https://github.com/javaee/jaxb-v2/issues/546
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[Tomas-Kraus]

@glassfishrobot Commented Reported by uryssel

[Tomas-Kraus]

@glassfishrobot Commented @pavelbucek said: Would you please provide the schema file and/or reproducible testcase? Thanks in advance.

[Tomas-Kraus]

@glassfishrobot Commented @pavelbucek said: I agree with Wolfgang - see attached mail:

(workaround available and this is not part of jsr222 -> adjusting priority to P4)

================================================ The reason resolve() is called with Object.class for the target type when a field of some parameterized type is annotated with @XmlIDREF is simply because that's the way Java works. At runtime, Set is erased to Set<? extends Object> or Set<?>. See this simple test program and its output:

mport java.util.; import java.lang.reflect.; public class Reflect { public List sList; public ArrayList sArrayList; private static void dr( String fname ) throws Exception { Class reflectClass = Reflect.class; Field sListField = reflectClass.getField( fname ); System.out.println( sListField.toString() ); Class sListClass = sListField.getType(); System.out.println( sListClass.toString() ); if( sListClass instanceof GenericDeclaration )

{ TypeVariable<?>[] typeVars = sListClass.getTypeParameters(); System.out.println( "generic " + typeVars.length + " parameter" ); Type[] types = typeVars[0].getBounds(); System.out.println( "bounds " + types.length + ": " + types[0].toString() ); System.out.println( "name " + typeVars[0].getName() ); }

} public static void main( String[] args ) throws Exception

{ dr( "sList" ); dr( "sArrayList" ); }

}

public java.util.List Reflect.sList interface java.util.List generic 1 parameter bounds 1: class java.lang.Object name E public java.util.ArrayList Reflect.sArrayList class java.util.ArrayList generic 1 parameter bounds 1: class java.lang.Object name E

The code in com/sun/xml/bind/v2/runtime/reflect/Lister.java, latest release, around line 140 seems to indicate that the declared parameter type is available, but perhaps I've not understood it in full.

The ID Resolver is an extension of Sun's implementation. The official JAXB documentation doesn't contain any hint for this; as far as I know, Kohsuke's blog is the only place where this feature is published.

The original reporter has found a reasonable workaround by declaring a dedicated wrapper type for the parameterized container class, so that ID resultion into separate namespaces is applicable for IDREFs in containers as well.

================================================

[Tomas-Kraus]

@glassfishrobot Commented @pavelbucek said: I forgot change priority...

[Tomas-Kraus]

@glassfishrobot Commented ktcorby said: I think it would be much more convenient if there was an additional parameter to the annotation, like @IDRef(targetType=String.class) or possibly an additional annotation (@IDRefType(String.class)), so that the resolver could map to the proper type at runtime.

I realize this may not be a possible short-term solution, but I wanted to mention it.

[Tomas-Kraus]

@glassfishrobot Commented larsrc said: Created an attachment (id=322) Update example source showing the old example plus a part that shows that getGenericType can find the right type.

[Tomas-Kraus]

@glassfishrobot Commented larsrc said: Using getGenericType() instead of getType() allows you to find the actual type. With getType(), you're affected by erasure.

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Hello. Can you please tell can this issue be fixed? Thanks.

[Tomas-Kraus]

@glassfishrobot Commented yaroska said: Hi,realsonic3,

As I see with "getGenericType" is looks optimistic. So we will try to add it to 2.2.7.

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Sorry, but in which java version will be JAXB 2.2.7? Thanks a lot.

[Tomas-Kraus]

@glassfishrobot Commented yaroska said: It's no need to wait for JDK integration. You can use JAXB as standalone application.

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Can you please fill "Fix Version/s:" field?

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Hello. Can you please update when this issue will be fixed? Thanks.

[Tomas-Kraus]

@glassfishrobot Commented yaroska said: Hi,

I hope I'll be able to fix it in 2.2.8

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Let me please update you. This bug causes a problem that two or more objects with same ID but different types are unmarshalled as one type.

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Any chances it will be fixed in 2.2.8?

[Tomas-Kraus]

@glassfishrobot Commented yaroska said: We are quite busy with maintenance now. So I can't promise.

[Tomas-Kraus]

@glassfishrobot Commented realsonic3 said: Hi. Are there any chances to get the issue resolved?..

[Tomas-Kraus]

@glassfishrobot Commented File: Reflect.java Attached By: larsrc

[Tomas-Kraus]

@glassfishrobot Commented Was assigned to yaroska

[Tomas-Kraus]

@glassfishrobot Commented This issue was imported from java.net JIRA JAXB-546