You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Reinhard Poetz (JIRA)" <ji...@apache.org> on 2006/02/02 23:27:03 UTC
[jira] Created: (COCOON-1764) Component handling
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
[jira] Closed: (COCOON-1764) Component handling
Posted by "Reinhard Poetz (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (COCOON-1764) Component handling
Posted by "Daniel Fagerstrom (JIRA)" <ji...@apache.org>.
[ 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