XFire
  1. XFire
  2. XFIRE-265

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

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0-RC
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows 2000 Pro, Java JRE 1.5-06
    • Number of attachments :
      1

      Description

      I see that the issue regarding the naming of input parameters to match the Java API specs was reported fixed in 1.0-RC1. I've just downloaded 1.0-RC1 from your website and it still seems to be generating a WSDL with input parameters named in0, in1, in2 etc ?

      Any ideas ??

      Cheers

      Matt Shaw

        Activity

        Hide
        Matt Shaw added a comment -

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

        Show
        Matt Shaw added a comment - This seems to occur when there is a serviceClass and an implementationClass which derives from it.
        Hide
        Dan Diephouse added a comment -

        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.

        Show
        Dan Diephouse added a comment - 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.
        Hide
        Matt Shaw added a comment -

        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.

        Show
        Matt Shaw added a comment - 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.
        Hide
        Roman Stumm added a comment -

        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()

        { 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>

        Show
        Roman Stumm added a comment - 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() { 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>
        Hide
        Dan Diephouse added a comment -

        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.

        Show
        Dan Diephouse added a comment - 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.
        Hide
        Jack Xu Hong added a comment -

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

        Show
        Jack Xu Hong added a comment - This patch is largely based on the solution provided by Roman Stumm, I just modified the classes directly instead of subclassing.
        Hide
        Dan Diephouse added a comment -

        Rescheduling as we need to get the 1.1 beta out now

        Show
        Dan Diephouse added a comment - Rescheduling as we need to get the 1.1 beta out now
        Hide
        Jeffrey Bonevich added a comment -

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

        Show
        Jeffrey Bonevich added a comment - Just wondering if this fix will be in beta-2?
        Hide
        Jeffrey Bonevich added a comment -

        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.

        Show
        Jeffrey Bonevich added a comment - 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.
        Hide
        Dan Diephouse added a comment -

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

        Show
        Dan Diephouse added a comment - I'm working on it. It requires some changes, but I'll get there before 1.1...
        Hide
        Dan Diephouse added a comment -

        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).

        Show
        Dan Diephouse added a comment - 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).
        Hide
        Christoph Sturm added a comment -

        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

        Show
        Christoph Sturm added a comment - 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
        Hide
        Christoph Sturm added a comment -

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

        Show
        Christoph Sturm added a comment - not sure if i can fix this for 1.1.1 so i set it to 1.2
        Hide
        Christoph Sturm added a comment -
        Show
        Christoph Sturm added a comment - this would be a route we could go: http://jroller.com/page/eu?entry=using_asm_to_read_mathod
        Hide
        Dan Diephouse added a comment -

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

        Show
        Dan Diephouse added a comment - Descheduling this as no one has supplied any code to read parameter names from an interface.

          People

          • Assignee:
            Christoph Sturm
            Reporter:
            Matt Shaw
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: