Kyle,
I agree that the implementors of ControlHandle interface will be few and that should weigh on your decision. Again, my concern is the consistency offered to control authors who will need to expect a portable and predictable contract regarding ControlHandle. At a minimum the ControlHandle intent needs to be captured clearly with the level of detail that is there in EventRef. I too am fine with it extending Serializable, being JavaDoc'd that "is Serializable" is the indication of support for usage in a different context or even going so far to enhance the ControlHandle API with properties which characterize its ability. I could see a ControlHandle supporting at least the following capabilities:
1) non-externalizable
2) externalizable but VM instance scoped (handle can only be reconstituted in the same VM instance)
3) true network reference (like IORs, WS-Addressing EPR, etc)
maybe a property on ControlHandle of an enumeration type would support what we need but allow future version of Controls API to be extended.
matt
Kyle Marvin wrote:
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
