XFire
  1. XFire
  2. XFIRE-35

Aegis needs to handle Polymorphic relationships

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0-M3
    • Fix Version/s: 1.2-RC
    • Component/s: Aegis Module
    • Labels:
      None
    • Number of attachments :
      2

      Description

      Nicolas Averseng writes:

      Let's take the following class structure as an example :

      public interface I
      {
      String getName();
      void setName(String name);
      }

      public class A implements I
      {
      private String m_name;

      public String getName()

      { return m_name; }

      public void setName(String name)

      { m_name = name; }

      }

      public class B extends A
      {
      private String m_data;

      public String getData)

      { return m_data; }

      public void setData(String data)

      { m_data = data; }

      }

      public interface SampleService1

      { public A getA(String name); public B getB(String name, int i); } public interface SampleService2 { public A getA(String name); public B getB(String name, int i); public I getI(String name); } public interface SampleService3 { public A getA(String name); public B getB(String name, int i); public Collection findSomeA() throws RemoteException; }

      1- When generating the WSDL for a service with interface SampleService1, the inheritance relationship between B and A is not included into the schema definition.

      <xsd:complexType name="B">
      <xsd:sequence>
      <xsd:element name="data" nillable="true" type="xsd:string"/>
      <xsd:element name="name" nillable="true" type="xsd:string"/>
      </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="A">
      <xsd:sequence>
      <xsd:element name="name" nillable="true" type="xsd:string"/>
      </xsd:sequence>
      </xsd:complexType>

      instead of :

      <xsd:complexType name="B">
      <xsd:complexContent>
      <xsd:extension base="A">
      <xsd:sequence>
      <xsd:element name="data" nillable="true" type="xsd:string"/>
      </xsd:sequence>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>
      <xsd:complexType name="A">
      <xsd:sequence>
      <xsd:element name="name" nillable="true" type="xsd:string"/>
      </xsd:sequence>
      </xsd:complexType>

      1. complexTypes.patch
        22 kB
        Xavier Fournet

        Issue Links

          Activity

          Hide
          Dan Diephouse added a comment -

          This isn't too hard to incorporate, but I don't know if I'll get to it before we do an M4 release.

          As a workaround you could provide your own wsdl with extended types.

          Show
          Dan Diephouse added a comment - This isn't too hard to incorporate, but I don't know if I'll get to it before we do an M4 release. As a workaround you could provide your own wsdl with extended types.
          Hide
          Dan Diephouse added a comment -

          We aren't going to get this in for M5. I'm not too sure of the usefulness either from an xml consumer standpoint.

          Show
          Dan Diephouse added a comment - We aren't going to get this in for M5. I'm not too sure of the usefulness either from an xml consumer standpoint.
          Hide
          Xavier Fournet added a comment -

          The patch for this issue has been provided by Řyvind Matheson Wergeland on the xfire-user mailing list, on 5/4/2006.
          I attach the patch file of Řyvind to this issue.

          Show
          Xavier Fournet added a comment - The patch for this issue has been provided by Řyvind Matheson Wergeland on the xfire-user mailing list, on 5/4/2006. I attach the patch file of Řyvind to this issue.
          Hide
          Fried Hoeben added a comment -

          Does the solution describe here also ensure that a call to SampleService.getA(name) may return a B? I.e. will the server also be aware that it may have to serialize all of B's properties, not just those defined by A?

          Show
          Fried Hoeben added a comment - Does the solution describe here also ensure that a call to SampleService.getA(name) may return a B? I.e. will the server also be aware that it may have to serialize all of B's properties, not just those defined by A?
          Hide
          Xavier Fournet added a comment -

          Updated patch in order to work on last XFire revision (#1455)

          Show
          Xavier Fournet added a comment - Updated patch in order to work on last XFire revision (#1455)
          Hide
          Dan Diephouse added a comment -

          How much of this patch works? anyone know what remains to be done?

          Show
          Dan Diephouse added a comment - How much of this patch works? anyone know what remains to be done?
          Hide
          Xavier Fournet added a comment -

          It seems to work well on WSDL generation (if objects appears in the method signatures) and serialisation/deserialisation parts.

          What is not handled :

          • force registration of extended class that doesn't appears in methods signatures, ie by addind a new service property
          • call the right serializer/deserializer on message reading/writing (handle the xsi:type attribute)
          Show
          Xavier Fournet added a comment - It seems to work well on WSDL generation (if objects appears in the method signatures) and serialisation/deserialisation parts. What is not handled : force registration of extended class that doesn't appears in methods signatures, ie by addind a new service property call the right serializer/deserializer on message reading/writing (handle the xsi:type attribute)
          Hide
          Chris Scudieri added a comment -
          {"call the right serializer/deserializer on message reading/writing (handle the xsi:type attribute)"}

          Has anybody looked at this? My data model uses a good deal of polymorphism and I tend to have a lot of collections
          of abstract types. As a result I have a lot of elements that look like:

          <Action xsi:type="GetInformationType" /> and the Server is having problems unmarshalling the message

          Show
          Chris Scudieri added a comment - {"call the right serializer/deserializer on message reading/writing (handle the xsi:type attribute)"} Has anybody looked at this? My data model uses a good deal of polymorphism and I tend to have a lot of collections of abstract types. As a result I have a lot of elements that look like: <Action xsi:type="GetInformationType" /> and the Server is having problems unmarshalling the message
          Hide
          Dan Diephouse added a comment -

          We've been working on this recently. Expect a commit in the next week or two with the necessary changes.

          Show
          Dan Diephouse added a comment - We've been working on this recently. Expect a commit in the next week or two with the necessary changes.
          Hide
          Stephane added a comment -

          The patch works fine on polymorphic relationships for Classes but not on polymorphic relationships for Exceptions.

          Could you confirm ?

          Show
          Stephane added a comment - The patch works fine on polymorphic relationships for Classes but not on polymorphic relationships for Exceptions. Could you confirm ?
          Hide
          Dan Diephouse added a comment -

          That patch is definitely not finished. We're still working on getting this into SVN, but expect it soon! We just need to get 1.1.1 out first.

          Show
          Dan Diephouse added a comment - That patch is definitely not finished. We're still working on getting this into SVN, but expect it soon! We just need to get 1.1.1 out first.
          Hide
          Stephane added a comment -

          Ok, thank you.

          Here, a nice article about polymorphic input parameters :
          http://www-128.ibm.com/developerworks/xml/library/ws-tip-xsdchoice.html

          It will be interesting if XFire implements this kind of mapping

          Show
          Stephane added a comment - Ok, thank you. Here, a nice article about polymorphic input parameters : http://www-128.ibm.com/developerworks/xml/library/ws-tip-xsdchoice.html It will be interesting if XFire implements this kind of mapping
          Hide
          Dan Diephouse added a comment -

          FYI - this is all in SVN now and has been pretty well tested. For those who want to get dirty checking out code and building xfire, feel free to play!

          Show
          Dan Diephouse added a comment - FYI - this is all in SVN now and has been pretty well tested. For those who want to get dirty checking out code and building xfire, feel free to play!
          Hide
          Dan Diephouse added a comment -

          Here is a snippet on how to use it:

          ObjectServiceFactory osf = (ObjectServiceFactory) getServiceFactory();

          HashMap props = new HashMap();
          props.put(AegisBindingProvider.WRITE_XSI_TYPE_KEY, Boolean.TRUE);

          ArrayList l = new ArrayList();
          l.add(Employee.class.getName());
          props.put(AegisBindingProvider.OVERRIDE_TYPES_KEY, l);

          endpoint = osf.create(InheritanceService.class,
          "InheritanceService",
          "urn:xfire:inheritance",
          props);

          getServiceRegistry().register(endpoint);

          Show
          Dan Diephouse added a comment - Here is a snippet on how to use it: ObjectServiceFactory osf = (ObjectServiceFactory) getServiceFactory(); HashMap props = new HashMap(); props.put(AegisBindingProvider.WRITE_XSI_TYPE_KEY, Boolean.TRUE); ArrayList l = new ArrayList(); l.add(Employee.class.getName()); props.put(AegisBindingProvider.OVERRIDE_TYPES_KEY, l); endpoint = osf.create(InheritanceService.class, "InheritanceService", "urn:xfire:inheritance", props); getServiceRegistry().register(endpoint);
          Hide
          Keith Garry Boyce added a comment -

          This also I can confirm is not entirely working for the case when Object is returned from an object contained in an exception. I was told:

          XFIRE-35: We need to make the getters and setters be Strongly typed until Jira is completed.

          Show
          Keith Garry Boyce added a comment - This also I can confirm is not entirely working for the case when Object is returned from an object contained in an exception. I was told: XFIRE-35 : We need to make the getters and setters be Strongly typed until Jira is completed.

            People

            • Assignee:
              Dan Diephouse
              Reporter:
              Arjen Poutsma
            • Votes:
              7 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: