Jeremy Boynes wrote:
This would work just as well - I could simply wrap the instance that I wanted to inject into the kernel in a SingletonFactory that always returned it, but this, until my current proxying approach throws up a problem, is no longer an issue, just a refactoring now.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.
I agree completely. I only got sidetracked into the lifecycle issue because David mentioned it as a concern.
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.
now these are valid concerns.
these are all things that will require someone having a deep understanding of both Geronimo and Spring proxying technologies and their interaction. I figured the best approach was to suck-it-n-see. With friends in both the Geronimo and Spring camp we should be able to overcome any issues that arise, or at least mark them as no-mans-land and steer people away from using the problem features with warnings etc.
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?
all interesting areas to look into.
let me get the code checked in (I need the cglib upgrade) and then i will look at some more serious testing - I may need some advice on how to tickle the kernel into doing these things...
Thanks
Thank you fot taking the time to go through this with me.
Better sooner than later :-)
too true :-)
Jules
-- Jeremy
-- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it."
/********************************** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net * * Open Source Training & Support. **********************************/
