[wildfly-dev] Module slots may be deprecated

[Sebastian Laskawiec]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160622/1e5aac7a/attachment.html