I saw your post on gemini-dev, but since I wasn't able to add much value, I disregarded it.
Although I am now leading the Gemini Blueprint project, I don't profess much skill in the area nor in Spring (in spite of working for SpringSource). It seems like the older I get, the less easily I consider that I've really understood something. Although I can use these technologies in a limited way, I don't really understand the "physics" of the implementation and it seems not many others do either.
With those caveats in mind, please see below.
On 29 May 2012, at 16:31, Raghuram Devarakonda wrote:
My question is really be related to Gemini blueprint but I am hoping that it is acceptable for this list as well. Few days back, I have posted the following to Gemini dev list and am copying it here in the hope that some one in Virgo community might have some idea about it. Here it goes:
I would like to ask couple of questions regarding the bug:
which talks about supporting "prototype" scope for
beans exported as OSGi services. In my tests, such beans behaved similar
to beans with "bundle" scope.
Upon reading "ServiceFactory" facility in OSGi, it seems to me that it
is not possible to implement "prototype" scope with the current OSGI
specification as the framework calls ServiceFactory.getService() only
once for each calling bundle. Is this correct?
Also, as stated above, "prototype" beans get
silently converted to "bundle" scoped beans (possibly inadvertently).
Isn't it better to fail loading contexts containing such beans?
That would have been a good idea originally, but introducing that behaviour now would introduce a backward incompatibility that could cause some people trouble. That's something I would reserve for a major release. Perhaps you could care to raise an enhancement.
Any insight into this issue is greatly appreciated.
virgo-dev mailing list