java.lang.NoSuchFieldError: sc

[per-erik]

Description

While trying to convert our existing war to a wab, I run into a deployment issue. The wab contains a an ejb-file (along with some libraries) in the WEB-INF/lib folder. The wab also contains jax-rs resources.

When building the wab without the ejb-file, it gets deployed correctly and I can successfully call the jax-rs endpoints (except that most of them require the ejb-file to function but I've created an endpoint that has no dependencies).

When building the wab with the ejb-file included I get an exception during deployment (or really after deployment succeeds, while mojarra is scanning for jsf annotations). I've tried this on both Payara 5.194 and Payara 5.2020.2 with the same result.

We don't need or use JSF so I would not expect the scanning to happen to begin with.

I suspect this error is related to eclipse-ee4j/glassfish-fighterfish#29.

If there is anything I can do to prevent this scan from happening, that would be just as good as a fix of the issue.

Expected Outcome

No exception during deployment of a war file with OSGi metadata deployed with type "Other" checking the checkbox "OSGi Type" through the admin console, even if the war file contains ejb files in the WEB-INF/lib directory.

Current Outcome

[2020-07-07T13:52:23.841+0200] [Payara 5.2020] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=187 _ThreadName=pool-29-thread-1] [timeMillis: 1594122743841] [levelValue: 1000] [[
  ContainerBase.addChild: start: 
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! java.util.concurrent.ExecutionException: java.lang.NoSuchFieldError: sc
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5778)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:619)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:958)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:941)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:694)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1824)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1576)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:108)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:123)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:283)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:362)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.initialize(ApplicationLifecycle.java:621)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:652)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:643)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:161)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:96)
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:99)
	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:130)
	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:84)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:36)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:128)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:125)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! java.util.concurrent.ExecutionException: java.lang.NoSuchFieldError: sc
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:284)
	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5178)
	at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:681)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5756)
	... 25 more
Caused by: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! java.util.concurrent.ExecutionException: java.lang.NoSuchFieldError: sc
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:374)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:206)
	... 28 more
Caused by: javax.faces.FacesException: java.util.concurrent.ExecutionException: java.lang.NoSuchFieldError: sc
	at com.sun.faces.config.ConfigManager.getAnnotatedClasses(ConfigManager.java:229)
	at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:806)
	at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:342)
	at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:420)
	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:217)
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:358)
	... 29 more
Caused by: java.util.concurrent.ExecutionException: java.lang.NoSuchFieldError: sc
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at com.sun.faces.config.ConfigManager.getAnnotatedClasses(ConfigManager.java:227)
	... 34 more
Caused by: java.lang.NoSuchFieldError: sc
	at org.glassfish.osgiweb.OSGiFacesAnnotationScanner.getAnnotatedClasses(OSGiFacesAnnotationScanner.java:57)
	at com.sun.faces.config.manager.tasks.FindAnnotatedConfigClasses.call(FindAnnotatedConfigClasses.java:89)
	at com.sun.faces.config.manager.tasks.FindAnnotatedConfigClasses.call(FindAnnotatedConfigClasses.java:40)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at com.sun.faces.config.ConfigManager.findAnnotations(ConfigManager.java:418)
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:285)
	... 29 more
]]

Steps to reproduce (Only for bug reports)

1. Start the domain
2. Deploy a wab with a contained EJB file as an OSGi bundle.
3. Wait for mojarra to start scanning for JSF annotations.

Context (Optional)

I'm trying to build a wab so that we can use our existing non-javaee OSGi bundles from our web application.

Environment

• Payara version 5.194 and 5.2020.2 (community edition)
• JDK Version: AdoptOpenJDK 11 and RedHat's JDK 11
• Operating system: Windows

[svendiedrichsen]

There seems to be a classloading problem. The class com.sun.faces.spi.AnnotationProvider base class apears twice in two different jars. Once in jsf-impl-2.1.0-b11.jar and once in jakarta.faces-2.3.14.payara-p2.jar. And they differ in that the first has a protected ServletContext member sc and in the latter it is called servletContext.

a) this double existance needs to be resolved
b) class members make for a bad interface definition -> maybe extend the interface with a getServletContext() method if this doesn't break the api

[svendiedrichsen]

@per-erik Did you remove the web.xml file or is it somehow corrupted? It only searches for the web.xml file under /WEB-INF/web.xml.

You should be able to find some warning in the log before the above mentioned exception. There is some weird code in the faces ConfigurationScanner which tries to find a FacesServlet configured in the web.xml. And if it runs into an exception it assumes that it exists and thus triggers the FacesAnnotation scanning afterwards:

                        } catch (SAXException | IOException | ParserConfigurationException var37) {
                            this.warnProcessingError(var37, context);
                            this.facesServletPresent = true;
                        } finally {

[per-erik]

Thanks for the quick reply @svendiedrichsen. I've looked into possible problems with the web.xml but found none. Originally I used the web.xml from one of the fighterfish samples (fighterfish-sample-uas-simplejaxrs) but IntelliJ gave me warnings about that one even after I fixed some obvious xml-errors in it (like line-feeds in the xmlns:xsi attribute value) so I ended up with the following web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
        version="3.0"
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
    <servlet>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

I also cannot see any warnings prior to the scanning. However, the stacktrace I sent earlier isn't the first one in the log. Instead of me guessing which parts of the log that could be interesting I'm attaching the entire log file, rotated just before deploying (so you don't get all the noise from server startup and previous attempts).

The interesting parts probably starts at row 88 or so when it says that the total number of classes with faces annotations is 0 and then starts Soteria and later Mojarra. Then it says that the Faces Config uris is an empty list. Right after that is the first exception where it seems to have started a JSF scan anyway but fails since the field sc does not exist.

Note that I'm somewhat new to jax-rs (and servlets overall) so my web.xml may very well be semantically wrong, but that shouldn't give SAXExceptions, IOExceptions or a ParserConfigurationException (assuming these are the "standard" exception classes).

server.log

[svendiedrichsen]

The Problem with the missing sc member is due to the fact I have commented in my first comment. The interesting thing for me was that the Faces scanner goes off at all. It shouldn't because it isn't a Faces app.

[per-erik]

Yes, I realized that after I wrote my last comment. The missing sc member is, as you said, due to being wired to packages from jakarta-faces where the AnnotationProvider's field is called servletContext and not sc.

After some debugging I think the reason the OSGiFacesAnnotationScanner is called at all is because a JSF config is created by com.sun.faces.config.manager.ConfigManager#initialize with the call to com.sun.faces.config.manager.Documents#getProgrammaticDocuments. I have not been able to deduce why the ConfigManager gets called to begin with.

I understand that my problem is somewhat unrelated to the reported bug so I'll stop commenting here. Is there anywhere I can ask questions about the scan, cause I'm not sure that it's a bug so I don't want to file a new issue for my root problem (the scanning).

[svendiedrichsen]

There is a Payara group at google which you could use https://groups.google.com/g/payara-forum?pli=1
to post any question first. The people from payara do read those questions too.

[fturizo]

Seems that there is nothing to report on this issue, so I'll proceed to close it.