[wildfly-dev] Cannot load module alias defined for root deployment

[David M. Lloyd]

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