Closed MarcinVaadin closed 1 year ago
Payara issue: https://github.com/payara/Payara/issues/6127
How about changing the enum to something like this to remove the need of the kinda fancy stuff ;)
public enum SortDirection {
/**
* Ascending (e.g. A-Z, 1..9) sort order
*/
ASCENDING(Constants.ASCENDING_OPPOSITE),
/**
* Descending (e.g. Z-A, 9..1) sort order
*/
DESCENDING(Constants.DESCENDING_OPPOSITE);
private final SortDirection opposite;
SortDirection(SortDirection opposite) {
this.opposite = opposite;
}
/**
* Get the sort direction that is the direct opposite to this one.
*
* @return a sort direction value
*/
public SortDirection getOpposite() {
return opposite;
}
private static class Constants {
public static final SortDirection ASCENDING_OPPOSITE = DESCENDING;
public static final SortDirection DESCENDING_OPPOSITE = ASCENDING;
}
}
Same issue for com/vaadin/flow/component/grid/Grid$SelectionMode.class
.
Also
Exception while visiting com/vaadin/flow/component/internal/ComponentTracker$Location.class of size 2124
java.lang.UnsupportedOperationException: Record requires ASM8
at org.objectweb.asm.ClassVisitor.visitRecordComponent(ClassVisitor.java:305)
at org.objectweb.asm.ClassReader.readRecordComponent(ClassReader.java:953)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:731)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:424)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:336)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:164)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:130)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:321)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:44)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:280)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:269)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Is there anything for us to do here or should we close this issue and wait for Payara to fix their deps?
I suggest first to try change the Flow codes for SortDirection, ComponentTracker$Location and Grid$SelectionMode and see if there Payara would start then.
Example to reproduce https://github.com/vaadin/skeleton-starter-flow-cdi/tree/v24-payara :
mvn clean package payara-micro:start
Tested the above starter with patched Flow https://github.com/vaadin/flow/tree/flow-payara and Flow Grid https://github.com/vaadin/flow-components/tree/grid-payara I got basically only one error:
[2023-01-24T19:25:42.714+0200] [] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1674581142714] [levelValue: 1000] Exception while visiting sun.security.util.KnownOIDs
and a blank page:
No errors in the browser console or network tab. Will set a verbose logging level for the server and see.
The problem seems to be that MainView
is not considered a CDI bean, and thus its @PostConstructor
is not invoked, so child components are not added to the view
The same happens with wildfly 27 (alpha), so the problem is with Jakarta EE 10 and CDI 4, that changed the default bean discovery mode to annotated
, as mentioned in vaadin/cdi#411
Just tested against latest Flow and grid modules and the ASM issues seems to be resolved.
For the blank page issue I will create a PR on skeleton-starter-flow-cdi
repository to add the @CdiComponent
to MainView
, so it will be detected as a CDI bean and lifecycle hooks will be correctly invoked
Description of the bug
From StackOverflow:
Expected behavior
Should work
Minimal reproducible example
we should add payara-micro example to one of skeleton starter modules
Versions