Hello Leif!
LM> The problem that I am now running into is because all of components
LM> implement the TJMFDataSourceProvider role and the processor
LM> components also depend on other TJMFDataSourceProvider implementations,
LM> fortress will throw a CyclicDependencyException because the cyclic checks
LM> are based on role rather than the actual component instances.
LM> I can't think of any way that Fortress could handle this any better because
LM> the actual instance is only known at run time from within the component as
LM> its configure method is running.
Honestly me neither.
1)
In fact the issue has shown up before (that time with Merlin),
some guy was also building a system where components were
to chain heavily, something a bit cocoon like, I do not recall
precisely. Under Merlin it was even worse, as it does enforce
the "you can get only what you have been allowed to get"
restriction.
Don't remember what recommendations did Steve finally give. Steve?
2)
The same trouble used to exist in the excalibur-store package.
It even did failed to compile Fortress meta data
because a component was declaring a dependency
on its own role. Would be interesting to see how this has
been resolved.
3)
The issue may be partially resolved by allowed a component to
declare a dependency on its own role. (Probably this has already
been done and that's how excalibur-store compiles fortress
meta-data, but then why are you having troubles?)
In fact it is quite reasonable to allow a component to look up
its own role and not consider it a cyclic dependency. If I want
to get myself via a lookup() why not allow me to do this?
But this resolves only the trivial loop: a component depending
on its own role. A "loop" consisting of two roles will not
be resolved with this.
4)
Initially Berin was saying that it will be possible in the future
to consider allowing dependency declarations of the form
"my.cool.Processor/hintA"
but this rises the following reservations:
4.1)
Since Fortress has no assembly now this is problematic: we will have
to put this info "...../hintA" into the source file, that is specify
at compile time. On the other hand the real hints (aka id-s) are
specified as the user writes .xconf. And id clashes for instance
may make this mechanism unworkable.
4.2)
Even for containers that have assembly (and with fortress if it gains
one in the future) this moves the name of the processor we chain with
from the component configuration where it naturally belongs and is
easy to write and understand to the section that describes dependencies.
(I hope my poor knowledge of terminology has not stopped me from
being understandable here :)
5)
I believe yet none of the containers supports the most dynamic case
when the id of the component we need is not known at configure time
at all. (E.g. comes some _very_ weird way from the configuration).
6)
If users start using this "hack" - not declaring a dependency but
lookup()-ing the component anyway than future introduction of the
"you can get only what you have been allowed to get"
restriction to Fortress will become a compatibility breakage.
*deep sigh*
7)
This section is a sort of "RT" :-)
Are the loops evil after all?
Can there be a legitimate application where two components need
to lookup() each other?
Why not?
The real trouble will happen if the components
invoke each other during the "warmup" peirod.
("warmup" = contextualize, configure, service, initialize, start)
But if the components do not make any real calls on each other
until after "warmup", then its all ok!
Oh, yes, they also must make no calls on each other in the
"cooldown" ( stop, dispose ) period and they must be decomissioned
together..
8) Compare this all to the mail by Niclas Hedhman <[EMAIL PROTECTED]>
with subject "[Phoenix] Design issue about wiring" in this list.
It's about just the same in Phoenix. The issue is common!
[EMAIL PROTECTED] ;-)
answer is interesting to read
I'm afraid I do not understand what his solution 2) means, it reads as
PRF> 2. Use a listener to collect all the blocks that implement
PRF> the Source interface and then register them with the listeners
PRF> in applicationStarted() method.
I guess it is something Phoenix specific.
Hmm.. is it really about putting the code not into a component
but into something that sort of "plugs inside the container"
(the listener and the applicationStarted() method)
and has less access restrictions then a component?
This looks to me like inventing another sort of components
that have less restrictions since the regular components have
too many. Hey, aren't we overcomplicating our design?
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
