You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Tim K. (Gmane)" <tk...@idpax.com> on 2005/04/06 07:50:35 UTC
design question xsd:anyType/java Object
Hello,
It seems that support for xsd:anyType (java Object) is optional in
JAX-RPC, though Axis supports it.
What would you suggest as an alternative to a JavaBean like this:
public class Property
{
private String name;
private Object value;
// getters + setters ...
}
It's useful in exposing methods like this:
public Property[] getProperties(...);
public void setProperties(Property[] props);
The current implementation works in Axis, at runtime everything seems to
be OK as long as the "value" is of a type that can be serialized.
Wrapped doc/literal doesn't support polymorphism from what I read.
I'm wondering if there are any issues I may run into (besides running
into a type that can't be serialized at runtime, I can prevent that at
least on the server side). Should I continue using it if it works or is
there a better approach?
Thanks.
--
Tim
Re: design question xsd:anyType/java Object
Posted by "Tim K. (Gmane)" <tk...@ugcs.net>.
Nobody can help with a design question? :(
I know there are smart people on this list, don't hold back ...
Tim
Tim K. (Gmane) wrote:
> Hello,
>
> It seems that support for xsd:anyType (java Object) is optional in
> JAX-RPC, though Axis supports it.
>
> What would you suggest as an alternative to a JavaBean like this:
>
> public class Property
> {
> private String name;
> private Object value;
>
> // getters + setters ...
> }
>
> It's useful in exposing methods like this:
>
> public Property[] getProperties(...);
> public void setProperties(Property[] props);
>
> The current implementation works in Axis, at runtime everything seems to
> be OK as long as the "value" is of a type that can be serialized.
>
> Wrapped doc/literal doesn't support polymorphism from what I read.
>
> I'm wondering if there are any issues I may run into (besides running
> into a type that can't be serialized at runtime, I can prevent that at
> least on the server side). Should I continue using it if it works or is
> there a better approach?
>
> Thanks.
>