Reinhard Poetz skrev:
[EMAIL PROTECTED] wrote:
Author: danielf
Date: Sat Feb 4 05:26:06 2006
New Revision: 374865
URL: http://svn.apache.org/viewcvs?rev=374865&view=rev
Log:
Changed from dependency based component lookup to global component
registry (https://issues.apache.org/jira/browse/COCOON-1764).
Updated tests and samples to reflect that there is no need to declare
component dependencies in block.xml.
Hmm, without block dependencies deployment becomes more difficult. How
does the person who deploys the block know which other blocks are
required to satisfy all requirements? Also auto-wiring that uses the
default-value from block.xml doesn't work anymore.
You are certainly right about that the lack of dependency declaration
for dependencies on component blocks will complicate deployment. But
keeping component dependencies at the _block level_ would give us some
severe problems later. I'll try to explain.
First let us step back a little bit. The point with components is that
they are parts of your system that you (or the users) want to be able to
replace. So if it is not relevant to have several implementations for
the users to choose between (or add own ones) it shouldn't be a
component. So the key with components is that they should be replaceable.
Now, let us see what happen if you declare that your block depends on a
component block. Say that it depends on Cocoon core. Cocoon core
contains maybe 100 components
(http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core-sitemap.xconf,
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core.xconf),
now suddenly you have declared that the unit that can be replaced are
not a single component, but all these maybe 100 components together. Not
particularly flexible anymore. If you want to switch one of the
components you have to implement a new block that is a copy of the core
block but with one component changed.
We had this idea of interface block, but in this case it mean that we
have a interface that say that all these, rather unrelated, components
always should go together.
Making the dependency on the core block a contract will also create
problems for us when we want to split up core in more reasonable and
reusable blocks. Each time we do that, all Cocoon projects must change
their dependency descriptor to be able to update.
Now if we had started from scratch, block dependencies would probably
have worked. We could have designed blocks so that they contained
components that actually are supposed to be replaced together. But
needing to get to that point at once, with our legacy of 50+ blocks
would be a major pain.
--- o0o ---
So what should we do? IMO the right level of granularity for component
dependencies, is at the single component level. This means that each
component (and application) should be the responsibility for declaring
what components it depends on. Then we need tools for being able to
discover the different blocks that contain the particular component that
we depend on. This tool could then help setting up the wiring so that it
contain the right set of blocks.
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on getting
the dependencies through the service manager in the program code. But
OSGi declarative services support declarative component dependencies e.g.
My suggestion is that we just leave this question for the time being. In
practice many of the component dependencies overlap with the interface
dependencies, that will be solved by the Maven compile time dependencies
anyway. Also we have been without a solution for this since we started
with compile time blocks a couple of years ago, so even if a solution
would be nice, we don't need to panic.
Also this is a problem that is common for all service (or component
based) plugin architectures, OSGi e.g. so we don't need to solve it
ourselves. Quite the opposite would it be much better to solve it
together with Felix and Maven, so that we can have a shared infra
structure and don't need to maintain an own non-compatible set of
service lookup services.
Something else that I don't understand is how do we manage component
namespaces in blocks?
If you talking about map: in component declarations, it seem to just be
ignored.
If I use <map:generate type="file"
src="test.xml"/> it just works but what happens if the hint "file" is
used several times in different blocks? (I guess the first or the last
declaration wins.)
The last one will be registered in the global registry, you will still
use the local one in each block as the block sets up a local service
manager for its own components and use the global service manager as a
parent manager.
/Daniel
