I'm ok with you about circular dependencies. They are bad practice and
must be avoided. But if I could save my time and concentrate on bugs
which are important for my work, I would prefer. Then, I could come back
later on this new architecture constraints.
I'm just realizing that moving from C21 to C22 will take more time, even
if it's for a better world ;-)
JC
Grzegorz Kossakowski a écrit :
Jean-Christophe Kermagoret pisze:
Hi,
I'm not talking about inheritance, only usage relationships.
I pointed you to that discussion to give you how good design can
eliminate a need for circular dependencies.
For example, I have 2 services :
* locator, which locates resources
* common, which provides common stylesheets
Each service is using the other one, not in a fallback mechanism. I'm
surprised this behavior is not allowed.
Could you show some flow between locator and common so I can get
better of idea of each block's role?
With C21, I could use mount table to describe where my services were
located. How may I design this in C22 ? Is servlet: the right choice
in my case ?
To give you exact advice I need more details about your use case.
As general note, block is not only about sitemap in C2.2, it's also a
reusable unit packaged with Maven.
With regard to circular dependencies:
a) Maven does not allow artifacts in circular dependencies (and you
always get the answer that your design is probably flawed when you
need them)
b) Spring does not allow beans to depend on themselves in circle (with
exceptions, though). You get more or less the same answer as from
Maven folks if you question this behaviour.
Don't you think that common wisdom of these communities can't be wrong?
Even though it was possible with Cocoon 2.1, in Cocoon 2.2 we are
trying to live in better harmony with rest of the world. That's one of
consequences.
--
Jean-Christophe Kermagoret,
OpenBlueLab Technological Leader
http://www.openbluelab.org
http://forge.openbluelab.org
http://wiki.openbluelab.org
http://demo.openbluelab.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
