XFire

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. Text File
    complexTypes.patch
    25/Apr/06 9:41 AM
    22 kB
    Xavier Fournet

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. XFIRE-173 Exception inheritance not handled correctly

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (7)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: