Peter Donald wrote:
I'll look at it again when I get some more energy. I just spent way too many hours learning theWhat would you think about moving the ComponentProxyGenerator over asI am not sure I like it. The main reason is that there is no consensus on how proxys are generated. ie In Phoenix/Merlin the lookup key will not necessarily match the interface name and thus the proxy would never work in this situation. In ECM/Fortress it works by virtue of
well. Doing so would
remove the need for the Container package by the Component package (?)
Seems to make
as much sense as moving the WrapperServiceManager class.
key == role + decoration
I would feel more comfortable if the code was moved either into both ECM and fortress (It would reduce coupling and thus IMHO the duplication is not bad). However long term I would prefer that it get moved into ECM and fortress implement a proper Proxy management (which included proxying objects prior to them being made available via the SM or CM).
quirks of the objects returned by java.lang.reflect.Proxy. It turns out that their equals method
always returns false. So you could have a proxy p and execute p.equals( p ) and get false.
Several places in the code were using collections classes which do not test for object equality
so this was leading to all kinds of problems trying to decommission components which did not
implement the Component interface.
Anyway, it is all fixed now.
The ECM now supports the use of components which do not implement Component. This
"feature" had been in there for a while, but it did not appear to work correctly in several cases.
It ran into problems when a component implemented Serviceable but not Component, for
example.
Anyway, if some more people could pound on it that would be great.
Cheers,
Leif
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
