Hi Oliver,
This is a Java design pattern and there is no restriction by the spec on
using such a pattern. However the current JAX-RPC implementation does
not support this.
Hope that clarifies.
Thanks for your interest in JAX-RPC.
Regards,
-Arun
Oliver Suciu wrote:
> Once again, the interface is *not* serialized, only the
> concrete objects.
>
> The interface is *only* used in the method declaration.
>
> ???
>
> -- Oliver
>
> Arun Gupta wrote:
>
>>Hi Oliver,
>>
>>That will not be permitted as well.
>>
>>Because any classes involved in the serialization/deserialization should
>>have a default constructor. And since interfaces cannot have
>>constructors, they cannot be serialized.
>>
>>Hope that clarifies.
>>
>>-Arun
>>
>>Oliver Suciu wrote:
>>
>>>Fine -- so I can only serialize/deserialize concrete objects
>>>(of course)...
>>>
>>>However, can you please reconsider my example -- I was asking
>>>about interfaces as parameters in the *method declaration*
>>>("doSomething" in the code below); would that be allowed
>>>in JAX-RPC?
>>>
>>>
>>>>// the service to be exposed:
>>>>public interface MyServiceProvider extends java.rmi.Remote {
>>>> public MyData doSomething(MyData someData) throws
>>>>java.rmi.RemoteException;
>>>>}
>>>>
>>>>// the interface that all data objects must implement:
>>>>public interface MyData extends java.io.Serializable {
>>>>}
>>>>
>>>>// some specific data object:
>>>>public class SpecificData implements MyData {
>>>> public boolean flag;
>>>>}
>>>>
>>>So, the web service method (doSomething) declares an interface
>>>(MyData) as parameter type, but the actual objects passed between
>>>the client and the server would be of a concrete type (SpecificData).
>>>
>>>Would this work?
>>>
>>>Thanks,
>>>
>>>-- Oliver
>>>
>>>Arun Gupta wrote:
>>>
>>>>Hi Oliver,
>>>>
>>>>Any Java class that needs to be serialized/deserialized should be
>>>>compliant with section 5.3.5 of 0.5 version of the spec. Since
>>>>interfaces cant have a default constructor, they do not qualify as value
>>>>type.
>>>>
>>>>Hope that clarifies your doubt.
>>>>
>>>>Thanks for your interest in JAX-RPC.
>>>>
>>>>Regards,
>>>>-Arun
>>>>
>>>>Oliver Suciu wrote:
>>>>
>>>>>Thanks -- however, I'm still unclear.
>>>>>
>>>>>My question was not about Java value types, but about interfaces.
>>>>>Or, formulated differently, does a Java interface qualifiy as a
>>>>>Java value type?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>-- Oliver
>>>>>
>>>>>Arun Gupta wrote:
>>>>>
>>>>>>Hi Oliver/Simon,
>>>>>>
>>>>>>The current implementation on java.sun.com is compliant with 0.5 version
>>>>>>of the spec. JAX-RPC valuetypes are introduced after 0.5 version of the
>>>>>>spec. These will be supported in the next public release of Java Web
>>>>>>Services Developer Pack and Java XML Pack.
>>>>>>
>>>>>>Regards,
>>>>>>-Arun
>>>>>>
>>>>>>Simon Horrell wrote:
>>>>>>
>>>>>>>>From section 5.5 of the JAX-RPC spec.
>>>>>>>
>>>>>>>A JAX-RPC value type is a Java class whose value can be moved between a
>>>>>>>service
>>>>>>>
>>>>>>>client and service endpoint. A Java class must follow these rules to be a
>>>>>>>JAX-RPC
>>>>>>>
>>>>>>>conformant value type:
>>>>>>>
>>>>>>>. Java class must have a public default constructor.
>>>>>>>
>>>>>>>. Java class must not implement (directly or indirectly) the java.rmi.Remote
>>>>>>>
>>>>>>>interface.
>>>>>>>
>>>>>>>. Java class may implement any Java interface (except the java.rmi.Remote
>>>>>>>interface)
>>>>>>>
>>>>>>>or extend another Java class.
>>>>>>>
>>>>>>>. Java class may contain public, private, protected, package-level fields.
>>>>>>>The Java type
>>>>>>>
>>>>>>>of a public field must be a supported JAX-RPC type as specified in the
>>>>>>>section 5.1,
>>>>>>>
>>>>>>>"JAX-RPC Supported Java Types".
>>>>>>>
>>>>>>>. Java class may contain methods. There are no specified restrictions on the
>>>>>>>nature of
>>>>>>>
>>>>>>>these methods. Refer to the later rule about the JavaBeans properties.
>>>>>>>
>>>>>>>. Java class may contain static or transient fields.
>>>>>>>
>>>>>>>. Java class for a JAX-RPC value type may be designed as a JavaBeans class.
>>>>>>>In this
>>>>>>>
>>>>>>>case, the bean properties (as defined by the JavaBeans introspection) are
>>>>>>>required to
>>>>>>>
>>>>>>>follow the JavaBeans design pattern of setter and getter methods. The Java
>>>>>>>type of a
>>>>>>>
>>>>>>>bean property must be a supported JAX-RPC type as specified in the section
>>>>>>>5.1,
>>>>>>>
>>>>>>>"JAX-RPC Supported Java Types".
>>>>>>>
>>>>>>>Even though the spec allows value types with public fields I think the
>>>>>>>JAX-RPC reference implementation only supports JavaBeans right now. This
>>>>>>>means implementing (not extending) java.io.Serializable, having a public
>>>>>>>no-arg constructor and having public getter/setter methods for each of the
>>>>>>>fields to be [de]serialized.
>>>>>>>
>>>>>>>Si.
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "Oliver Suciu" <olivers_at_TIBCOFINANCE.COM>
>>>>>>>To: <JAXRPC-INTEREST_at_JAVA.SUN.COM>
>>>>>>>Sent: Thursday, March 07, 2002 2:52 AM
>>>>>>>Subject: interfaces as service parameters?
>>>>>>>
>>>>>>>
>>>>>>>>Hi all,
>>>>>>>>
>>>>>>>>Would the following work in JAX-RPC?
>>>>>>>>
>>>>>>>>// the service to be exposed:
>>>>>>>>public interface MyServiceProvider extends java.rmi.Remote {
>>>>>>>> public MyData doSomething(MyData someData) throws
>>>>>>>>java.rmi.RemoteException;
>>>>>>>>}
>>>>>>>>
>>>>>>>>// the interface that all data objects must implement:
>>>>>>>>public interface MyData extends java.io.Serializable {
>>>>>>>>}
>>>>>>>>
>>>>>>>>// some specific data object:
>>>>>>>>public class SpecificData implements MyData {
>>>>>>>> public boolean flag;
>>>>>>>>}
>>>>>>>>
>>>>>>>>???
>>>>>>>>
>>>>>>>>Thx,
>>>>>>>>
>>>>>>>>-- Oliver
>>>>>>>>
>>>>>>--
>>>>>>=============================================
>>>>>>There is only one me, I must live myself!
>>>>>>There is only one today, I must live itself!
>>>>>>=============================================
>>>>>>http://members.tripod.com/~apgupta/index.html
>>>>>>=============================================
>>>>>>
>>>>--
>>>>=============================================
>>>>There is only one me, I must live myself!
>>>>There is only one today, I must live itself!
>>>>=============================================
>>>>http://members.tripod.com/~apgupta/index.html
>>>>=============================================
>>>>
>>--
>>=============================================
>>There is only one me, I must live myself!
>>There is only one today, I must live itself!
>>=============================================
>>http://members.tripod.com/~apgupta/index.html
>>=============================================
>>
--
=============================================
There is only one me, I must live myself!
There is only one today, I must live itself!
=============================================
http://members.tripod.com/~apgupta/index.html
=============================================