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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Thomas Diesler
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. 

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?

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




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jaikiran Pai
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Thomas Diesler
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd-2
In reply to this post by Thomas Diesler
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Thomas Diesler
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev