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.
7)
This section is a sort of "RT" :-)
Are the loops evil after all?
They very well can be. In this case, it seems to be benign. The closest analogy I can give is one of "tumors". Not all tumors are cancerous, but they they _might_ be. A component that forces the container into a real cyclic dependency loop will never be able to be initialized because it will never get out of the initialization stage. Component A will require Component B wich requires Component C which requires Component A will continue that initialization cycle until it is forcibly broken.
When the Component "A"s are really Component Acapture and Component Ascan then those are not really cyclic. THey are two different components.
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)
If they are looked up at that time then the problem still exists--and that seems to be a common practice.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
