The issue with potential duplicate aliases needs to get fixed anyway IMHO. If there is a check for an existing alias in the deployment namespace it could also be checked against the system namespace. I believe it'd be sufficient to try a module load on the ServiceModuleLoader - this would include a check on the system module loader.

The requirement comes from the WildFly Camel integration. Users that run Camel on Wildfly need to be able to provision modules (e.g. camel components) on demand. Additional user deployments have dependencies on these components. From the perspective of a user deployment it should make no difference whether the component is part of the system setup or has been deployed as an on-demand feature (i.e. dependency org.apache.camel.foo) should always work.

The general issue is that additionally to the named dependency on a specific module, we also introduce a dependency on how the module got into the system (i.e. deployment. prefix or not). This is really the unecessary  complexity IMHO.

cheers
--thomas

On May 24, 2013, at 3:31 PM, Jaikiran Pai <jpai@redhat.com> wrote:

On Friday 24 May 2013 06:50 PM, Thomas Diesler wrote:

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.


That looks like a (unnecessary) complexity. Assume, there's a foo.bar static module and then some deployment configures a module named foo.bar within it's jboss-deployment-structure.xml. I haven't looked at JBoss Modules implementation and how it interacts with the module loaders, but how would it know that foo.bar "already exists" as a static module?

By the way, why do we need this? I read up the JIRA and the comments in the PR but I am not sure what the real requirement is.

-Jaikiran
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

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