Payara 5.2022.5 + JDK 17 Does Not Start on Windows 11

During unzip, Windows Defender identifies vulnerabilities. When ignored, trying to start fails with the following. Payara 5.2022.4 on the other hand starts fine. Have other folks seen this?

================================================================

Launching Payara Server on Felix platform
Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@4c4bfed6 in service registry.
Completed shutdown of GlassFish runtime
We are in non-embedded mode, so fish.payara.server.internal.core.glassfish [113] has nothing to do.
Jan 01, 2023 12:25:06 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFO: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Exception in thread “main” java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:121)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
Caused by: A MultiException has 2 exceptions. They are:

  1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [fish.payara.server.internal.batch.glassfish-batch-connector [102]], State = [NEW]

  2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
    implementation=org.glassfish.batch.spi.impl.BatchRuntimeConfigurationInjector
    name=batch-runtime-configuration
    contracts={org.glassfish.batch.spi.impl.BatchRuntimeConfigurationInjector,org.jvnet.hk2.config.ConfigInjector}
    scope=javax.inject.Singleton
    qualifiers={org.jvnet.hk2.config.InjectionTarget}
    descriptorType=CLASS
    descriptorVisibility=NORMAL
    metadata=@table-suffix={optional,default:,datatype:java.lang.String,leaf},@data-source-lookup-name={optional,datatype:java.lang.String,leaf},@table-prefix={optional,default:,datatype:java.lang.String,leaf},@schema-name={optional,default:APP,datatype:java.lang.String,leaf},@executor-service-lookup-name={optional,default:concurrent/__defaultManagedExecutorService,datatype:java.lang.String,leaf},target={org.glassfish.batch.spi.impl.BatchRuntimeConfiguration},Bundle-SymbolicName={fish.payara.server.internal.batch.glassfish-batch-connector},Bundle-Version={5.2022.5}
    rank=0
    loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [fish.payara.server.internal.batch.glassfish-batch-connector [102]], State = [NEW],10885570)
    proxiable=null
    proxyForSameScope=null
    analysisName=null
    id=198
    locatorId=0
    identityHashCode=1687087217
    reified=false)

     at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2247)
     at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:438)
     at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:457)
     at org.jvnet.hk2.config.DomDocument$InjectionTargetFilter.matches(DomDocument.java:184)
     at org.jvnet.hk2.internal.ServiceLocatorImpl.getDescriptors(ServiceLocatorImpl.java:347)
     at org.jvnet.hk2.internal.ServiceLocatorImpl.getDescriptors(ServiceLocatorImpl.java:389)
     at org.jvnet.hk2.internal.ServiceLocatorImpl.getBestDescriptor(ServiceLocatorImpl.java:397)
     at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:135)
     at org.jvnet.hk2.config.ConfigModel.parseValue(ConfigModel.java:959)
     at org.jvnet.hk2.config.ConfigModel.<init>(ConfigModel.java:875)
     at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:114)
     at org.jvnet.hk2.config.DomDocument.getModelByElementName(DomDocument.java:162)
     at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:166)
     at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:102)
     at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:96)
     at org.glassfish.config.support.DomainXml.parseDomainXml(DomainXml.java:271)
     at org.glassfish.config.support.DomainXml.run(DomainXml.java:121)
     at org.jvnet.hk2.config.ConfigurationPopulator.populateConfig(ConfigurationPopulator.java:58)
     at org.glassfish.hk2.bootstrap.HK2Populator.populateConfig(HK2Populator.java:83)
     at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:190)
     at com.sun.enterprise.module.bootstrap.Main.createServiceLocator(Main.java:249)
     at org.jvnet.hk2.osgiadapter.HK2Main.createServiceLocator(HK2Main.java:95)
     at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:95)
     at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
     at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:91)
     at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:137)
     ... 6 more
    

Caused by: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [fish.payara.server.internal.batch.glassfish-batch-connector [102]], State = [NEW]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:193)
at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:54)
at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2239)
… 31 more
Caused by: org.osgi.framework.BundleException: Unable to resolve fish.payara.server.internal.batch.glassfish-batch-connector [102](R 102.0): missing requirement [fish.payara.server.internal.batch.glassfish-batch-connector [102](R 102.0)] osgi.wiring.package; (osgi.wiring.package=com.ibm.jbatch.spi) [caused by: Unable to resolve fish.payara.server.internal.batch.payara-jbatch [316](R 316.0): missing requirement [fish.payara.server.internal.batch.payara-jbatch [316](R 316.0)] osgi.wiring.package; (osgi.wiring.package=org.glassfish.weld) [caused by: Unable to resolve fish.payara.server.internal.web.weld-integration [381](R 381.0): missing requirement [fish.payara.server.internal.web.weld-integration [381](R 381.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.web.deployment.descriptor)(version>=5.2022.0)(!(version>=6.0.0))) [caused by: Unable to resolve fish.payara.server.internal.web.glue [369](R 369.0): missing requirement [fish.payara.server.internal.web.glue [369](R 369.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.catalina)(version>=5.2022.0)(!(version>=6.0.0))) [caused by: Unable to resolve fish.payara.server.internal.web.core [367](R 367.0): missing requirement [fish.payara.server.internal.web.core [367](R 367.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.web.loader)(version>=5.2022.0)(!(version>=6.0.0)))]]]] Unresolved requirements: [[fish.payara.server.internal.batch.glassfish-batch-connector [102](R 102.0)] osgi.wiring.package; (osgi.wiring.package=com.ibm.jbatch.spi)]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.startBundle(OSGiModuleImpl.java:227)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:185)
… 33 more

Hi @reza_rahman,

I tried replicating but in my case, it is working as expected.

Seems that I have the same problem.
My Java:
openjdk version “11.0.17” 2022-10-18 LTS
OpenJDK Runtime Environment Zulu11.60+19-CA (build 11.0.17+8-LTS)
OpenJDK 64-Bit Server VM Zulu11.60+19-CA (build 11.0.17+8-LTS, mixed mode)

I get the same crash when trying to start domain1 immediately after expanding Payara 5.2022.5 Community Edition from zip-file.
With Payara 5.2022.4 Community Edition domain1 starts ok immediately after expanding from zip-file.

I have tried this in Windows 10 and Windows 7 with same results.

Update:

There is an issue BugReport: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [fish.payara.server.internal.batch.glassfish-batch-connector [102]], State = [NEW]Bug Report: · Issue #5953 · payara/Payara · GitHub that looks same.

It seems that Windows Defender is the root cause. Module war-util.jar was quarantined and restoring it allowed the domain start normally.

Is it useful to record a video with the issue? I suspect an updated Windows Defender is the key.

I wonder is this false alarm (updated Windows Defender/Microsoft Security Essentials virus definitions will fix the false alarm) or is there really something wrong with Payara installation zip-file (in this case the installation package must be fixed). For now, I just restore the quarantined file.

It’s possible it’s a false report. If so, Payara will need to report it as such with justification to the Windows Defender team. Reporting is easy and the Defender team is generally responsive.