[ http://issues.apache.org/jira/browse/COCOON-1764?page=comments#action_12365175 ]
Daniel Fagerstrom commented on COCOON-1764: ------------------------------------------- The implementation is changed to a global registry. The current soultion is rather ECM specific though, and more work is needed to make it work with OSGi. > Component handling > ------------------ > > Key: COCOON-1764 > URL: http://issues.apache.org/jira/browse/COCOON-1764 > Project: Cocoon > Type: New Feature > Components: - Blocks Framework > Reporter: Reinhard Poetz > > see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113813135727508&w=2 > In the current implementation of blocks, each block has an own component > manager (the choice of which type is configurable) for managing the > components of the block. The block local CM has an InterBlockServiceManager > as parent manager and through it it can access components from component > managers in other blocks that it is *wired* to, (and not from the other > blocks of the system). Let us call this behavior wiring based CM for later > reference. > Now I'm starting to think that the above described behavior is unnecessarily > complicated and has some other problems as well. So if no one protests I'm > going to change it so that the blocks still has own component managers, but > that they register their (exposed) components in a global registry and that > the parent manager of the local component managers access components from the > global registry and not only from the connected blocks. > Consequences > ------------ > A global registry is much more similar to the situation in our "compile time" > blocks than the wiring based CM, so it should be easier to migrate, > furthermore so is a global registry used in OSGi so it will be more future > safe as well. > A global registry requires less configuration in block.xml and wiring.xml. It > is enough to declare the dependency on the interfaces of the components in > the POM. If one want to make certain that a certain block is used at run > time, a run time dependency can declared in the POM. Connections in the > block.xml is only used for declaring inter block servlet communication. > A possible disadvantage is that role names could collide in the global > registry but by using URIs or package names it should be possible to > distinguish between components from different manufacturers. > The global registry approach might give run time errors when components are > missing instead of deploy time errors. But this depends to a large extent on > what lookup strategy the components and the local CMs use. If most of the > component lookup is done from within the components using a service manager > the setup problems might be defered to runtime. But if configuration based > dependency injection is used the problems can at least in principle be > detected early. > Local vs Global CMs > ------------------- > A question that not will matter much until we use OSGi is whether the CMs are > used from within the block or from the outside. > The current design assumes that the CM is internal to each block. The reason > for this is that with OSGi R3 it was, IIUC, the only way to be able to have > the implementation classes for the components internal to the bundle. A > global CM would have requried that all implementation packages to be exported. > With R4 there are some new possibilities, one can get a class loader from a > bundle and use that for constructing components in a global CM. OSGi R4 uses > this for the new declarative services manager. A bundle that want to use the > declarative service manager signals that by pointing out its component > declaration with a special manifest header, "Service-Component". We could > have a similar global ECM++ manager for legacy support. It is rather probable > that there will be a OSGi adapted Spring CM, following the same principles. > --- o0o --- > AFAIR, we haven't discussed what lookup strategy we wanted for components in > blocks, I implemented the wiring based strategy because it seemed more > natural for me before. The OSGi CM bridge that Sylvain implemented used OSGis > service registry as a global registry. Gianugo tried to convince me that > global registry was better at ApacheCon, but I was obviously not ready for it > then -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
