(sorry for a bit lengthy mail) On Monday 04 July 2005 20:57, Daniel Fagerstrom wrote: <snip />
Thanks for the clarification. > Niclas, are you getting up to speed with OSGi? Well, I am tugging along with OSGi independently of Cocoon. As you probably know, I am from the Avalon camp, and has been working on running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components are exposed as OSGi services as well as ServiceManager.lookup() resolves to OSGi services if no 'local implementations' within the Metro container exist. I am still struggling with some classloading issues. Not sure if it is Knopflerfish or the OSGi spec, but the Oscar documentation mentioned that OSGi has tightened up the specification around classloading, i.e. less permissive. > Any thoughts about how to > use modern component management together with OSGi? I am no longer sure what "modern component management" would be ;o) IMHO, Spring's extensive use of XML seems to me to transfer coding from Java to XML, and remove the type-safety of Java. They say noone has a problem with it, but I think that is hype. I don't have any experience myself with Pico as such, but use CDI (not automatic) a lot myself. Lately, I have been working with an explicit custom management side. That means that each component is free to define its own management requirement, and optionally implement it if no existing pattern exists. That means that Pico and Spring *could* co-exist, together with a pattern called ContextIOC which I find really intriguing (well, I find the "official" pattern a bit confusing, but one can boil that down to something with better clarity.) Another aspect, is that it is possible to push a lot more of the so called "component management" over to "Build Time", and end up with "sealed components" that are already "resolved and configured". Such "sealed component" could end up as a Bundle for deployment, or even just a marshalled serialized binary ready to be put into action. All these are experiments that are being conducted and probably not relevant to Cocoon. Back to OSGi; The fact that bundles can be loaded, then manipulated (config, permissions, ++) and finally the entire OSGi platform saved into a deployment bundle is also an interesting aspect. For Cocoon it should mean that all services that has configuration, should implement ManagedService and store all their config state in the ServiceRegistration. Which means one can tune the running server and no need to worry about that getting lost on restarts. I am still a long way from understanding all aspects of OSGi. But to me one thing is fairly clear; The platform specifications are well balanced, allowing for rock-solid implementations in the difficult domain of classloading management. I like it a lot. I like the way I end up developing, hitting reload button after a compile. I like to manipulate configs and permissions in runtime. I like that only a fraction of the application is reloaded. BUT, it is easy to make mistakes keeping references to old instances in other bundles, causing all kinds of problems. So great care required! :o) Cheers Niclas
