On Mon, Apr 24, 2023 at 3:39 PM James Perkins <jperkins@redhat.com> wrote:

This is a late reply to this email and we've shipped WildFly 28 with these changes. I feel we should consider reverting https://issues.redhat.com/browse/WFCORE-6250 removing the org.jboss.vfs module. Spring deployments require the VFS to be on the class path. They use this if the vfs protocol is used when traversing resources. Because our resources use this protocol, Spring makes decisions, for better or worse, about using VFS. Having the module not be on the deployments classpath is causing CNFE's to be thrown.

As a workaround a user could add a module dependency to org.jboss.vfs. However, this is a private module and a warning will be logged.

Another possible workaround would be for the jaxrs subsystem to add the module dependency to deployments since it configures resteasy-spring for deployments. However, if the subsystem is removed or is ignored by a deployment processor, the above issues still exist. I filed https://issues.redhat.com/browse/WFLY-17921 as that seemed like an okay solution. I do feel like at this point it's not quite enough though and we still run the risk of breaking deployments.

I feel in the end it's best to just add the org.jboss.vfs module back to deployments.

I agree. Earlier I said regarding this, "I'm hoping/praying that the only reason we exposed it to deployments in the first place was for our own internally classloading needs, not because user apps wanted access." TBH I should have known better. :) In any case we now know it breaks working applications so we should revert it.

Finding better solutions is fine, but I think we should start with reverting and if we come up with better solutions we can implement those then. Things like having the dependency added by the jaxrs subsystem (or by some other one even more likely to be in the config if Spring is used) aren't clearly better, so they need some thinking. I say not clearly better because doing that is kind of hacky and also because a sufficiently broad fix of that nature is likely not going to differ much in practice from adding it to all deployments.

While I agree it would be nice to not have this module as dependency to deployments, it seems to be currently needed.

On Mon, Mar 20, 2023 at 8:57 AM Richard Opalka <ropalka@redhat.com> wrote:

   At the time when first modular Java was released in September 2017 [0]
JBoss Modules team have already been working on proper integration with it [2].
That effort was finished 7 months later after Java 9 initial release and
JBoss Modules version supporting Java's JPMS modules was integrated into
WildFly in April 2018.

During the JBoss Modules 1.8.0.Final merge into WildFly some legacy and
WildFly specific modules have been deprecated, see [2] and [3]. These are:

 * ibm.jdk (aggregation module for IBM JDK8 internals)
 * javax.api (aggregation module for some Java's official APIs)
 * javax.xml.stream.api (streaming api)
 * javax.sql.api (sql api)
 * sun.jdk (aggregation module for SUN JDK internals)

   We created and defined these modules over time as WildFly was developed and before
Java got modularized via [5]. But with introduction of modular Java everything changed
and there is no more reason to use these legacy modules that we came up in the past.
It is preferred and recomended to use official Java JPMS modules instead.

   All five obsolete modules were deprecated in the past but second important step
of removing references on them wasn't completed yet and so they are still being used
in both WildFly and WildFly Core. Now before EAP8 goes final is the right time
to clean it up and complete the migration to standard Java's JPMS modules and ideally
get rid of these five deprecated modules. Another option is to keep them (although
unreferenced) in WildFly & EAP8 for backwards compability.

   There were identified two areas of above deprecated modules usages:
 a) module.xml files in WildFly Core and WildFly
 b) server runtime code

   To migrate to Java JPMS modules it is important to know which JPMS module(s) should be
used/referenced instead. Following is the mapping of legacy WildFly modules to Java JPMS modules:

 1) ibm.jdk deprecated module cannot be migrated to standard Java JPMS module. This module was introduced
    because we needed some of IBM JDK8 internals to be available in WildFly in the past.
    When WildFly Core and WildFly code base moved to modular JDKs (JDK11  and above) this legacy module
    is not needed anymore. It is because recent IBM JDK 11 and above are based on OpenJDK and its JPMS modules architecture.
    References to that module can be eliminated completely without any further migration.

 2) javax.api deprecated module will be replaced with one or some of the following JPMS modules it aggregates:
    - java.se
    - jdk.xml.dom
    where java.se is also Java's JPMS aggregation module and it can be further dereferenced to smaller JPMS modules that are only needed

 3) javax.xml.stream.api will be replaced with java.xml JPMS module

 4) javax.sql.api deprecated module will be replaced with one or some of the following JPMS modules it aggregates:
    - java.sql
    - java.sql.rowset
    - java.transaction.xa

 5) sun.jdk deprecated module will be replaced with one or some of the following JPMS modules it emulates:
    - modules whose name starts with jdk. prefix (note these are specific to the JDK and will not necessarily be available in all Java implementations)

   The last remaining bit we would like to clarify and standardize with this cleanup effort
is server runtime code referencing these legacy WildFly modules. It was identified that WildFly server propagates:
 * javax.api
 * ibm.jdk
 * sun.jdk
 * org.jboss.vfs
modules to all deployments by default.

   In order to standardize WildFly and EAP8 deployments we propose the following changes:
 * only java.se JPMS module will be propagated to all deployments by default - was addressed with [6]
 * deprecated ibm.jdk will not be propagated anymore to all deployments by default - will be addressed with [7]
 * deprecated sun.jdk will not be propagated anymore to all deployments by default - will be addressed with [8]
 * org.jboss.vfs will not be propagated to all deployments - was addressed with [9]
This proposal of course introduces a potential (but fixable) backward incompatibility issue between EAP7 and EAP8 deployments.
Deployments that were relying on sun.jdk module or org.jboss.vfs module to be available in their deployments by default will need to be fixed
to reference org.jboss.vfs module or jdk. prefixed JPMS modules explicitly - for example see [10].

Best regards,
JBoss Modules Team

[0] https://en.wikipedia.org/wiki/Java_version_history - Java release dates
[1] https://issues.redhat.com/browse/MODULES-254 - Support for dependency on Jigsaw modules from static modules
[2] https://issues.redhat.com/browse/WFCORE-3705 - Allow dependencies on JDK modules
[3] https://issues.redhat.com/browse/WFCORE-3684 - Upgrade JBoss Modules to 1.8.0.Final
[4] https://issues.redhat.com/browse/WFCORE-6248 - Only Java SE aggregation module should be visible to all deployments by default
[5] https://openjdk.org/jeps/200 - JEP 200: The Modular JDK
[6] https://issues.redhat.com/browse/WFCORE-6237 - Eliminate usage of deprecated javax.api module
[7] https://issues.redhat.com/browse/WFCORE-6245 - Eliminate usage of deprecated ibm.jdk module
[8] https://issues.redhat.com/browse/WFCORE-6249 - Eliminate usage of deprecated sun.jdk module
[9] https://issues.redhat.com/browse/WFCORE-6250 - Don't include org.jboss.vfs module to all deployments by default
[10] https://issues.redhat.com/browse/WFLY-17666 - Deployments using RMI Java Naming provider must define explicit dependency on jdk.naming.rmi JPMS module

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

James R. Perkins

JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His