On 12/21/10 2:54 AM, Thomas Diesler wrote:
For this to work it'd be necessary for a module to define its
capabilities/requirements. At runtime, there should be a "gate keeper"
to the modules dependency API - the Resolver. Deployments would also
define their respective set of capabilities/requirements. The resolver
could reject a deployment if the runtime does not provide the required
set of capabilities. This could happen with very detailed error
response. Currently we have various DUPs that use the modules dependency
API. IMHO these DUPs cannot be expected to produce consistent wiring
graphs for the non-trivial setups that we expect in future. Instead a
single authority should be tasked to validate that a set of modules can
be installed in an existing setup. This must happen without modifying
the existing setup.
No matter where you move the dependency information, there is still
going to be some kind of human factor here.
To reiterate, we must resist the urge to do fancy things that make our
(and not our users') life easier, as it costs us performance. The only
way we are going to remain as fast as we are, is if we continue to push
ourselves.
That said, I think we can do all kinds of error checking during build,
which to me makes way more sense then any kind of runtime analysis (why
continually verify what is known to be good?).
--
Jason T. Greene
JBoss, a division of Red Hat