Hi Kyle ,
Thanks for pointing this out - my mistake : I did not see the attempt to re-associate the dependency injected resources.
But I had observed attempts to serialize the ResourceContextImpl's failing time and again (earlier on) - so decided to dig a bit more : was not sure if this was fixed recently too !
What I found out is that "public void initServices(ControlBean bean, Object target)" in the generated ImplInitializer has all the dependency injection done properly : Context , ResourceContext , etc.
While for "public void resetServices(ControlBean bean, Object target)" , only the context was getting reset to null.
I think this is the reason why I observed the attempts to serialize a ResourceContextImpl - since the field was not getting reset to null.
So , this would mean that we would typically need to reset all resource we injected in initServices while executing resetServices.
Please correct me if my understanding is wrong.
Thanks Mridul
Kyle Marvin wrote:
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
