History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XFIRE-35
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dan Diephouse
Reporter: Arjen Poutsma
Votes: 7
Watchers: 9
Operations

If you were logged in you would be able to see more operations.
XFire

Aegis needs to handle Polymorphic relationships

Created: 06/Apr/05 11:06 AM   Updated: 25/Jul/06 03:26 PM
Component/s: Aegis Module
Affects Version/s: 1.0-M3
Fix Version/s: 1.2-RC

Time Tracking:
Not Specified

File Attachments: 1. Text File complexTypes.patch (22 kb)
2. Zip Archive InheritancePath.zip (2 kb)

Issue Links:
dependent
 


 Description  « Hide
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>



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Dan Diephouse - 07/Apr/05 10:47 AM
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.


Dan Diephouse - 01/Jun/05 10:19 PM
We aren't going to get this in for M5. I'm not too sure of the usefulness either from an xml consumer standpoint.

Xavier Fournet - 18/Apr/06 07:13 AM
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.

Fried Hoeben - 24/Apr/06 09:13 AM
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?

Xavier Fournet - 25/Apr/06 09:41 AM
Updated patch in order to work on last XFire revision (#1455)

Dan Diephouse - 25/Apr/06 10:06 AM
How much of this patch works? anyone know what remains to be done?

Xavier Fournet - 25/Apr/06 10:22 AM
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)

Chris Scudieri - 02/Jun/06 04:30 PM
{"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


Dan Diephouse - 02/Jun/06 05:04 PM
We've been working on this recently. Expect a commit in the next week or two with the necessary changes.

Stephane - 14/Jun/06 09:16 AM
The patch works fine on polymorphic relationships for Classes but not on polymorphic relationships for Exceptions.

Could you confirm ?


Dan Diephouse - 14/Jun/06 01:19 PM
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.

Stephane - 15/Jun/06 09:21 AM
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


Dan Diephouse - 23/Jun/06 01:15 PM
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!

Dan Diephouse - 23/Jun/06 01:16 PM
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);


Keith Garry Boyce - 25/Jul/06 03:26 PM
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.