The problem with making an interface Serializable is that it doesn't
impose any obvious requirement on implementing classes to ensure that
their data members are themselves Serializable. It's easy to implement
the interface without realizing that this has ramifications for member
data. The kicker is that containers seem to handle a non-Serializable
class much better than they handle a Serializable class with
non-Serializable members; they often check for the former but blow up on
the latter. Just a thought/observation.
Rich
Kyle Marvin wrote:
Matt,
Thanks for the spelling out the analogies to EJBHandle. Given the use
cases for ControlHandles, I think that is 100% a reqt that the
implementations be Serializable, so if this is true, then perhaps the
best way to express this is by making it explicit via the
ControlHandle interface. The Javadoc and associated Control
Containment design doc (still a WIP at
http://incubator.apache.org/beehive/controls/controlsContainment.html),
can emphasize this well.
With respect to whether a ControlHandle is or is not a "network
reference", my take is that it can be, but should not be required to
be. There are potential containment scenarios for Controls, such as
a standalone VM, applet, ... where the ability to dispatch an network
event from the outside in might be problematic (no externalized
listeners), but where using a handle to enable a local async event
dispatch might still be interesting.
This being said, I get your point that this particular 'property' of a
ControlHandle might be useful and interesting. I can envision an API
like:
public interface ControlHandle {
...
public boolean isLocalHandle()
...
}
if 'true', this might indicate that the serialization/deserialization
context must be the same (from a container perspective) for the handle
to be able to properly dispatch events, or, if 'false' indicates that
the handle could actually be passed out externally w.r.t. the
constructing container with enough information (and a dispatch path)
to call back in (ala EJBHandle).
-- Kyle
On 4/27/05, Matthew Stevens <[EMAIL PROTECTED]> wrote:
Kyle,
It may be worth noting here that EJB Handle interface does extend
Serializable. However, it is clearly noted that EJB Handles are
considered "network references" and are only available to EJB clients of
remote EJBs. In my opinion the term "handle" implies a network
reference. Also, the asynchronous nature of the "event" use case for
ControlHandle, in practical server topologies, demands a "network"
aspect. For example, if someone wanted to create a Alarm Control which
acted as a business delegate to an EJB Timer Service, its worth noting
that the TimerHandle interface and the "info" property of Timer
interface are both Serializable. If ControlHandle does not prescribe
Serializable then a portable Alarm Control implementation would need to
not only assert that a ControlHandle was available, but that it was
Serializable as well.
If it is the intent of ControlHandle to be used for intra-VM
coordination of async events then I can understand why it does not
demand Serializable. In that case, there should be an API on
ControlHandle or a documented convention (e.g. checking for
serializable) which a control author can rely on to discern the
capability/policy of the ControlHandle in support of portable
implementations.
matt
Kyle Marvin wrote:
ControlHandle itself is just an interface... but you are 100% that
concrete implementations of ControlHandle should mplement
java.io.Serializable to enable them to be persisted, enqueued, passed
over a wire, etc.
In general, it's probably not a good idea to have an interface
implement Serializable and then have a corresponding impl pick it up
via an 'implements' inheritance relationship. You generally want a
class author to be thinking more explicitly about serialization in the
design of class state.
I'll add something to the Javadoc for Control Handle that states
"classes implementing this interface should be serializable". This
will make it more explicit, less implied.
-- Kyle
On 4/27/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote:
Hi all,
Is there any particular reason why ControlHandle does not implement
java.io.Serializable interface ?
From what I read , I would guess it is envisioned to be used in
situations which will need serialization/deserialization ...
Thanks and Regards
Mridul
