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.
>