The basic design is that contextual services are not part of the state of a control. If you attempt to serialize a Control, its contextual service references (at least the @Context annotated ones) will all be set to null by ControlBean.writeObject(). Post-deserialization, these are lazily reassociated/reinitialized in ControlBean.ensureControl.
The implication is that contextual services are stateless, or more accurately they only have transient state. In another way of looking at it, since they are contextual services, they should be provided by the deserialization context (i.e. the environment into which a control is being deserialized), not by the original (serialization) environment. The other things that _are_ part of the state of a serialized control are: - all properties which have been uniquely set on a control instance (but. *not* those that come from external config or annotations) and other basic info held on the ControlBean base class (see its non-transient fields). - any Java serialization state associated with the impl instance, including nested controls and any non-transient (and non-Context) fields. The overall goal is to keep the serialization state of the control as small as possible... things that can be reconstituted from the deserialization environment can and should be. -- Kyle On 4/14/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote: > Hi Kyle , all , > One more question since you mention about serialization below. > I see that the default ResourceContextImpl at > "org.apache.beehive.controls.runtime.bean" does not implement Serializable. > I dont understand why it does not (everything worked fine when I just > added the Serializable marker interface : a > serialization/deserialization test went ok) - maybe I am missing > something here ? > This is in light of what was discussed earlier that the > ControlImplementation's should all implement Serializable - so I guess > all the fields in it should hold references to instances which are > Serializable , correct ? > (Also note that it is not possible to override this from a custom > control container - since the contextual service gets added at the > ControlContainerContext.initialize() itself and javabeans does not allow > me to overwrite the service without using the same ServiceProvider - > which I cant get to since it is package private.) > So I cant even think of a workaround for this in a custom container > other than hacking at the custom container code ... except ofcourse to > make ResourceContextImpl serializable that is :) > > Thanks and Regards > Mridul > > > Kyle Marvin wrote: > > >Mridul, > > > >The intention is that Controls should be 100% conformant with the > >JavaBeans spec. You should be able to do things like: > > > >- load, introspect, and use the Control bean class in any JavaBeans aware > >editor > >- use a Control anywhere a JavaBean can be used (like <jsp:useBean> JSP tag) > > > >If there are areas where they are not, then these should be filed as > >high-priority JIRA issues. I checked the JAR spec, and "Java-Beans:" > >is the correct manifest attribute, so this is definitely an > >oversight/bug. > > > >Both this and the serialization issue (serializability of all > >code-generated or supporting runtime classes is definitely a reqt too) > >should be opened as "Critical/fix by V1" issues. > > > >Your Controls questions and feedback are proving to be invaluable.... > >keep 'em coming! :) > > > >-- Kyle > > > >On 4/14/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote: > > > > > >>Hi all, > >> > >> Since ControlBean is essentially a javabean , I wanted to see the > >>interoperatability of controls with a pure javabean env. > >>For this , I got the BDK1.1 > >>(http://java.sun.com/products/javabeans/software/bdk_download.html - yep > >>, I know this is old !) and tried to load a simple control jar in it. > >>I had to modify the BDK code to also accept "JavaBeans: true" as a > >>javabean (it had a check for only "Java-Beans" - btw , is this valid ? > >>Have not checked the spec yet on this). > >>What I found was that when I try to serialize a control after having > >>customized it , it throws an exception indicating that it cant be > >>serialized. > >>On some digging I found that this was 'cos > >>"org.apache.beehive.controls.api.properties.PropertyKey" had a field > >>"Method _getMethod;". > >>Now , since Method is not serializable , this fails serialization of the > >>entire ControlBean. > >> > >>So question would be whether this is the intended behavior - as in > >>Controls were not expected to interoperate with a plain vanilla javabean > >>env ? > >>(From what I have seen till now , beehive seems to go to great pains to > >>maintain interoperability and is not just using and riding over the > >>javabeans framework). > >>If it is expected to interoperate, then I guess this would be a bug. > >> > >>Any thoughts , comments , help would be greatly appreciated ! > >> > >>Thanks and Regards, > >>Mridul > >> > >> > >> >
