Never mind -- looks like this is an issue returning Hibernate-loaded
beans. If the relationship is defined as eager, everything works as
expected. When defined as lazy, it seems like the Address proxy class
generated by Hibernate to handle the lazy loading fools the SOAP stack
into thinking it's the base class and not one of the subclasses.
I guess I should still say, if anyone knows if a workaround, that
would be great.
Or if there's some way to improve the SOAP handling so it can properly
decode the Hibernate proxy classes, that would be great too.
Thanks,
Aaron
On Mon, Nov 24, 2008 at 10:22 AM, Aaron Mulder
<[EMAIL PROTECTED]> wrote:
> I have a service exposed via JAX-WS and Spring with CXF 2.1.3. Some
> of the methods in the service interface return either an Address
> object or a Customer object which has a property of type Address
> (public Address getAddress). Further, Address has two subclasses,
> BusinessAddress and ResidentialAddress, and any instance is always one
> or the other of those subclasses. And the Address class is annotated
> with @XmlSeeAlso({BusinessAddress.class,ResidentialAddress.class})
>
> Now when I call the service method like this:
>
> public List<Address> getAllAddresses
>
> Then I get what I expect -- the SOAP client receives every entry as
> either a BusinessAddress or ResidentialAddress.
>
> But when I call the service method like this:
>
> public List<Customer> getAllCustomers
>
> Then there's a problem. Every customer's address comes through in the
> SOAP (verified with a log interceptor) as just a plain Address, not
> one of the subclasses. If I call the method directly in the same VM,
> I get the subclasses. So it seems to be a problem with the encoding
> of the SOAP return types, not a problem with what the service returns.
>
> Any ideas?
>
> Thanks,
> Aaron
>
