<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>The requirement comes from the <a href="https://github.com/tdiesler/wildfly-camel/wiki">WildFly Camel</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>cheers</div><div>--thomas<br><div><br><div><div>On May 24, 2013, at 3:31 PM, Jaikiran Pai <<a href="mailto:jpai@redhat.com">jpai@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>On Friday 24 May 2013 06:50 PM,
Thomas Diesler wrote:</tt><tt><br>
</tt></div>
<blockquote cite="mid:12FB7BE7-1F5F-4BC1-AA6B-2E1BB8DDC5FE@jboss.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><tt><br>
</tt></div>
<div><tt>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.</tt><tt><br>
</tt></div>
<div><tt><br>
</tt></div>
<tt><br>
</tt></blockquote>
<tt>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?</tt><tt><br>
</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt><br>
</tt><tt>-Jaikiran</tt><tt><br>
</tt>
</div>
_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/wildfly-dev<br></blockquote></div><br><div>
<div><pre class="moz-signature" cols="72">xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>