[#XFIRE-673] CLONE -Arrays of Collections do not map correctly [Patch Included] - Not Fixed - jira.codehaus.org

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 1.1.2, 1.2-RC, 1.2
Fix Version/s: 1.2.2
Component/s: Aegis Module
Labels:
None
Environment:
Xfire 1.1.2

Number of attachments :
0

Description

If I have a Service that returns an array of Collections / Map XFire fails saying that the keytype and componentType are not defined.

The problem seems to be that when an array is returned, XFire creates a new TypeInfo for the nested List / Map which does not inherit the keyType and componentType defined in the aegis mapping.

Here is an example

interface ArrayService{
    	public Map[] getMapArray();

	public List[] getArrayOfListsOfDoubles();
}

<mappings>
    <mapping>
                 <method name="getMapArray">
			<return-type keyType="java.lang.Double" componentType="java.lang.Double" />
		</method>

		<method name="getArrayOfListsOfDoubles">
			<return-type componentType="java.lang.Double" />
		</method>
    </mapping>
</mappings>

The problem was found at AbstractTypeCreator line 310. This was modified so now it looks like the following:

TypeClassInfo nestedInfo = createBasicClassInfo(componentType);
            nestedInfo.setKeyType(info.getKeyType());
            nestedInfo.setGenericType(info.getGenericType());

        	type = createTypeForClass(nestedInfo);
            getTypeMapping().register(type);

We will try to add the testcase for these scenarios.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Andres Bernasconi added a comment - 26/Sep/06 4:35 PM

Sorry for this clone, could not reopen the issue.

I am having the exact same problem on XFire 1.2.1 so I think this issue it is not closed.

Here are the details.

XMLTypeCreator.java:359
the KeyType for the InfoBean is still null, that is, it is not being "inherited" from the parent info bean which is an ArrayType. This makes XFire create a 'default' type in line 366, which returns an ObjecType. This object, in turn, has no typeMapping defined and causes my program to crash dramatically at:

Caused by: java.lang.NullPointerException
        at org.codehaus.xfire.aegis.type.basic.ObjectType.readObject(ObjectType.java:102)
        at org.codehaus.xfire.aegis.type.collection.MapType.readObject(MapType.java:70)
        at org.codehaus.xfire.aegis.type.basic.ArrayType.readCollection(ArrayType.java:80)
        at org.codehaus.xfire.aegis.type.basic.ArrayType.readObject(ArrayType.java:48)
        at org.codehaus.xfire.aegis.type.basic.BeanType.readObject(BeanType.java:180)
        at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:155)
        at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206)
        at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50)
        at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)

Don't know if this is a problem affecting anybody else but me but...

Best Regards,
Andres Bernasconi.

Show

Andres Bernasconi added a comment - 26/Sep/06 4:35 PM Sorry for this clone, could not reopen the issue. I am having the exact same problem on XFire 1.2.1 so I think this issue it is not closed. Here are the details. XMLTypeCreator.java:359 the KeyType for the InfoBean is still null, that is, it is not being "inherited" from the parent info bean which is an ArrayType. This makes XFire create a 'default' type in line 366, which returns an ObjecType. This object, in turn, has no typeMapping defined and causes my program to crash dramatically at:

Caused by: java.lang.NullPointerException
        at org.codehaus.xfire.aegis.type.basic.ObjectType.readObject(ObjectType.java:102)
        at org.codehaus.xfire.aegis.type.collection.MapType.readObject(MapType.java:70)
        at org.codehaus.xfire.aegis.type.basic.ArrayType.readCollection(ArrayType.java:80)
        at org.codehaus.xfire.aegis.type.basic.ArrayType.readObject(ArrayType.java:48)
        at org.codehaus.xfire.aegis.type.basic.BeanType.readObject(BeanType.java:180)
        at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:155)
        at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206)
        at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50)
        at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)

Don't know if this is a problem affecting anybody else but me but... Best Regards, Andres Bernasconi.

Hide

Permalink

Dan Diephouse added a comment - 27/Sep/06 9:44 PM

OK, I'll check into this for 1.2.2

Show

Dan Diephouse added a comment - 27/Sep/06 9:44 PM OK, I'll check into this for 1.2.2

Hide

Permalink

Dan Diephouse added a comment - 29/Sep/06 1:15 PM

Have you tried this format?

Its documented here:

http://xfire.codehaus.org/Mapping+collections

Going to check into the NPE some more though...

Show

Dan Diephouse added a comment - 29/Sep/06 1:15 PM Have you tried this format? <mapping> <method name="getMapArray"> <return-type componentType="#map" /> </method> <component name="map" class="java.util.Map" typeName="SomeMap" keyType="java.lang.Double" componentType="java.lang.Double" /> </mapping> Its documented here: http://xfire.codehaus.org/Mapping+collections Going to check into the NPE some more though...

Hide

Permalink

Dan Diephouse added a comment - 29/Sep/06 4:27 PM

I think I've fixed an issues in SVN. Here is a patched build:

http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20060929.210820-24.jar

You'll want to use that syntax I outlined in my last comment though.

Show

Dan Diephouse added a comment - 29/Sep/06 4:27 PM I think I've fixed an issues in SVN. Here is a patched build: http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20060929.210820-24.jar You'll want to use that syntax I outlined in my last comment though.

Hide

Permalink

Dieter Bachmann added a comment - 06/Oct/06 2:30 AM

I'm not shure, if my actual problem is related to this issue: Using xfire 1.2.2 on Java 5 with annotations.

The strcture we are using contains of a a class that contains a List of an other class. The second class contains another list of a class. It's more or less a two-dimensional dynamic array.

the wsdl created contains only the second list. the first list is ignored.

<code java>
public class a{
private List<b> bList;

// getters and setters....
}

public class b{
private List<c> cList
// getters and setters ....
}

public class c{
//members..
//getters and setters...
}
</code>

The resulting WSDL holds a complex-type ArrayOfc but shows b instead of Arrayfb

any ideas, where this comes from or how to resolve this problem?

best regards
dieter

Show

Dieter Bachmann added a comment - 06/Oct/06 2:30 AM I'm not shure, if my actual problem is related to this issue: Using xfire 1.2.2 on Java 5 with annotations. The strcture we are using contains of a a class that contains a List of an other class. The second class contains another list of a class. It's more or less a two-dimensional dynamic array. the wsdl created contains only the second list. the first list is ignored. <code java> public class a{ private List<b> bList; // getters and setters.... } public class b{ private List<c> cList // getters and setters .... } public class c{ //members.. //getters and setters... } </code> The resulting WSDL holds a complex-type ArrayOfc but shows b instead of Arrayfb any ideas, where this comes from or how to resolve this problem? best regards dieter

People

Assignee:

Dan Diephouse

Reporter:

Andres Bernasconi

Vote (0)

Watch (1)

Dates

Created:

26/Sep/06 4:28 PM

Updated:

06/Oct/06 2:30 AM

Resolved:

29/Sep/06 4:27 PM