You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Mridul Muralidharan <Mr...@Sun.COM> on 2005/04/27 09:01:22 UTC
ControlHandle
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
Re: ControlHandle
Posted by Matthew Stevens <Ma...@Sun.COM>.
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 <ri...@bea.com> 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 <Ma...@sun.com> 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 <Mr...@sun.com> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
Re: ControlHandle
Posted by Kyle Marvin <ky...@gmail.com>.
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 <ri...@bea.com> 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 <Ma...@sun.com> 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 <Mr...@sun.com> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
>
Re: ControlHandle
Posted by Richard Feit <ri...@bea.com>.
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 <Ma...@sun.com> 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 <Mr...@sun.com> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
>
Re: ControlHandle
Posted by Kyle Marvin <ky...@gmail.com>.
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 <Ma...@sun.com> 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 <Mr...@sun.com> 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
> >>
> >>
> >>
>
>
Re: ControlHandle
Posted by Matthew Stevens <Ma...@Sun.COM>.
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 <Mr...@sun.com> 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
>>
>>
>>
Re: ControlHandle
Posted by Kyle Marvin <ky...@gmail.com>.
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 <Mr...@sun.com> 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
>