[ http://issues.apache.org/jira/browse/COCOON-1764?page=all ]
Reinhard Poetz closed COCOON-1764:
----------------------------------
Resolution: Won't Fix
component handling is done in a different way than it is described here. Other
issues will be open to describe the remaining open tasks
> 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
