So it turns out that the 2 second wait in the ServiceModuleLoader that
we removed was actually covering up another bug in the way module
dependencies are handled.
Basically the problem is that even though a module load service has a
dependency on all its dependent modules, the module can actually be
loaded prematurely if its contents are exported by another module.
e.g. we have A,B,C where A has a dependency on B, and B has a dependency
on C with export=true.
If B's ModuleSpecService comes up first, then module A can be loaded,
however there is no guarantee that C's ModuleSpecService will have
started yet. Unfortunately we can't automatically handle this situation
properly with some kind of transitive service dependency mechanism,
because circular dependencies are allowed and quite common between
modules, and and sort of pure service based approach runs into circular
dependencies quite quickly.
I have worked around this for EE deployments, basically by simply adding
a dependency on every ModuleSpecService in the deployment to each module
load service, not ideal, but short of adding back the 2 second delay I
can't really think of a better solution, and the 2 second delay caused
other problems anyway.
OSGI still seems to have problems however, as can be seen in the recent
spate of OSGI related intermittent failures, and I am not really sure
how best to solve them. Do you have any ideas? If not, do you want to
meet up on IRC and talk about it?
as7-master-testsuite-ip6 - Build # 5740 - Failure:
Check console output at to view the results.
1 tests failed.
Cannot deploy: complex.ear
jboss-as7-dev mailing list