11:54 a.m.
Generally, a deployment that can provide classes/resources ends up as a module identified
by its module identity. What I'm trying to address is a use case whereby
org.acme.bar depends on org.acme.foo
This is not to be confused with
org.acme.bar depends on org.acme.foo only when the foo was installed as a deployment
Modularity in WildFly works with direct named dependencies. The current implementation
however adds another dimension to the named dependency. Namely, some sort of extension to
the module identity that is associated with how the module got into the system.
In the Fuse use case the dependency above is defined as content of some repository (i.e.
we only know that bar depends on foo). For obvious reasons we cannot have two dimensional
dependency definitions in the repository.
It is fine that multiple module loaders are at play at runtime. It is very likely also
true that these module loaders are organised is some hirarchy or order. (i.e. they will
not compete to load a given module identifier). This effectively makes a flat namespace
for module identities, which leads to a reasonable constraint that there are no duplicates
in that namespace. (i.e. a module identity cannot shadow another module identity coming
later in the order of module loaders)
If the use of unique module aliases is no good, there is perhaps another way to express
the above dependency in a one dimensional way.
Would you have an idea what this could be?
cheers
--thomas
On May 24, 2013, at 4:30 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
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_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx