Module slots may be deprecated

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

Module slots may be deprecated

David Lloyd-2
Java 9 modules do not have a concept of a slot, and are identified only
by name.  On the other hand, the module slot in JBoss Modules is
essentially an extension of the name, and is used mainly as a helper to
name parsing for things like the filesystem module loader to allow easy
multi-version or parallel installation support.  A few projects use
slots for other purposes.  In many module loaders, slots are not used at
all and are allowed to default to "main".

Among the changes coming to JBoss Modules for Java 9, my current plan
for this is to migrate towards the Java 9 way of doing things and
support only a general name field.  For compatibility purposes, the
ModuleIdentifier API will continue to function, until/unless it is clear
that all major users have migrated off of it.  It will work as a
frontend to plain String names - a ModuleIdentifier with name "name" and
slot "slot" will be translated behind the scenes as a module named
"name:slot".  A module with a slot of "main" will be translated as just
"name".  A simple character escaping scheme will be employed to ensure
that there is a lossless two-way mapping from plain names to
ModuleIdentifier-style names, in the event that there is a ':' in the
name part of the ModuleIdentifier, though in practice this may not come
up much.

The existing module loaders can continue to function more or less as
they are.  For filesystem modules using module.xml, the slot could still
be used by way of the compatibility syntax scheme above.  The filesystem
module loader will continue to use the same file name mapping scheme for
now, using the aforementioned compatibility scheme to achieve the same
effect that slots do now; we can look at ways to transition off of that
later if it proves necessary to do so.

The deployment module loader in WildFly can be transitioned to using
plain names easily, and this can probably be done at any time.  We can
keep WildFly management APIs which reference modules as they are for now
- if a slot is present, it could simply be appended to the given module
name after a dividing ":", otherwise the module name is used as-is.  The
slot attributes could be deprecated at any time.

Overall though I think the best way of approaching the change is that we
start thinking of "name:slot" as merely a ModuleLoader-specific name
syntax policy that some loaders use, and some do not.  I suspect that
some module loaders will actively benefit from not having to deal with
the annoying possibility that a slot will be present and will not be the
expected "main" value; having a simple unrestricted String name allows
each ModuleLoader to have complete control over their syntax policy,
which is something that JBoss Modules has been moving towards for some
time now.

Ultimately slots are a pretty limited tool and are already essentially a
facade over a plain name, with a very thin convenience class over the
top of it to implement a parsing policy.  While many people have taken
advantage of slots in many ways, it is my view that moving this
logic/policy into each module loader will afford more flexibility than
does simply dividing names into two fields.  The ModuleIdentifier class
could be preserved as a convenience, though I would not recommend its
use (hence deprecation), especially as it may map awkwardly into things
like Java 9 module-aware stack traces.  However this is something that
can be discussed before any decision is reached.

The estimated time frame for these changes relates to the time frame and
progress of Java 9, so it is not clear at the moment exactly when this
must happen, but it is certain that the changes will definitely not
occur before WildFly 12.  Hopefully this will give everyone enough time
to recover from the shock. :-)

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

Re: Module slots may be deprecated

Bob McWhirter
This is horrible! Horrible I say.

Actually, no, we’re cool.

Thanks for the heads-up.

-Bob

On Tue, Jun 21, 2016 at 4:39 PM, David M. Lloyd <[hidden email]> wrote:
Java 9 modules do not have a concept of a slot, and are identified only
by name.  On the other hand, the module slot in JBoss Modules is
essentially an extension of the name, and is used mainly as a helper to
name parsing for things like the filesystem module loader to allow easy
multi-version or parallel installation support.  A few projects use
slots for other purposes.  In many module loaders, slots are not used at
all and are allowed to default to "main".

Among the changes coming to JBoss Modules for Java 9, my current plan
for this is to migrate towards the Java 9 way of doing things and
support only a general name field.  For compatibility purposes, the
ModuleIdentifier API will continue to function, until/unless it is clear
that all major users have migrated off of it.  It will work as a
frontend to plain String names - a ModuleIdentifier with name "name" and
slot "slot" will be translated behind the scenes as a module named
"name:slot".  A module with a slot of "main" will be translated as just
"name".  A simple character escaping scheme will be employed to ensure
that there is a lossless two-way mapping from plain names to
ModuleIdentifier-style names, in the event that there is a ':' in the
name part of the ModuleIdentifier, though in practice this may not come
up much.

The existing module loaders can continue to function more or less as
they are.  For filesystem modules using module.xml, the slot could still
be used by way of the compatibility syntax scheme above.  The filesystem
module loader will continue to use the same file name mapping scheme for
now, using the aforementioned compatibility scheme to achieve the same
effect that slots do now; we can look at ways to transition off of that
later if it proves necessary to do so.

The deployment module loader in WildFly can be transitioned to using
plain names easily, and this can probably be done at any time.  We can
keep WildFly management APIs which reference modules as they are for now
- if a slot is present, it could simply be appended to the given module
name after a dividing ":", otherwise the module name is used as-is.  The
slot attributes could be deprecated at any time.

Overall though I think the best way of approaching the change is that we
start thinking of "name:slot" as merely a ModuleLoader-specific name
syntax policy that some loaders use, and some do not.  I suspect that
some module loaders will actively benefit from not having to deal with
the annoying possibility that a slot will be present and will not be the
expected "main" value; having a simple unrestricted String name allows
each ModuleLoader to have complete control over their syntax policy,
which is something that JBoss Modules has been moving towards for some
time now.

Ultimately slots are a pretty limited tool and are already essentially a
facade over a plain name, with a very thin convenience class over the
top of it to implement a parsing policy.  While many people have taken
advantage of slots in many ways, it is my view that moving this
logic/policy into each module loader will afford more flexibility than
does simply dividing names into two fields.  The ModuleIdentifier class
could be preserved as a convenience, though I would not recommend its
use (hence deprecation), especially as it may map awkwardly into things
like Java 9 module-aware stack traces.  However this is something that
can be discussed before any decision is reached.

The estimated time frame for these changes relates to the time frame and
progress of Java 9, so it is not clear at the moment exactly when this
must happen, but it is certain that the changes will definitely not
occur before WildFly 12.  Hopefully this will give everyone enough time
to recover from the shock. :-)

Discussion!
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Module slots may be deprecated

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

Re: 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


On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Module slots may be deprecated

Sanne Grinovero
I'm a bit sad from this, as the notion of "slot" was very useful, but
I understand that the alternatives will work the same. So +1 for your
proposal, if that helps with Jigsaw.. however beyond how things are
represented, I'd hope we will be able to still evolve the notion of
"slots" as a concept, for example to one day be able to validate that
it's illegal for a user to depend on both "org.hibernate:4.1" and
"org.hibernate:5.0", just to name one.

About the transition period and the idea of "escaping" the ":"
character in the name: maybe it would be better to avoid such escaping
so that we could already make the transition on some projects, without
enforcing the new naming scheme on all of them?

It might be useful to start publishing some modules with e.g.
name="org.hibernate.search-engine:6.0.0.Final" and yet be able to
depend on this via the couple { name="org.hibernate.search-engine",
slot="6.0.0.Final" } from another project:
we're having at this point several projects which depend on each other
in a complex matrix, with different release times and possibly
targeting different WildFly versions and different product builds.

Support for aliases will stay I hope? Those have been extremely useful too.

Thanks!
Sanne



On 22 June 2016 at 07:18, Sebastian Laskawiec <[hidden email]> wrote:

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

Re: Module slots may be deprecated

David Lloyd-2
I'll answer your questions inline.

On 06/22/2016 10:11 AM, Sanne Grinovero wrote:
> I'm a bit sad from this, as the notion of "slot" was very useful, but
> I understand that the alternatives will work the same. So +1 for your
> proposal, if that helps with Jigsaw.. however beyond how things are
> represented, I'd hope we will be able to still evolve the notion of
> "slots" as a concept, for example to one day be able to validate that
> it's illegal for a user to depend on both "org.hibernate:4.1" and
> "org.hibernate:5.0", just to name one.

Sounds like a potentially useful feature.  This could be implemented as
a ModuleLoader policy.

> About the transition period and the idea of "escaping" the ":"
> character in the name: maybe it would be better to avoid such escaping
> so that we could already make the transition on some projects, without
> enforcing the new naming scheme on all of them?

Sure, code can transition to using String names and avoid any kind of
special handling.  Also, I believe that at present the filesystem module
loader does not support : in names, so it won't have any issue with
escaping.  Or are you proposing something else?

> It might be useful to start publishing some modules with e.g.
> name="org.hibernate.search-engine:6.0.0.Final" and yet be able to
> depend on this via the couple { name="org.hibernate.search-engine",
> slot="6.0.0.Final" } from another project:
> we're having at this point several projects which depend on each other
> in a complex matrix, with different release times and possibly
> targeting different WildFly versions and different product builds.

Something of note is that I will also be adding version support.  The
version string will not have any core function (other than to display
the correct version in the module stack trace, a new feature of Java 9)
- in particular it won't be used as part of the module's identification
for loading modules - but ModuleLoaders can use it for whatever purpose
they wish (for example the ModuleLoader could generate the version based
on the module name) including policy enforcement decisions.

> Support for aliases will stay I hope? Those have been extremely useful too.

Yes, though there will be some implementation changes (independently of
this change) because alias unloading does not presently work properly.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev