On Wednesday 12 October 2005 22:21, Daniel Fagerstrom wrote: > Also Niclas Hedman have moved his post Merlin/Metro work to use context > dependency injection and it is built uppon OSGi, maybe he can comment on > it.
Not much to report in this ContextIoC [1] area. I have been busy porting Merlin/Metro to a OSGi bundle, where the Merlin/Metro services are seen by other bundles, and the Merlin/Metro services can use the OSGi services. And some stuff around all to make this work. All needed as migration path for the project I am involved. Other than that, most important observation in the OSGi adventure is probably that bundles becomes "just nice size" (or maybe it is just my preference). Not too large that 100s of classes needs to interact with each other with heaps of GoF patterns required to hold everything together, and essentially I don't feel I need any "component framework" at all. A dozen or two classes is typical bundle size for me, and all bundles that provides a service generates two Jars, one with the API and one for the impl, so the API can be placed in dependent bundles, as originally intended. That allows me to "fabricate" the needed components or their factories in the Activator, pass it down the line with constructor injection, and pretty set to go. I.e. I am on the same page as Pier when it comes to "I don't like complex solutions", and to me Spring is complex, Pico is complex, yes Merlin/Metro is complex. One gets sucked in slowly into these platforms, but end up fighting different kind of battles (XML hell) instead of coding Java. Anyway... With the "Feature" feature in OSGi R4, where sets of bundles are treated as mega-bundles, I think my "small bundle approach" makes very good sense, and a component-like organization is emerging. I still think that OSGi needs better implementations of many presecribed services, i.e Config, Prefs, Meta, User, Permission and so on services. I was hoping that Felix would become the place where those implementations flourished and could be shared across half a dozen projects at ASF alone. As for Cocoon to use OSGi, I am not familiar enough with the inner workings of Cocoon of today to have any clue of how hard that would be to remain compatible with previous versions. I guess that 100% compatibility is impossible, by the fact that there are no well-defined contracts, and any user could be using any internal bits that it happens to reach one way or the other. I hope the Cocooners can work all of this out, as the motivation for me to use Cocoon diminishes by the days, as it gets easier and easier to do stuff in competing platforms that only made sense in Cocoon previously. Cheers Niclas [1] http://www.theserverside.com/articles/article.tss?l=IOCandEJB
