Input parameter names generated into the WSDL still don't seem to be named correctly

This seems to occur when there is a serviceClass and an implementationClass which derives from it.

Are you compiling with debug symbols? Also are you using the Sun VM? i.e. I don't think the eclipse compiler works with this.

Hi Dan,

I'm compiling with full debug symbols and I'm using the Sun Java JRE 1.5_06.

Reading some of the header comments from the Apache library that you've used seems to indicate that it doesn't work with derived classes. When you only have a ServiceClass it works fine but when you have a ServiceClass and an ImplmentationClass which derives from the ServiceClass it stops working. I think this works in Apache because they don't have the concept of an Interface class and an Implementation class (which I think is great - if this worked). I think if you have put this feature in it should work with all models of creating the service.

I hope this helps.

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); }

/**

• read mappedName from aegis.xml file
• @param info
• @param parameter
  */
  protected void setMappedName(TypeClassInfo info, Element parameter)
  Unknown macro: { String mappedName = parameter.getAttributeValue("mappedName"); if (mappedName != null) { TypeClassInfoAccess.setMappedName(info, mappedName); } }

}

public class ImprovedAegisBindingProvider extends AegisBindingProvider {
public ImprovedAegisBindingProvider()

public ImprovedAegisBindingProvider(TypeMappingRegistry 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())

else if (TypeClassInfoAccess.getMappedName(info) != null)

} else

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)

}
</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>

Alright, I hear you guys now. This issue fell of my radar, but its back on it now. I'll see if we can't get a better way to do this in for our 1.1-beta in a week or two.

This patch is largely based on the solution provided by Roman Stumm, I just modified the classes directly instead of subclassing.

Rescheduling as we need to get the 1.1 beta out now

Just wondering if this fix will be in beta-2?

I was playing around with this a bit yesterday and today in 1.1-beta-1, and the mappedName stuff works fine for objects that are part of the model in my service, but appears to not work for the service object itself. So if I have a DocumentService with operation getWorklist(User user) returning a Worklist object, I create User.aegis.xml and Worklist.aegis.xml files and can set the mapped names for properties on those objects, but creating a DocumentService.aegis.xml file appears to not affect naming of methods, return-types, or parameters.

I'm working on it. It requires some changes, but I'll get there before 1.1...

This is fixed in SVN. Watch for a new snapshot in the next 24 hours (I'll update the date posted on the Download page).

the original issue was that parameter names are not retrived from method parameter names in some circumstances. This still is doesnt work, so i'm reopening it to investigate if its possible

not sure if i can fix this for 1.1.1 so i set it to 1.2

this would be a route we could go: http://jroller.com/page/eu?entry=using_asm_to_read_mathod

Descheduling this as no one has supplied any code to read parameter names from an interface.