[wildfly-dev] Module slots may be deprecated

[Scott Marlow]

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