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

[Thomas Diesler]

Hi David, I added a check that a module alias cannot shadow an already existing system module. Duplicate deployment aliases were prevented already by virtue of duplicate service names. Do you still think there is an issue with dropping the 'deployment.' prefix constraint on module aliases?

cheers
--thomas

On May 28, 2013, at 11:54 AM, Thomas Diesler <thomas.diesler at jboss.com> wrote:

> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130603/baefe125/attachment.html