4:30 p.m.
On Fri, 24 May 2013, Thomas Diesler wrote:
Folks, currently we allow an arbitrary module alias to be defined
with a
deployment/subdeployment in jboss-deployment-structure.xml. The
ServiceModuleLoader will however only accept module identifiers that
have the 'deployment.' prefix.
This was done by mistake - specifying arbitrary module aliases to
deployments is not supported.
I believe the 'deployment.' prefix is an unnecessary
constraint for
deployed module aliases. Deployments should be able to define any alias.
This would allow for a deployment to get 'promoted' to a system module
without breaking clients. A module alias should be unique, if a
deployment defines an alias of an already existing module it should
fail. System modules cannot have dependencies on deployment modules.
This change, provides a fallback in the ServiceModuleLoader that allows
deployment modules to be loaded by their alias even if they don't have
the 'deployment.' prefix. Unless I'm mistaken it only applies to inter
deployment dependencies.
What do you think?
Right now deployments are known (in a public API sense) only by their
deployment name e.g. foo.jar/foo.war/foo.ear. The "deployment." stuff is
an implementation detail only - one which may even change over time. What
you're really proposing is that deployments have formal *module* names,
which would compete for namespace with the statically installed modules or
any other module loader with which deployments might interact now or in
the future (including module loaders responsible for filesystem JAR
loading and SE-style extension loading, in addition to (for example) a
possible present or future OSGi module loader).
I do not agree with this change because I think this views the problem of
deployment modules the wrong way around. Deployment module dependencies
are resolved during deployment as services, whereas static module
dependencies are fixed. Right now, the only supported way to
establish deployment dependencies is by JAR name and relative path.
Deployment order is guaranteed by way of deployment processors which set
up services to resolve in the proper order.
We could, potentially, extend this with (for example) a simple
requires/provides mechanism, but if so, this mechanism would definitely
NOT operate by way of module identifiers. The module identifier namespace
for deployments must remain strictly controlled by the deployment system
or else we start creating ways to break deployment in weird ways. Any
interdeployment wiring must be done via MSC dependencies, not by module
aliases.
--
- DML