In Infinispan we actually use both approaches (with and without slots).

We use slots when creating modules for WF/EAP [1][2]. The idea is to copy them directly into the modules directory and use in your deployment. Note that we want to be able to put multiple versions there (like ispn-8.2 and ispn-9.0 for example).

The default slot is used for WF Clustering and when we create our own HotRod server [3].

I think those changes look fine and everything should still work as it did before.

Thanks

Sebastian

[1] https://github.com/infinispan/infinispan/tree/master/as-modules/embedded

[2] https://github.com/infinispan/infinispan/tree/master/as-modules/client

[3] https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack

On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow <smarlow@redhat.com> wrote:

This might impact the second Infinispan module name that OGM will likely
use for remote Infinispan access, since the base module name was going
to be identical to the WildFly infinispan module, with the slot name
used to distinguish between the different Infinispan modules.

The WildFly JPA container currently supports a persistence unit hint
(jboss.as.jpa.providerModule=name) to specify a non-default persistence
provider. This is probably used by some applications. Recently, Sanne
also mentioned some use cases for Hibernate Search applications to
depend on jboss.as.jpa.providerModule as well. Applications that
currently include the slot with "jboss.as.jpa.providerModule", could
need changes when the slot support is removed.

Have you created a WFLY tracking issue yet for deprecating module slots?
I'm thinking that the JPA container should check if
"jboss.as.jpa.providerModule" specifies a slot and if yes, log a
deployment warning about the application referencing a slot that needs
change to not require the slot. We should also create a dependent jira
for the JPA container change to log the warning.

The JPA container also supports a similar "jboss.as.jpa.adapterModule"
persistence unit property but I don't think that is used much, if at
all. Applications that specify a slot in
"jboss.as.jpa.adapterModule=name", should also get a deployment warning
logged about deprecated slot usage.

The other related change, will be the convention that we use for legacy
Hibernate module names, which use the module slot as well.

From a compatibility point of view, of future WildFly versions, with
WildFly 10, when we pull the switch for removing module slot support
completely, I'm not really sure if that breaks application compatibility
or more that the user needs to move the system/user modules that use
slot, to a non-slot module. For example, if the application persistence
unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the
user will need to move their Hibernate 4.x jars into a different folder.

Another thing, I'm not sure if in that future WildFly version that
removes slots completely, if the JPA container, should translate the
"jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot,
with the colon separator removed, so
"jboss.as.jpa.providerModule=org.hibernate:4.1" becomes
""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a
deployment error until the user moves the Hibernate jars from
"org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1"
(in the user or system module folder).

Scott

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