I'm actually OK either way, as long as the details are spelled out clearly in docs/Javadocs.
Keep in mind, providing a ControlHandle implementation is a job for a Control Container Author, not for a Control Author, so the target audience that has to understand this and get it right is much smaller.... -- Kyle On 4/27/05, Richard Feit <[EMAIL PROTECTED]> wrote: > 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 > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > > > > > > >
