<div dir="ltr">In Infinispan we actually use both approaches (with and without slots).<div><br></div><div>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 <i>ispn-8.2</i> and <i>ispn-9.0</i> for example). </div><div><br></div><div>The default slot is used for WF Clustering and when we create our own HotRod server [3].</div><div><br></div><div>I think those changes look fine and everything should still work as it did before. </div><div><br></div><div>Thanks</div><div>Sebastian</div><div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/tree/master/as-modules/embedded">https://github.com/infinispan/infinispan/tree/master/as-modules/embedded</a></div><div>[2] <a href="https://github.com/infinispan/infinispan/tree/master/as-modules/client">https://github.com/infinispan/infinispan/tree/master/as-modules/client</a></div><div>[3] <a href="https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack">https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow <span dir="ltr"><<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This might impact the second Infinispan module name that OGM will likely<br>
use for remote Infinispan access, since the base module name was going<br>
to be identical to the WildFly infinispan module, with the slot name<br>
used to distinguish between the different Infinispan modules.<br>
<br>
The WildFly JPA container currently supports a persistence unit hint<br>
(jboss.as.jpa.providerModule=name) to specify a non-default persistence<br>
provider. This is probably used by some applications. Recently, Sanne<br>
also mentioned some use cases for Hibernate Search applications to<br>
depend on jboss.as.jpa.providerModule as well. Applications that<br>
currently include the slot with "jboss.as.jpa.providerModule", could<br>
need changes when the slot support is removed.<br>
<br>
Have you created a WFLY tracking issue yet for deprecating module slots?<br>
I'm thinking that the JPA container should check if<br>
"jboss.as.jpa.providerModule" specifies a slot and if yes, log a<br>
deployment warning about the application referencing a slot that needs<br>
change to not require the slot. We should also create a dependent jira<br>
for the JPA container change to log the warning.<br>
<br>
The JPA container also supports a similar "jboss.as.jpa.adapterModule"<br>
persistence unit property but I don't think that is used much, if at<br>
all. Applications that specify a slot in<br>
"jboss.as.jpa.adapterModule=name", should also get a deployment warning<br>
logged about deprecated slot usage.<br>
<br>
The other related change, will be the convention that we use for legacy<br>
Hibernate module names, which use the module slot as well.<br>
<br>
From a compatibility point of view, of future WildFly versions, with<br>
WildFly 10, when we pull the switch for removing module slot support<br>
completely, I'm not really sure if that breaks application compatibility<br>
or more that the user needs to move the system/user modules that use<br>
slot, to a non-slot module. For example, if the application persistence<br>
unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the<br>
user will need to move their Hibernate 4.x jars into a different folder.<br>
<br>
Another thing, I'm not sure if in that future WildFly version that<br>
removes slots completely, if the JPA container, should translate the<br>
"jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot,<br>
with the colon separator removed, so<br>
"jboss.as.jpa.providerModule=org.hibernate:4.1" becomes<br>
""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a<br>
deployment error until the user moves the Hibernate jars from<br>
"org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1"<br>
(in the user or system module folder).<br>
<span class="HOEnZb"><font color="#888888"><br>
Scott<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>