Jules Gosnell wrote:
<snip for the sake of clarity on the following points/>
To what extent is it necessary for Spring to register the actual POJOs at runtime? How much can be built before hand and be packaged into a Geronimo Configuration?
Good question.... I guess it comes down to the fact that user code may be supplied to create the beans inside Spring. So, these must be created at runtime, since we have no protocol with which we can dehydrate/rehydrate them in the way that we can a normal J2EE app. Since, I don't actually see the full set of Beans until runtime, i don't have a chance to build GBean proxies for them until this point. maybe we can break up the process somewhere in Spring and get all this information out without actually creating the bean instances themselves - Rob ?
Would an alternative here be to change the GBean wrapper so that instead of constructing the target itself it called out to a factory defined in the GBeanInfo? Basic Geronimo could continue to use the constructor but we would call back to Spring or the user's factory.
To me, the challenges here are not in the lifecycle but in how references between objects are handled. I would have thought some level of proxy integration would also be needed with integration at this low a level.
So, can we drill down on this - what problems do you foresee that putting a proxy, dumb or otherwise, between me and you will solve ? I simply create the beans when i am started and destroy them when i am stopped....
I think there are two things going on here.
Firstly, there is a desire to expose Spring components to management via Geronimo's infrastructure (JMX or otherwise). In the same way Spring can register them directly with JMX, we would like to support the ability to register them with Geronimo - this is what your patch is doing and in this simple scenario I see no issues.
Secondly, and this is where I see concerns, is that both Spring and Geronimo already intercept inter-component references and replace them with proxies. If the reference type is a interface we may be OK, but we both support proxied references to classes and I am concerned about interference between the two proxy mechanisms - for example, if the only thing Geronimo knows about is the cglib proxy and it contains final methods.
In any non-trival example, the POJO you are registering is going to contain Spring proxies for the inter-POJO references. Can we leave those as they are, or do we need to re-proxy them with Geronimo references? Do we need to add a mechanism to the kernel to allow Spring to obtain a Geronimo reference to a GBean so that it can inject it up front?
Geronimo transparently re-proxies references (and updates collection valued ones) as a referenced GBean gets loaded and unloaded. Will this continue to work with Spring proxies present?
Thanks
Thank you fot taking the time to go through this with me.
Better sooner than later :-) -- Jeremy
