Hi Scott,
Got to love how simple things are never quite simple with software (even
though we do our darndest..). To be honest I'm not 100% sure that we support
that use case at the moment. One hack that you could do is to create an
interface which delegates to your real service and returns the real type.
Unfortunately I don't think this syntax will work:
<return-type class="com.acme.UnitedStatesPostalAddress"/>
But please do file a JIRA for that.
Another option would be to have your own custom type:
<return-type type="UnitedStatesPostalAddressType"/>
And then your type would be:
public class UnitedStatesPostalAddressType extends BeanType {
public UnitedStatesPostalAddressType() {
super(new BeanTypeInfo(UnitedStatesPostalAddress.class, "namespace");
}
}
Cheers,
- Dan
On 12/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I need a little to something that I *thought* would be a no brainer,
but.....
Here's the environment....Using XFire 1.2.3 and Spring 1.2.6 to expose my
services as HTTP web-services...
Once exposed, most of the methods are right and work fine. However, I
have
a situation that doesn't work out of the box...
I have a service exposed as an interface like the one below....
//------------------------------------------------------------------------------
public interface CustomerSearchService {
...
public PostalAddress findCustomerPrimaryBillingAddress(String id);
...
}
//------------------------------------------------------------------------------
Ok, so no problem, I can call this method using a client and get back a
"PostalAddress"....
Now here's the problem...
PostalAddress is a marker interface...and contains no methods because the
implementation determines which derivitive address to return, like
UnitedStatesPostalAddress.
//------------------------------------------------------------------------------
public interface PostalAddress extends Serializable {
//Marker Only
}
//------------------------------------------------------------------------------
So what I want to do is tell Xfire to use my UnitedStatesPostalAddress as
the interface in which to derive the WSDL from.
I have tried multiple iterations of a aegis mapping file
CustomerSearchService.aegis.xml in the same package as my service
interface....
Here's what I think should work... but the end result is still the
same....
//------------------------------------------------------------------------------
<mappings>
<mapping>
<method name="findCustomerPrimaryBillingAddress">
<return-type componentType=
"com.xxx.ems.service.commons.model.UnitedStatesPostalAddress"/>
</method>
</mapping>
</mappings>
//------------------------------------------------------------------------------
The WSDL that is generated looks like this.... where obviously
PostalAddress is correctly identified as having NO methods, but that not
what I really need. My failed attempts at mapping, including the above
list <mappings> clip, have failed. The above <mappings> clip actually
prevents the server from starting up, yet I cannot determine why it
doesn't
like it.
//------------------------------------------------------------------------------
<xsd:element name="findCustomerPrimaryBillingAddress">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="in0"
nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="findCustomerPrimaryBillingAddressResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="out"
nillable="true" type="ns2:PostalAddress" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
<xsd:complexType name="PostalAddress" />
//------------------------------------------------------------------------------
Anyone know this framework better than me that can shed some light on the
subject, would be much appreciated.
Thanks,
Scott
This message contains information from Equifax Inc. which may be
confidential and privileged. If you are not an intended recipient, please
refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited. If you have
received this transmission in error, please notify by e-mail
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
