Quoting Xavier Hanin <[EMAIL PROTECTED]>:
On Nov 20, 2007 2:04 AM, Jing Xue <[EMAIL PROTECTED]> wrote:
This could be interesting. I suppose since a resolver has access to the
current
resolution map, it could at least theoretically make a "stateful"
decision. One potential caveat though is that, IIUC, when two modules
aren't depending on one another, the order of them being resolved is
undefined.
It isn't really undefined, the order is always the same, and depends on the
order of the dependencies defined in your metadata.
True. On the other hand though, I suspect (by skimming through the
parsing and resolving code and I _could_ be very wrong) that this
behavior is like this only because of the way it's implemented. The
behavior itself is always deterministic, and a rather sane one at
that, but I don't recall seeing it documented anywhere, which is what
I meant by "undefined".
It's very similar to a
preorder tree traversal, except that we walk through a graph and that we try
to avoid visiting evicted nodes. But it's true that it isn't under control
of the resolver, it's under control of people writing metadata. So it may be
a problem for you, depending on how well you can control the way metadata is
written.
Resolving the problem without imposing some kind of order is pretty
challenging. Maybe this could be done with some modifications in the
ResolveEngine, to let a door open just before the end of the resolution
process, to let you resolve this dependency only when the rest of the graph
has been resolved. But the least I can says is that this is not an easy
solution.
You mean some sort of "post resolving" extension point which is
exposed by the resolve engine to handle any dependencies left
unresolved by the standard algorithm? That'd be cool. I wouldn't
mind working on it. It'd probably be way out of scope at the moment,
though. 8-)
Another solution I see if you are sure the module making the decision is the
direct client of your module, is to define a custom parser based on the
XmlModuleDescriptorParser we provide, but which "sort" the dependency
descriptors returned to make sure your module is always at the end. Then in
a custom resolver you can make the stateful decision based on the full graph
of dependencies available at this time. This is not the cleanest thing I've
ever imagined, but it may work :-)
I think for now we are going to take the easy route - which is to make
a code branch for spring 2.0 support. Seeing Spring 2.5 just got
released (only after two RCs, that was quick!) last night, and it's
supposed to be a drop-in replacement, we might luck out with a rather
short transition period.
Thanks for the advices. It was a rather interesting discussion even
from a theoretical standpoint. 8-)
Cheers.
--
Jing
Xavier
