Hi,
IWe had the same problem (parameters in WSDL named "in0"...) and did not want to rely on debug-information. We also needed the interface (our implemenation is a proxy). So we created a subclass of XMLTypeCreator and of AegisBindingProvider so use the "mappedName" attribute for parameters of our operations:
<xmp>
<pre>
public class ImprovedXMLTypeCreator extends XMLTypeCreator {
/**
- read more infos from aegis.xml file than the superclass
*/
protected void readMetadata(TypeClassInfo info, Element parameter)
{
super.readMetadata(info, parameter);
setMappedName(info, parameter);
}
/**
}
public class ImprovedAegisBindingProvider extends AegisBindingProvider {
public ImprovedAegisBindingProvider()
{
super();
}
public ImprovedAegisBindingProvider(TypeMappingRegistry registry)
{
super(registry);
}
public QName getSuggestedName(Service service, OperationInfo op, int param) {
TypeMapping tm = getTypeMapping(service);
if (tm.getTypeCreator() instanceof AbstractTypeCreator) {
final AbstractTypeCreator creator = (AbstractTypeCreator) tm
.getTypeCreator();
TypeClassInfo info = creator.createClassInfo(op.getMethod(), param);
Type type = creator.createType(op.getMethod(), param);
if (type.isComplex() && !type.isAbstract())
{
return type.getSchemaType();
}
else if (TypeClassInfoAccess.getMappedName(info) != null)
{
return new QName(TypeClassInfoAccess.getMappedName(info));
}
} else
{
return super.getSuggestedName(service, op, param);
}
return null;
}
}
package org.codehaus.xfire.aegis.type;
import org.codehaus.xfire.aegis.type.AbstractTypeCreator.TypeClassInfo;
/**
- Class must be in this package to grant access to TypeClassInfo.mappedName
- (default visibility, no accessors in Aegis provided).
- @author SAO
*
*/
public class TypeClassInfoAccess {
public static void setMappedName(TypeClassInfo info, String value)
{
info.mappedName = value;
}
public static String getMappedName(TypeClassInfo info)
{
return info.mappedName;
}
}
</xmp>
</pre>
So we could configure it with Spring and use the mappedName for parameters.
If this kind of solution does not contradict the idea of XFire, we would be glad, if the next release provides some kind of such a solution so that we can control the WSDL-names in the aegis.xml mapping file.
This solution seems to work, but we do not like the class TypeClassInfoAccess (there are not getters/setters for mappedName) and the downcast to AbstractTypeCreator in the BindingProvider there.
With best regards,
Roman Stumm
Our Spring config to activate the new classes:
<xmp>
<pre>
<bean id="my.xfire.serviceFactory"
class="org.codehaus.xfire.service.binding.ObjectServiceFactory"
singleton="true">
<constructor-arg index="0">
<ref bean="xfire.transportManager" />
</constructor-arg>
<constructor-arg index="1">
<ref bean="my.xfire.aegisBindingProvider" />
</constructor-arg>
</bean>
<bean id="myxfire.typeMappingRegistry"
class="org.codehaus.xfire.aegis.type.DefaultTypeMappingRegistry"
init-method="createDefaultMappings" singleton="true">
<property name="typeCreator" ref="my.xfire.typeCreator" />
</bean>
<bean id="my.xfire.typeCreator"
class="my.xfire.ImprovedXMLTypeCreator">
<property name="nextCreator">
<bean class="org.codehaus.xfire.aegis.type.DefaultTypeCreator" />
</property>
</bean>
<bean id="my.xfire.aegisBindingProvider"
class="my.xfire.ImprovedAegisBindingProvider"
singleton="true">
<constructor-arg index="0">
<ref bean="my.xfire.typeMappingRegistry" />
</constructor-arg>
</bean>
</pre>
</xmp>
Bug
Reopened
Major
This seems to occur when there is a serviceClass and an implementationClass which derives from it.