Service interface generics map generates anyType2anyTypeMap WSDL

This is quite a disturbing bug indeed. Could you please post an example of your Interface.aegis.xml file?

<mappings>
<mapping>
<!-- We need to specify the HashMap types because Aegis does not detect
them correctly. -->
<method name="findMostRecentSources">
<return-type keyType="java.lang.Integer" componentType="my.package.Source"/>
</method>
</mapping>
</mappings>

I'm having the same issue with Maps in my application, while Lists are working correctly.

In debugging through the implementation, I see the following:

The logic in AbstractTypeCreator#createTypeForClass(TypeClassInfo) handles a Map before a collection in the if/else statement.

Java5TypeCreator does not override the createMapType(TypeClassInfo) method so AbstractTypeCreator is handling it instead. It does, however override createCollectionType(TypeClassInfo), which would explain why other types of collections besides Maps are working.

OK, I've read and debugged a little further. My previous assessment is incorrect.

Here is my revised assessment:

• The CustomTypeMapping in my environment has the following chain of type creators:
  XMLTypeCreator -> Java5TypeCreator -> DefaultTypeCreator

• The Java5TypeCreator implementation appears correct. If it cannot infer a Java 5 type, it defers to the next creator in the chain (I'm assuming this is the intended design pattern).

• XMLTypeCreator does not delegate to the next type creator when it can't resolve a type. Instead, it calls super.###. I'm guessing is a holdover from before the delegation chain pattern existed?

• XMLTypeCreator appears, however, to be able to resolve collections to a parameterized type on its own without help from the Java 5 Type Creator (they both call the same method in their respective implementations).

The aforementioned behavior causes the bug we are seeing because the Java5TypeCreator never gets its chance at bat due to XMLTypeCreator. If I change the relevant Map methods in XMLTypeCreator so that it is a good citizen and delegates to the next person in line, it should work.

Could I get a verification of my assessment from somebody who understands some of the history of this implementation so I don't go about causing an avalanche?

Here's my fix that appears to work on my system. Note that because the following map related methods are scoped protected, Java5TypeCreator could not properly delegate to the nextCreator. A proper version of this fix would change the scope of the getOrCreateMapKeyType and getOrCreateMapKeyValue methods to public, but I will leave that up to someone with commit rights to decide.

    protected Type getOrCreateMapKeyType(TypeClassInfo info)
    {
        Type type = null;
        if (info.getKeyType() != null)
            type = createTypeFromGeneric(info.getKeyType());
        
        if (type == null)
            type = nextCreator.getOrCreateMapKeyType(info);  // Give the next creator a shot
        
        return type;
    }

    protected Type getOrCreateMapValueType(TypeClassInfo info)
    {
        Type type = null;
        if (info.getGenericType() != null)
            type = createTypeFromGeneric(info.getGenericType());
        
        if (type == null)
            type = nextCreator.getOrCreateMapValueType(info);  // Give the next creator a shot
        
        return type;
    } 

    protected Type getOrCreateMapKeyType(TypeClassInfo info)
    {
    	if (info.getGenericType() != null) {
    		return getOrCreateParameterizedType(info.getGenericType(), 0);
    	} else {
    		return super.getOrCreateMapKeyType(info); // Because this method is protected & in a different package we can't delegate
    	}
    }

    protected Type getOrCreateMapValueType(TypeClassInfo info)
    {
        if (info.getGenericType() != null) {
    		return getOrCreateParameterizedType(info.getGenericType(), 1);
    	} else {
    		return super.getOrCreateMapValueType(info); // Because this method is protected & in a different package we can't delegate
    	}
    }

I'm seeing a perhaps related variation on the theme.

A return type of

MyClass[]

is handled correctly.

List<MyClass[]> turns into an array of anyType elements.

List<List<MyClass>> works correctly.

Any news on this one?

Yuck. I know that xfire 1.X is not cool anymore, but seeing as there is a proposed patch for this, can we get a bugfix release?

Is there any workaround besides changing the method signature?

public Map<String, String> blah() goes into anytype hell.

public List<StringPairObject> blah() works fine, if you want to monkey around with a new class holding two strings.

I know that I should really have a better domain object, nicer, purer, cooler XML than just key/value pairs, but that's how it goes. Is there any workaround for this? I see in the spring-xfire jar, xfire.xml,

<bean id="xfire.typeMappingRegistry"
class="org.codehaus.xfire.aegis.type.DefaultTypeMappingRegistry"
init-method="createDefaultMappings" singleton="true">
</bean>

So I guess I'm using Aegis. Where do I put this .aegis.xml file and what should it be called to work around this?

Note, this also affects 1.2.4 and 1.2.6.