Feature #6692
move FWD to Java 17
100%
Related issues
History
#1 Updated by Greg Shah almost 2 years ago
- Related to Support #5567: move FWD to Java 11 added
#2 Updated by Greg Shah almost 2 years ago
Java 17 Release Notes
Java 17 Features
As of Sept 2021, Java 17 is the latest LTS (long term support) release. I'd like to take a quick look at the effort of moving to Java 17 as well as any performance benefit to doing so.
Java 11 is an LTS release, as is Java 8 (which are are on at the moment). In #5567, we are close to merging the changes back and enabling support for both Java 8 and Java 11 in branch 3821c (soon to be in trunk of FWD v4). The problem here is that Java 11 seems to be consistently slower than Java 8. By ChUI testing, the difference is 5-30% and in one customer's appserver testing it was 10-20%. That is a large enough problem that most customers won't want to use it. If Java 17 is as fast or faster than Java 8, then it would be a priority to move to 17 unless there was a functional reason otherwise.
Java 17 has more changes to the underlying API and I'm pretty sure our code base will require changes to enable support. These changes will be incompatible with Java 8/11.
#3 Updated by Greg Shah over 1 year ago
- Assignee set to Tomasz Domin
I anticipate this work to occur in 2 phases.
- Update all (or as many as can be done without changing Java versions) dependencies to their latest levels.
- Rework FWD code to allow usage in Java 17.
We need to make an estimate of the work involved. I think we need to do this work sooner rather than later. I'm especially interested in knowing those changes which break compatibility with Java 8/11 and understanding the plan to make that shift. If these things can be done while still allowing us to use Java 8/11, then it opens up more possibilities for shifting faster. Keeping the option for Java 8/11 will also reduce risk because we can shift back if there is some blocking bug or performance problem (as with Java 11).
We will also want to test performance as early as possible to know if we have an issue there.
#4 Updated by Greg Shah over 1 year ago
Tomasz: Please go ahead and start work on the estimate. This is in parallel to your other work, so don't consume all of your time with this. Please keep a running summary of the changes expected as you identify them.
#5 Updated by Tomasz Domin over 1 year ago
- Status changed from New to WIP
I've created a branch 6692a based on 3821c.
I will do a quick check how build works under Java 17
and will provide the estimate.
#6 Updated by Roger Borrello over 1 year ago
Regarding what you might see as a minor devops item... version information.
Currently version.properties
contains something like:
major=4 minor=0 release=0 #repo, branch and rev are attempted to be read from code repository if not defined here repo=p2j branch=3821c rev=14349 #if desired the default version format can be changed here #format=<major>.<minor>.<release>_<repo>_<branch>_<rev>
I utilize this information when creating the archive
target such that we know important details about the distributed files. However, we don't have any way to indicate which version of Java was used to build FWD.
Any thought given to this? It gets even worse when we consider now Java 17... so at some near future point, we could be dealing with 3 varieties. Am I making much ado about nothing?
#7 Updated by Greg Shah over 1 year ago
If Java 17 is as fast or faster than Java 8, then we will never use Java 8 or Java 11 again. Usually, we only would support a single version of Java. Let's defer this concern for now.
#8 Updated by Tomasz Domin over 1 year ago
Its not just about Java version, but IMO its more about a whole execution environment. E.g. different database types, database engine versions, OS etc
#9 Updated by Greg Shah over 1 year ago
The OS version matters for a FWD build but we (as yet) have no differences by any other part of the environment. In particular, the database side is independent.
#10 Updated by Tomasz Domin over 1 year ago
java.lang.Record
.What is preferred way to solve this issue ?
- rename
com.goldencode.p2j.persist.Record
tocom.goldencode.p2j.persist.AbstractRecord
- add explicit import
com.goldencode.p2j.persist.Record;
to every class where "error: reference to Record is ambiguous" happens
#11 Updated by Greg Shah over 1 year ago
I would guess the second is preferable, but this is really Eric's call.
#12 Updated by Tomasz Domin over 1 year ago
I've tried to move a bit and have done initial migration to gradle 7.5.1 and tried to build FWD with Java 17.
Just to feel it I've also tried to upgrade dependencies to their latest versions but I gave up after 2-3 components, as performing that is complex and takes more time, I presumed providing initial estimate and plan has higher priority than actual upgrade at this stage. I guess I'd need 2 days for providing usable estimate.
Regarding steps: I'd like to add partial dependencies upgrade step, as it seems it is be not very costly.
From what I see (until now) upgrading dependencies' versions does not affect downwards compatibility - the latest versions of dependent components stay Java 8 downwards compatible.
For now a plan looks like following:
- Build environment upgrade to Java 17 with build tools upgrade and partial dependencies upgrade (only necessary upgrades)
- Migrate to gradle 7.5.1 (does not include migrating to java plugin) - (done)
- Update all dependencies (jars, scripts) to the latest versions working with current FWD code base to get FWD@Java 17 working configuration if feasible - 1d
- Update all (or as many as can be done without changing Java versions) dependencies to their latest levels. - this is something I cant estimate fully at this stage - there are too many direct and indirect dependencies that may affect the process when upgraded and I need more time for this.
- execute full dependencies analysis (find latest versions, check for compatibility etc) - 2d
- Rework FWD code to allow usage with latest dependencies versions - ?d
- create sub-tasks for upgrading components and FWD per case if needed (to implement larger changes) - ?d
- Testing
- regression testing (java 8, java 11, java 17) and results analysis - Effort: 2d, Elapsed: 6d due to tests execution time
- hotel_chui app,hotel_gui app - less then 1d
- performance testing (Java 8 vs Java 17) - 2d (getting test base, tests execution, tests results analysis)
- Merge Java 8/11 build configuration in 6692 (Java 8/11 stays on current dependencies' versions, Java 17 uses latest versions) - Effort: 1d
- Merge back 6692 into 3821c - 1d
- Post-merge support - 2d reserve
It would also help me if you specify how much time I can spend on this task in total,weekly or monthly.
#13 Updated by Greg Shah 10 months ago
- Related to Feature #7799: automated vulnerability scanning added
#14 Updated by Tomasz Domin 6 months ago
Restarting the tasks.
After rebasing to latest trunk
refreshing gradle
configuration.
#16 Updated by Tomasz Domin 5 months ago
There are 27 warnings mainly related with code deprecation. I will check them one by one and try to clear them minimizing suppressing.
[ant:javac] Note: Some input files use unchecked or unsafe operations. [ant:javac] Note: Recompile with -Xlint:unchecked for details. [ant:javac] 27 warnings
#17 Updated by Tomasz Domin 5 months ago
Regarding Java 17 and modules - there are few places I need to add --add-opens
JVM option to allow access of base module internals.
Greg, are there any broader guidelines regarding FWD and Java Modules (JPMS) ?
#19 Updated by Tomasz Domin 5 months ago
I've cleaned 6692
from compiler warnings by updating FWD code.
There were two cases where I had to add deprecated
note - in order to keep compatibility with Java 8 I couldn't migrate following warnings:
[ant:javac] /home/tjd/projects/p2j_6692a/src/com/goldencode/p2j/persist/orm/DataObjectFactory.java:370: warning: [deprecation] isAccessible() in AccessibleObject has been deprecated [ant:javac] if (!field.isAccessible()) [ant:javac] /home/tjd/projects/p2j_6692a/src/com/goldencode/p2j/util/logging/CentralLogRecord.java:222: warning: [deprecation] setMillis(long) in LogRecord has been deprecated [ant:javac] cl.setMillis(this.millis);
For both cases I've added some comments.
I've pushed 6692a/14923, please review.
Next I will create a new branch 6692b
which will be 6692a
rebased to 6667i
for regression and performance testing.
#20 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
Regarding Java 17 and modules - there are few places I need to add
--add-opens
JVM option to allow access of base module internals.Greg, are there any broader guidelines regarding FWD and Java Modules (JPMS) ?
After starting regression tests which is more or less the real application working on FWD I get following exceptions:
Caused by: java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'boolean com.goldencode.p2j.persist.BufferImpl.checkExtentRange(int, int)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') Caused by: java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'void com.goldencode.p2j.persist.BufferImpl.setQuery(com.goldencode.p2j.persist.QueryWrapper)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') Caused by: java.lang.RuntimeException: java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'boolean com.goldencode.p2j.persist.BufferImpl.checkExtentRange(int, int)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') Caused by: java.lang.RuntimeException: java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'void com.goldencode.p2j.persist.BufferImpl.setQuery(com.goldencode.p2j.persist.QueryWrapper)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'boolean com.goldencode.p2j.persist.BufferImpl.checkExtentRange(int, int)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'void com.goldencode.p2j.persist.BufferImpl.setQuery(com.goldencode.p2j.persist.QueryWrapper)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app') java.lang.RuntimeException: java.lang.IllegalAccessError: class com.goldencode.p2j.persist.BufferImplMethodAccess tried to access protected method 'boolean com.goldencode.p2j.persist.BufferImpl.checkExtentRange(int, int)' (com.goldencode.p2j.persist.BufferImplMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @47404bea; com.goldencode.p2j.persist.BufferImpl is in unnamed module of loader 'app')
Plus the old one:
java.lang.reflect.InaccessibleObjectException: Unable to make field private transient boolean java.util.logging.LogRecord.needToInferCaller accessible: module java.logging does not "opens java.util.logging" to unnamed module @2cd76f31
For now I will try with --add-opens
, but sooner or later these need to fixed by an implementation correction or a proper module packaging.
#21 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
Tomasz Domin wrote:
After starting regression tests which is more or less the real application working on FWD I get following exceptions:
[...]
These were fixed by updating signatures for checkExtentRange
and setQuery
to public
from protected
to enable access from generated code.
Plus the old one:
[...]
That was already fixed by adding --add-opens java.logging/java.util.logging=ALL-UNNAMED"
. Unfortunately that needs to be added to every FWD application's command line.
#22 Updated by Tomasz Domin 5 months ago
- Related to Bug #7443: performance of CentralLogger added
#23 Updated by Tomasz Domin 5 months ago
While regression testing I found another IllegalAccessException:
java.lang.IllegalAccessError: failed to access class com.goldencode.p2j.net.Queue from class com.goldencode.p2j.net.RouterSessionManagerMethodAccess (com.goldencode.p2j.net.Queue is in unnamed module of loader 'app'; com.goldencode.p2j.net.RouterSessionManagerMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @30990c1b) at com.goldencode.p2j.net.RouterSessionManagerMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:156) at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:788) at com.goldencode.p2j.net.Dispatcher.dispatch(Dispatcher.java:921) at com.goldencode.p2j.net.Dispatcher$DispatcherStub.run(Dispatcher.java:1740) at java.base/java.lang.Thread.run(Thread.java:833)
This time it was a bit harder to fix.
The exception was caused by illegal access from
AccessClassLoader
to non-public com.goldencode.p2j.net.Queue
. It seems exception is gone after making com.goldencode.p2j.net.Queue
class public.#25 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
That was already fixed by adding
--add-opens java.logging/java.util.logging=ALL-UNNAMED"
. Unfortunately that needs to be added to every FWD application's command line.
I've made a fix to CentralLogger.java
removing the need for adding --add-opens java.logging/java.util.logging=ALL-UNNAMED"
to every server startup.
Basically now application startup scripts should support Java 17 if they already support Java 11, no new changes to startup script would be needed.
#26 Updated by Tomasz Domin 5 months ago
Committed Hotel_ChUI_Demo_Application change revision 95 which brings back support for Java 11 and Java 17.
The change only applies to scripts and build files, no code was changed/updated.
#28 Updated by Tomasz Domin 5 months ago
Committed Hotel_Gui_Demo_Application change revision 321 that brings back option to run it under Java 11 and Java 17.
Tested Swing GUI Client
mode , Embedded Web Client
and Virtual Desktop Web Client
mode - all are working correctly under Java 17 (FWD branch @6692a/14964)
#31 Updated by Tomasz Domin 5 months ago
Greg Shah wrote:
Tested
Swing GUI Client
mode ,Embedded Web Client
andVirtual Desktop Web Client
mode - all are working correctly under Java 17 (FWD branch @6692a/14964)Doesn't embedded mode require the change from #8253?
It does, but I applied it temporarily for Java 17 testing as a kind of dirty and quick fix of blocking issue. I am not sure about side-effects of that change so I haven't committed it yet and I've created #8253 for someone more familiar with embedded mode to verify it.
#32 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
- Rework FWD code to allow usage with latest dependencies versions - ?d
Pushed branch 6692a
revision 14983
that has IMHO all possible upgrades of dependencies. By "all possible" I mean updates of components to the latest non-beta and non-snapshot version of Java components that are available in public repositories reported by ./gradlew dependencyUpdates
. If I have missed something important please let me know. I haven't upgraded any JS dependencies except dojotoolkit
.
I've briefly tested hotel_gui
with Java 17 and following clients: Swing GUI Client
, Virtual Desktop Web Client
, Embedded Web Client
and Administration console
- they all seem to work correctly.
The current report from ./gradlew dependencyUpdates
The following dependencies have later milestone versions: - antlr:antlr [2.7.7 -> 20030911] - false,, 2.7.7 is the latest - com.fasterxml.jackson.core:jackson-databind [2.13.4.2 -> 2.16.1] -> false, its net.sf.jasperreports:jasperreports:6.21.0 dependency - com.github.stephenc.high-scale-lib:high-scale-lib [1.1.2 -> 1.1.4] -> requires to stay at that version in a comment in build.gradle - com.google.guava:guava [19.0 -> 33.0.0-jre] - already updated -> false, already updated - commons-codec:commons-codec [1.15 -> 1.16.1] -> false, already updated, probably other component dependency - commons-codec:commons-codec [1.16.0 -> 1.16.1] -> false, already updated, probably other component dependency - commons-collections:commons-collections [3.2.2 -> 20040616] -> false, 3.2.2 is the latest - commons-io:commons-io [2.11.0 -> 2.15.1] -> false, already updated, probably other component dependency - commons-lang:commons-lang [2.4 -> 2.6] -> false, already updated, probably other component dependency - jakarta.xml.ws:jakarta.xml.ws-api [2.3.3 -> 4.0.1] -> cant be updated as it provided API missing in Java 17 - javax.mail:mail [1.4 -> 1.5.0-b01] -> no need to upgrade plain API package - javax.servlet:javax.servlet-api [3.1.0 -> 4.0.1] -> no need to upgrade plain API package - javax.xml.bind:jaxb-api [2.3.0 -> 2.4.0-b180830.0359] -> no need to upgrade plain API package - org.apache.poi:poi-ooxml-full [5.2.2 -> 5.2.5] -> probably other component dependency, cant directly update - org.apache.tika:tika-core [2.9.1 -> 3.0.0-BETA] -> dont update to BETA - org.apache.xmlbeans:xmlbeans [5.0.3 -> 5.2.0] -> probably other component dependency, cant directly update - org.bouncycastle:bcmail-jdk14 [1.72 -> 1.77] -> false, already updated, probably other component dependency - org.bouncycastle:bcprov-jdk14 [1.72 -> 1.77] -> false, already updated, probably other component dependency - org.eclipse.jetty.aggregate:jetty-all [9.4.22.v20191022 -> 11.0.0.beta1] -> cant upgrade - it needs a separate effort - org.janusgraph:janusgraph-berkeleyje [1.1.0-20240207-121257.e172faf -> 1.1.0-20240207-164433.d3c0e11] -> irrelevant - org.janusgraph:janusgraph-core [1.1.0-20240201-181040.3df4f04 -> 1.1.0-20240207-164433.d3c0e11] -> irrelevant - org.janusgraph:janusgraph-lucene [1.1.0-20240207-121257.e172faf -> 1.1.0-20240207-164433.d3c0e11] -> irrelevant - org.jsoup:jsoup [1.15.1 -> 1.17.2] > false, already updated - org.quartz-scheduler:quartz [2.3.2 -> 2.5.0-rc1] -> do not upgrade to RC version - org.slf4j:slf4j-api [2.0.12 -> 2.1.0-alpha1] -> do not upgrade to alpha versions - org.slf4j:slf4j-jdk14 [2.0.12 -> 2.1.0-alpha1] -> do not upgrade to alpha versions
I had A LOT of trouble upgrading
jetty
uber-jar so for now I've left it alone for now.For some funny reason Java 8 compiler enters infinite loop on
ant-compile step
, I need to check it out, as there should be support for all: Java 8/11/17.
So I guess now its time do regression testing and take care of upgrading jetty
in meantime.
#34 Updated by Tomasz Domin 5 months ago
Greg Shah wrote:
Sergey: Can you please review our javascript dependencies and mae a list of the latest stable/non-beta and non-snapshot versions? We need to update them in this branch.
This list can be of a little help, most of them are javascript dependencies.
Failed to determine the latest version for the following dependencies (use --info for details): - adamwdraper:adamwdraper-Numeral-js - bootstrap:bootstrap - cbtree:cbtree - com.goldencode:fwd-h2 - d3:d3 - font-bundle:font-bundle - gettext:gettext.js - io.keikai:fwd-keikai - io.keikai:fwd-keikai-ex - io.keikai:fwd-keikai-model - io.keikai:fwd-keikai-poi - jquery:jquery - jquery:jquery-loading-overlay - jquery:jquery-ui - material-components-web:material-components-web - material-design-icons:material-design-icons - net.sourceforge.barbecue:barbecue - org.apiguardian:apiguardian-api - org.junit.jupiter:junit-jupiter-api - org.junit.platform:junit-platform-console - org.junit.platform:junit-platform-engine - org.junit.platform:junit-platform-suite-engine - org.roaringbitmap:RoaringBitmap - tabulator:tabulator-master - virtualscroller:virtualscroller - webcola:webcola
#36 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
Tomasz Domin wrote:
- Rework FWD code to allow usage with latest dependencies versions - ?d
Pushed branch
6692a
revision14983
that has IMHO all possible upgrades of dependencies. By "all possible" I mean updates of components to the latest non-beta and non-snapshot version of Java components that are available in public repositories reported by./gradlew dependencyUpdates
. If I have missed something important please let me know. I haven't upgraded any JS dependencies exceptdojotoolkit
.
I've briefly testedhotel_gui
with Java 17 and following clients:Swing GUI Client
,Virtual Desktop Web Client
,Embedded Web Client
andAdministration console
- they all seem to work correctly.
The current report from./gradlew dependencyUpdates
[...]
Greg
I have a question about upgrading transitive dependencies.
There are some configuration where older components are in use then in other configuration, as newer versions are declared only in some configurations e.g. in fwdServer
and not in base configuration like fwdCCS
. Older components are there as they are needed by FWD dependencies for given configuration.
Shall I move forcing newer dependencies to base configuration so all dependencies versions are aligned for all configurations and we dont have different version of the same component in different configuration ?
#37 Updated by Tomasz Domin 5 months ago
Tomasz Domin wrote:
I had A LOT of trouble upgrading
jetty
uber-jar so for now I've left it alone for now.So I guess now its time do regression testing and take care of upgrading
jetty
in meantime.
Greg
And I have a question about jetty
upgrade.
I found a note about jetty
classifier uber
: But this Uber artifact is not for direct consumption, never was. It only exists to teach about jetty basics from the documentation point of view.
It causes issues in latest jetty
versions (not sure if minor or major :))
Are there any reasons why uber
classifier is in use instead jar
plus dependencies. I guess this would increase number of dependencies a lot, but are there any other reasons ?
#38 Updated by Greg Shah 5 months ago
Shall I move forcing newer dependencies to base configuration so all dependencies versions are aligned for all configurations and we dont have different version of the same component in different configuration ?
Yes, our intention is that everything is upgraded and we only use that latest version. If there is some reason to deviate from this, I want us to know exactly why that is the case.
#39 Updated by Greg Shah 5 months ago
I found a note about
jetty
classifieruber
:But this Uber artifact is not for direct consumption, never was. It only exists to teach about jetty basics from the documentation point of view.
It causes issues in latestjetty
versions (not sure if minor or major :))
Are there any reasons whyuber
classifier is in use insteadjar
plus dependencies. I guess this would increase number of dependencies a lot, but are there any other reasons ?
I don't recall the reasons.
Constantin or Hynek: Do you recall?
#40 Updated by Hynek Cihlar 5 months ago
Greg Shah wrote:
I found a note about
jetty
classifieruber
:But this Uber artifact is not for direct consumption, never was. It only exists to teach about jetty basics from the documentation point of view.
It causes issues in latestjetty
versions (not sure if minor or major :))
Are there any reasons whyuber
classifier is in use insteadjar
plus dependencies. I guess this would increase number of dependencies a lot, but are there any other reasons ?I don't recall the reasons.
Constantin or Hynek: Do you recall?
I think it was to bring down the number of dependencies.
#41 Updated by Tomasz Domin 5 months ago
Hynek Cihlar wrote:
Greg Shah wrote:
Constantin or Hynek: Do you recall?
I think it was to bring down the number of dependencies.
Regarding Jetty I had to take a step back as Jetty 9, 10 and 11 are basically different products with limited support for JVM versions - Jetty 9 works on Java 8, but neither Jetty 10, Jetty 11 nor Jetty 12 does. Jetty 12 requires Java 17, but there are changes to API so I'd need to make dedicated version of FWD classes, which I will skip for now. Despite Jetty 9 has no longer a public support there is a quite new version of Jetty 9 9.4.53.v20231009
- I guess 4 month old version is still OK, and after upgrading Guava
dependency there are no related vulnerabilities reported.
Greg - if you a different opinion and I'd need to work on bringing Jetty 12 to FWD under JVM 17+ please let me know. I guess that would require a partial source code split into Java8/Java11 and Java18+ versions.
#42 Updated by Greg Shah 5 months ago
Despite Jetty 9 has no longer a public support there is a quite new version of Jetty 9
9.4.53.v20231009
- I guess 4 month old version is still OK, and after upgradingGuava
dependency there are no related vulnerabilities reported.
What comes with the later Jetty versions besides the newer Java support?
Since Java 17 still has a negative performance impact compared with Java 8, it is hard to accept a forced move to Java 17. If the performance was not a problem, I would strongly consider it. I don't think we have any customers that would object. That would really make all of this easier.
Greg - if you a different opinion and I'd need to work on bringing Jetty 12 to FWD under JVM 17+ please let me know. I guess that would require a partial source code split into Java8/Java11 and Java18+ versions.
If we had to do this, how would you propse we could manage it? I would hope we could hide the messiness which some magic in the build process, but is nasty.
#43 Updated by Tomasz Domin 5 months ago
Greg Shah wrote:
Despite Jetty 9 has no longer a public support there is a quite new version of Jetty 9
9.4.53.v20231009
- I guess 4 month old version is still OK, and after upgradingGuava
dependency there are no related vulnerabilities reported.What comes with the later Jetty versions besides the newer Java support?
For Jetty 10 and 11 its support for newer servlet specifications. Jetty 12 supports all servlet specifications as its predecessors as it comes in 3 flavors. Jetty 12 is the newest so its supported and updated, which might be important in the context of application security, as Jetty 9 is in "End of Community Support" since June 2022.
Greg - if you a different opinion and I'd need to work on bringing Jetty 12 to FWD under JVM 17+ please let me know. I guess that would require a partial source code split into Java8/Java11 and Java18+ versions.
If we had to do this, how would you propse we could manage it? I would hope we could hide the messiness which some magic in the build process, but is nasty.
Maybe we should create Multi-release FWD JAR I need to think about it in the context of Java9+ modularization. I dont know yet.
#44 Updated by Tomasz Domin 5 months ago
When upgrading JanusGraph
to one of 1.1.0
releases there seems to be a bug in tinkerpop
/gremlin
graph traversal - it fails with java.lang.ClassCastException: class org.janusgraph.graphdb.types.indextype.CompositeIndexTypeWrapper cannot be cast to class org.janusgraph.graphdb.types.MixedIndexType
in case aggregate like max
is in use on CompositeIndex
. After index type for given attribute was changed to MixedIndexType
exception does not show up anymore and ant callgraph
terminates successfully.
#46 Updated by Tomasz Domin 4 months ago
Greg
It appears that javac
and iajc
task need more heap memory then default - when starting ant
from gradle
it seems it inherits its memory heap - by default gradle
7.6.4 gets only 512M heap memory.
Until now I was using fork="true"
If I don't you fork
with new memory limits I'd need to :
- increase somehow ant
memory limit to be able to call tasks straight from ant
command line
- increase gradle
heap in gradle.properties
as well to make
What is preferred way of increasing memory available to ant
and gradle
- via increasing ant
memory with ANT_OPTS
or via using maxmem
and fork
task attributes ?
Using fork
allows for setting heap requirements per task.
If using fork is a preferred way - what is reasonable heap limit for javac
and iajc
nowadays ? 1 GB is not enough for 6692a
branch. I'd set it to 4Gb to prevent worrying about that for next few years time.
#48 Updated by Greg Shah 4 months ago
What is preferred way of increasing memory available to
ant
andgradle
- via increasingant
memory withANT_OPTS
or via usingmaxmem
andfork
task attributes ?
Usingfork
allows for setting heap requirements per task.
I'll let Hynek comment here.
I do think that we cannot require that environment variables (e.g. ANT_OPTS
) are set properly in order for our build to work. We should have good defaults that are applied automatically. Setting the heap in the ant task would be my preference.
#49 Updated by Greg Shah 4 months ago
Alexandru Donica wrote:
I need a branch able to run with java 17 but made from the branch 7156b, for issue #8114. Could someone with more knowledge on this transition help make this branch?
The existing FWD trunk already supported Java 11 (see Switching Between Java 8 and Java 11). Can't #8114 be worked using Java 11?
#50 Updated by Tomasz Domin 4 months ago
Alexandru Donica wrote:
I need a branch able to run with java 17 but made from the branch 7156b, for issue #8114. Could someone with more knowledge on this transition help make this branch?
Please checkout branch 6692a
, note its work in progress and I dont think its recomended to rebase to that branch.6692a
is based on trunk/14974
, so you can generate a patch with bzr diff -r 14974
and apply to your branch 7156b
to make temporary update and make FWD
build with Java 17
.
#51 Updated by Hynek Cihlar 4 months ago
Greg Shah wrote:
What is preferred way of increasing memory available to
ant
andgradle
- via increasingant
memory withANT_OPTS
or via usingmaxmem
andfork
task attributes ?
Usingfork
allows for setting heap requirements per task.I'll let Hynek comment here.
For Gradle I think you can do this in gradle.properties
file placed in the project alongside build.gradle
. But I never tried this so the mileage may vary.
Ant runs inside of the Gradle process so that's that.
#52 Updated by Alexandru Donica 4 months ago
Greg Shah wrote:
The existing FWD trunk already supported Java 11 (see Switching Between Java 8 and Java 11). Can't #8114 be worked using Java 11?
There is a slight improvement when using Java 17 rather than Java 11. I was tasked with trying with Java 17.
#53 Updated by Tomasz Domin 4 months ago
Tomasz Domin wrote:
- Merge Java 8/11 build configuration in 6692 (Java 8/11 stays on current dependencies' versions, Java 17 uses latest versions) - Effort: 1d
Well, that was not that straightforward.
I unified the upgrade and I did that for all JVM versions, as there are not only dependencies for which I did only minor updates, but also there are ones having major updates that required FWD code changes.
Greg, if you'd like to stay on old/current dependencies for Java 8 and keep latest dependencies version only for Java 11/17 please let me know, I'll restructure build.gradle
There are a lot of changes in dependencies between Java 8 trunk
and Java 8 6692a
. The only difference between 6692a
Java 8 and 6692a
Java 17 versions is only different version of AspectJ, as new versions no longer support Java 8.
There are still libraries that FWD probably needs to migrate out of like (not many of them): xercesImpl, ghost4j, reflections, relaxngDatatype - but this might be just to broad for this task.
Regarding regression testing - 6692a
based on current 6667i
passes regression testing for Java 17, Java 8 tests are in progress. For Java 17 I had to increase memory limit for client - from 40mb to 48 mb, otherwise some of regression tests were randomly failing. I guess memory requirements increase is partially related with a larger JVM runtime and partially for a bit bigger size of dependencies.
Sergey: Can you please review our javascript dependencies and mae a list of the latest stable/non-beta and non-snapshot versions? We need to update them in this branch.
I am still waiting for JS updates to finalize the task (and reduce number of vulnerabilities), I check what I can do.
All direct dependencies updates are listed below (left is trunk, right is 6692a for JVM 17 > for added, < for removed, | for changed):
cglib:cglib:2.1_3 | cglib:cglib:3.3.0 com.esotericsoftware:reflectasm:1.11.6 | com.esotericsoftware:reflectasm:1.11.9 com.fasterxml.jackson.core:jackson-core:2.11.1 | com.fasterxml.jackson.core:jackson-core:2.16.1 com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:2.11.1 | com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:2.16.1 com.fasterxml.woodstox:woodstox-core:6.2.6 | com.fasterxml.woodstox:woodstox-core:6.6.0 com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 < com.googlecode.gwt-validation:gwt-validation:2.1 < com.google.guava:guava:19.0 < com.google.guava:guava-gwt:21.0 | com.google.guava:guava-gwt:33.0.0-jre com.kohlschutter.junixsocket:junixsocket-common:2.5.2 | com.kohlschutter.junixsocket:junixsocket-common:2.8.3 com.kohlschutter.junixsocket:junixsocket-native-common:2.5.2 | com.kohlschutter.junixsocket:junixsocket-native-common:2.8.3 com.lowagie:itext:2.1.7 | com.lowagie:itext:4.2.1 com.mchange:c3p0:0.9.5.2 | com.mchange:c3p0:0.9.5.5 commons-codec:commons-codec:1.7 -> 1.10 | commons-codec:commons-codec:1.16.1 commons-io:commons-io:2.6 | commons-io:commons-io:2.15.1 > commons-logging:commons-logging:1.3.0 com.twelvemonkeys.common:common-image:3.1.2 | com.twelvemonkeys.common:common-image:3.10.1 com.twelvemonkeys.common:common-io:3.1.2 | com.twelvemonkeys.common:common-io:3.10.1 com.twelvemonkeys.common:common-lang:3.1.2 | com.twelvemonkeys.common:common-lang:3.10.1 com.twelvemonkeys.imageio:imageio-core:3.1.2 | com.twelvemonkeys.imageio:imageio-core:3.10.1 com.twelvemonkeys.imageio:imageio-metadata:3.1.2 | com.twelvemonkeys.imageio:imageio-metadata:3.10.1 de.intarsys.opensource:jPod:5.5.1 | de.intarsys.opensource:jPod:5.6 dom4j:dom4j:1.6 -> 1.6.1 | org.dom4j:dom4j:2.1.4 > jakarta.security.auth.message:jakarta.security.auth.message-api > jakarta.xml.ws:jakarta.xml.ws-api:2.3.3 net.java.dev.msv:msv-core:2010.2 | net.java.dev.msv:msv-core:2022.7 net.sf.ehcache:ehcache-core:2.6.2 | net.sf.ehcache:ehcache-core:2.6.11 net.sf.jasperreports:jasperreports:6.5.1 | net.sf.jasperreports:jasperreports:6.21.0 org.apache.axis2:axis2-adb:1.6.2 | org.apache.axis2:axis2-adb:1.8.2 org.apache.axis2:axis2-kernel:1.6.2 | org.apache.axis2:axis2-kernel:1.8.2 org.apache.axis2:axis2-transport-http:1.6.2 | org.apache.axis2:axis2-transport-http:1.8.2 org.apache.axis2:axis2-transport-local:1.6.2 | org.apache.axis2:axis2-transport-local:1.8.2 org.apache.bcel:bcel:5.2 | org.apache.bcel:bcel:6.8.1 org.apache.commons:commons-email:1.5 | org.apache.commons:commons-email:1.6.0 > org.apache.commons:commons-text:1.11.0 org.apache.httpcomponents:httpclient:4.5.1 | org.apache.httpcomponents:httpclient:4.5.14 org.apache.james:apache-mime4j:0.8.3 | org.apache.james:apache-mime4j:0.8.9 org.apache.pdfbox:fontbox:2.0.5 | org.apache.pdfbox:fontbox:3.0.1 org.apache.pdfbox:pdfbox:2.0.5 | org.apache.pdfbox:pdfbox:3.0.1 > org.apache.logging.log4j:log4j-1.2-api:2.22.1 > org.apache.logging.log4j:log4j-core:2.22.1 org.apache.poi:poi:3.15 | org.apache.poi:poi:5.2.5 org.apache.tika:tika-core:1.18 | org.apache.tika:tika-core:2.9.1 org.apache.ws.commons.axiom:axiom-api:1.2.22 | org.apache.ws.commons.axiom:axiom-api:1.4.0 org.apache.ws.commons.axiom:axiom-impl:1.2.22 | org.apache.ws.commons.axiom:axiom-impl:1.4.0 org.apache.xmlgraphics:batik-codec:1.8 | org.apache.xmlgraphics:batik-codec:1.17 org.apache.xmlgraphics:batik-extension:1.8 | org.apache.xmlgraphics:batik-extension:1.17 org.apache.xmlgraphics:batik-gui-util:1.8 | org.apache.xmlgraphics:batik-gui-util:1.17 org.apache.xmlgraphics:batik-gvt:1.8 | org.apache.xmlgraphics:batik-gvt:1.17 org.apache.xmlgraphics:batik-svggen:1.8 | org.apache.xmlgraphics:batik-svggen:1.17 org.apache.xmlgraphics:batik-swing:1.8 | org.apache.xmlgraphics:batik-swing:1.17 org.apache.xmlgraphics:batik-transcoder:1.8 | org.apache.xmlgraphics:batik-transcoder:1.17 org.apache.xmlgraphics:xmlgraphics-commons:2.0 | org.apache.xmlgraphics:xmlgraphics-commons:2.9 > org.apiguardian:apiguardian-api:1.1.2 org.aspectj:aspectjrt:1.9.7 | org.aspectj:aspectjrt:1.9.21 org.aspectj:aspectjtools:1.9.7 | org.aspectj:aspectjtools:1.9.21 org.aspectj:aspectjweaver:1.9.7 | org.aspectj:aspectjweaver:1.9.21 org.bouncycastle:bcmail-jdk15to18:1.69 | org.bouncycastle:bcmail-jdk18on:1.77 org.bouncycastle:bcpg-jdk15to18:1.69 | org.bouncycastle:bcpg-jdk18on:1.77 org.bouncycastle:bcpkix-jdk15to18:1.69 | org.bouncycastle:bcpkix-jdk18on:1.77 org.bouncycastle:bcprov-jdk15to18:1.69 | org.bouncycastle:bcprov-jdk18on:1.77 org.bouncycastle:bctls-jdk15to18:1.69 | org.bouncycastle:bctls-jdk18on:1.77 org.codehaus.woodstox:stax2-api:4.2.1 | org.codehaus.woodstox:stax2-api:4.2.2 org.dojotoolkit:dojo:1.10.0 | org.dojotoolkit:dojo:1.17.3 org.eclipse.jetty.aggregate:jetty-all:9.4.22.v20191022 < > org.eclipse.jetty:jetty-server:9.4.53.v20231009 > org.eclipse.jetty:jetty-webapp:9.4.53.v20231009 > org.eclipse.jetty.websocket:websocket-server:9.4.53.v20231009 > org.eclipse.emf:common:2.2.3 org.eclipse.jetty:jetty-proxy:9.4.22.v20191022 | org.eclipse.jetty:jetty-proxy:9.4.53.v20231009 > org.freemarker:freemarker:2.3.32 | org.glassfish:javax.json:1.1.4 org.gwtbootstrap3:gwtbootstrap3:0.9.4 | org.gwtbootstrap3:gwtbootstrap3:1.0.1 org.gwtbootstrap3:gwtbootstrap3-extras:0.9.4 | org.gwtbootstrap3:gwtbootstrap3-extras:1.0.2 org.janusgraph:janusgraph-berkeleyje:0.1.0 | org.janusgraph:janusgraph-berkeleyje:1.1.0-20240207-121257.e172 org.janusgraph:janusgraph-core:0.1.0 < org.janusgraph:janusgraph-lucene:0.1.0 | org.janusgraph:janusgraph-lucene:1.1.0-20240207-121257.e172faf org.javassist:javassist:3.19.0-GA+ -> 3.19.0-GA | org.javassist:javassist:3.30.2-GA > org.jboss.logging:jboss-logging:3.5.3.Final org.jsoup:jsoup:1.14.3 | org.jsoup:jsoup:1.17.2 org.junit.jupiter:junit-jupiter-api:5.9.0 | org.junit.jupiter:junit-jupiter-api:5.10.2 org.junit.platform:junit-platform-console:1.9.0 | org.junit.platform:junit-platform-console:1.10.2 org.junit.platform:junit-platform-engine:1.9.0 | org.junit.platform:junit-platform-engine:1.10.2 org.junit.platform:junit-platform-suite-engine:1.9.0 | org.junit.platform:junit-platform-suite-engine:1.10.2 org.mariadb.jdbc:mariadb-java-client:3.1.2 | org.mariadb.jdbc:mariadb-java-client:3.3.2 org.ow2.asm:asm:5.0.3 | org.ow2.asm:asm:9.6 org.postgresql:postgresql:42.2.5 | org.postgresql:postgresql:42.7.1 org.quartz-scheduler:quartz:2.2.1 | org.quartz-scheduler:quartz:2.3.2 org.roaringbitmap:RoaringBitmap:0.9.40 | org.roaringbitmap:RoaringBitmap:1.0.1 > org.reflections:reflections:0.10.2 org.shredzone.acme4j:acme4j-client:0.10 < org.shredzone.acme4j:acme4j-utils:0.10 < org.slf4j:jcl-over-slf4j:1.7.36 | org.slf4j:slf4j-jdk14:2.0.12 org.slf4j:slf4j-api:1.7.36 | org.slf4j:slf4j-api:2.0.12 xerces:xercesImpl:2.11.0 | xerces:xercesImpl:2.12.2
Adding new dependencies is usually related with an update of a new transitive dependency. Removed libraries are usually brought as transitive dependency.
I've removed ACME libs completely (it was not working since Java 11 update anyway).
#54 Updated by Tomasz Domin 4 months ago
I have pushed Java 17 compatible branch 6692a
revision 15009, which is based on a quite recent trunk
revision 14990.
It has been regression tested using Java 8 and Java 17 runtimes.
#55 Updated by Hynek Cihlar 4 months ago
Tomasz, do you have any comparison on performance between 8 and 17?
#56 Updated by Hynek Cihlar 4 months ago
Hynek Cihlar wrote:
Tomasz, do you have any comparison on performance between 8 and 17?
OK, I found it in #8208-27.
#57 Updated by Greg Shah 4 months ago
if you'd like to stay on old/current dependencies for Java 8 and keep latest dependencies version only for Java 11/17 please let me know,
I have no interest in this, unless we find some failure than only can be resolved with the old dependencies.
What work is left on this task? Do we just need wider testing?
#58 Updated by Tomasz Domin 4 months ago
Greg Shah wrote:
if you'd like to stay on old/current dependencies for Java 8 and keep latest dependencies version only for Java 11/17 please let me know,
I have no interest in this, unless we find some failure than only can be resolved with the old dependencies.
I guess old components are tested better thus instability/failure risk is lower. In case there is a customer having current version of FWD 4 on production there is a risk of instabilities and a bit higher memory usage (even for Java 8).
Whats left:What work is left on this task? Do we just need wider testing?
- updating fwd-imageio-bmp to 3.10.1 to due to a critical vulnerability CVE-2021-23792 (will submit the patch) - in progress, eta 2h
- updating JavaScript components - Sergey or I can do it.
- testing, testing, testing - especially JasperReports and GWT dependent code,
spawner
also needs some testing
I did manual tests (mainly with hotel_gui
) and regression tests, but there may be parts of FWD that may be affected by subcomponent update not tested yet.
#59 Updated by Tomasz Domin 4 months ago
- File twelvemonkeys-fwd-imageio-bmp-3.10.1.jar added
- File imageio-bmp-3.10.2-mask-memory-fix.diff
added
Tomasz Domin wrote:
Whats left:
- updating fwd-imageio-bmp to 3.10.1 to due to a critical vulnerability CVE-2021-23792 (will submit the patch) - in progress, eta 2h
Attached imageio-bmp:3.10.1
memory allocation for 24-bit icons patch imageio-bmp-3.10.2-mask-memory-fix.diff
and rebuilt fwd-imageio-bmp-3.10.1.jar
to be put into GCD repository. Its only tested with own imageio-bmp
tests, but I dont think it could cause any regression in FWD.
Greg - can you please upload fwd-imageio-bmp-3.10.1.jar
to GCD maven repository ?
#60 Updated by Tomasz Domin 4 months ago
- File deleted (
twelvemonkeys-fwd-imageio-bmp-3.10.1.jar)
#61 Updated by Tomasz Domin 4 months ago
- File fwd-imageio-bmp-3.10.1.zip added
Tomasz Domin wrote:
Tomasz Domin wrote:
Whats left:
- updating fwd-imageio-bmp to 3.10.1 to due to a critical vulnerability CVE-2021-23792 (will submit the patch) - in progress, eta 2h
Attached
imageio-bmp:3.10.1
memory allocation for 24-bit icons patchimageio-bmp-3.10.2-mask-memory-fix.diff
and rebuiltfwd-imageio-bmp-3.10.1.jar
to be put into GCD repository. Its only tested with ownimageio-bmp
tests, but I dont think it could cause any regression in FWD.Greg - can you please upload
fwd-imageio-bmp-3.10.1.jar
to GCD maven repository ?
Sorry, wrong upload. fwd-imageio-bmp-3.10.1.jar
is now inside a zip file that just needs to be unzipped into GCD root of maven repository.
#64 Updated by Greg Shah 3 months ago
- % Done changed from 0 to 100
- Status changed from WIP to Internal Test
I know you've been doing some amount of testing on this. As far as I know, we only have testing and any fixes that are needed based on issues found in the testing.
- Are there any open bugs?
- What has been tested so far?
- Is there any other work needed?
#65 Updated by Tomasz Domin 3 months ago
Greg Shah wrote:
I know you've been doing some amount of testing on this. As far as I know, we only have testing and any fixes that are needed based on issues found in the testing.
- Are there any open bugs?
None I know of.
- What has been tested so far?
Standard regression tests + hotel GUI
- Is there any other work needed?
I still need to update JS libraries.
#67 Updated by Eugenie Lyzenko 3 months ago
Guys,
Regarding possible migration I have a question. Will we have performance degradation with Java 8 -> Java 17
? Do we have some comparison estimations? I guess for some projects this could be critical point.
#68 Updated by Greg Shah 3 months ago
Yes, this can be found in #8208-18. A summary for those that can't access that task:
- Java 8 is faster than Java 11 by 21,0% on average per test
- Java 8 is faster than Java 17 by 13,3% on average per test
- Java 17 is faster than Java 11 by 5,5% on average per test
Calculations for weighted average - the longer the test the higher its weight - and the performance difference is smaller:
- Java 8 is faster than Java 11 by 12,35% on weighted average per test
- Java 8 is faster than Java 17 by 9,82% on weighted average per test
- Java 17 is faster than Java 11 by 3,32% on weighted average per test
So the difference is less visible for longer operations (tests).
The short version: expect to lose up to 13% when moving from Java 8 to Java 17. It is better than Java 11 but not as good as we would hope for.
#69 Updated by Hynek Cihlar 3 months ago
It would be interesting to profile a test case with both Java 8 and Java 17 and see where the times differ. Having more insights into the timings we could perhaps tune up some of the JVM settings.
#70 Updated by Tomasz Domin 3 months ago
Greg Shah wrote:
Did you test both embedded mode and virtual desktop in Hotel GUI?
Yes, I did
Did you test call graph in Hotel GUI?
And Yes, I did :)
We need to test ETF and the POC. Optimally, some smoke testing in a large GUI application would also be a good idea.
Fully agree.
#71 Updated by Tomasz Domin 3 months ago
Rebased to trunk/15136, pushed into repository 6692/15156
Working on JS libraries updates.
#72 Updated by Tomasz Domin 3 months ago
Rebased 6692a to trunk/15146 and pushed 6692a/15146.
I started to work on JS updates, upgraded with webjars versions jquery,jquery-ui,bootstrap,d3 - tried to update matching path.
But does it really make sense ? It seems JS libraries are managed by client application, I tried to update libraries but got nothing but failures, as web resource path were not matching (specific internal resource paths need to be kept).
As an example please check web_partial_login_embedded.html
from hotel_gui
:
<link rel="stylesheet" href="embedded/dojo-toolkit/dijit/themes/claro/claro.css" type="text/css"> <link rel="stylesheet" href="embedded/bootstrap/css/bootstrap.min.css" type="text/css"> <link rel="stylesheet" href="embedded/jquery-ui/jquery-ui.min.css" type="text/css"> <link rel="stylesheet" href="embedded/tabulator/tabulator.css" type="text/css"> <link rel="stylesheet" href="embedded/custom/ehotel.css" type="text/css"> <script type="text/javascript" src="embedded/jquery/jquery-3.2.1.js"></script> <script type="text/javascript" src="embedded/jquery-ui/jquery-ui.min.js"></script> <script type="text/javascript" src="embedded/bootstrap/js/bootstrap.min.js"></script> <script type="text/javascript" src="embedded/custom/moment-2.17.1/moment.js"></script> <script type="text/javascript" src="embedded/d3/d3.js"></script> <!-- http://bl.ocks.org/davegotz/bd54b56723c154d25eedde6504d30ad7 --> <script type="text/javascript" src="embedded/custom/d3-tip/d3.tip.js"></script> <script type="text/javascript" src="embedded/tabulator/tabulator.js"></script>
Note all libraries are included in client application. I guess this is a kind of a standard FWD JS header.
I guess they should be included by a standard script like fwd_sdk.js
instead, so all needed version are loaded by FWD framework.
For now I'll stop here unless instructed otherwise.
#74 Updated by Hynek Cihlar 3 months ago
Greg Shah wrote:
Hynek: What do you think?
I like the idea of having the dependencies in fwd_sdk.js
. Moving them from the individual project in the core FWD source tree will simplify dependency management and deployment.
#75 Updated by Tomasz Domin 3 months ago
Greg Shah wrote:
I prefer not to leave old dependencies in the code. On the other hand, I don't want to delay this branch since many customers are waiting.
Tomasz: What do you expect is the effort for the JS dependencies?
Its hard to say, I need to look in different places and I am not proficient in JS.
#77 Updated by Hynek Cihlar 3 months ago
Greg Shah wrote:
Hynek: What would you estimate for the effort?
I would say up to two days. The JS dependencies are indeed a bit messy.
Some notes:- JS dependencies are mostly served by
WebResourceHandler
, seeGuiWebDriver.init
where it is setup - embedded resources are served by
EmbeddedWebHandler
- Report Server has its own mechanism, see
ThirdPartyDependenciesHandler
#78 Updated by Tomasz Domin 3 months ago
Hynek Cihlar wrote:
Greg Shah wrote:
Hynek: What would you estimate for the effort?
I would say up to two days. The JS dependencies are indeed a bit messy.
Some notes:
- JS dependencies are mostly served by
WebResourceHandler
, seeGuiWebDriver.init
where it is setup- embedded resources are served by
EmbeddedWebHandler
- Report Server has its own mechanism, see
ThirdPartyDependenciesHandler
Note I am already on it. Not sure if able to finalize that work.
#79 Updated by Tomasz Domin 3 months ago
- File hotel_gui_patch.diff
added
Hynek Cihlar wrote:
Greg Shah wrote:
Hynek: What would you estimate for the effort?
I would say up to two days. The JS dependencies are indeed a bit messy.
Some notes:
- JS dependencies are mostly served by
WebResourceHandler
, seeGuiWebDriver.init
where it is setup- embedded resources are served by
EmbeddedWebHandler
- Report Server has its own mechanism, see
ThirdPartyDependenciesHandler
It took me some time, as framework JS libraries are loaded and in sync mode and I had to make dynamic libraries initialized before static JS is executed, mostly for embedded mode.
I've updated following JS dependencies (note I chose the last version with the same major version)- d3 4.9.1 to d3 4.13.0 webjars
- bootstrap 3.3.7 to bootstrap 3.4.1 webjars
- jquery 3.2.1 to jquery 3.7.1 webjars
- jquery-ui 1.12.1-custom to jquery-ui 1.13.2 webjars (not sure if could - what is custom here ?)
- dojotoolkit 1.10.0 to dojotoolkit 1.17.3 (a bundle from maven central)
proj.goldencode.com
:
- fwdClient group: 'adamwdraper', name: 'adamwdraper-Numeral-js', version: '7de892f', ext: 'zip'
- fwdClient group: 'cbtree', name: 'cbtree', version: 'v0.9.4', classifier: '0', ext: 'zip'
- fwdClient group: 'font-bundle', name: 'font-bundle', version: 'v1', ext: 'zip' // WARNING: this zip name is hardcoded in WebResourceHandler
- fwdClient group: 'material-components-web', name: 'material-components-web', version: '0.37.0', ext: 'zip' // WARNING: this zip name is hardcoded in WebResourceHandler
- fwdClient group: 'material-design-icons', name: 'material-design-icons', version: '96', ext: 'zip' // WARNING: this zip name is hardcoded in WebResourceHandler
- fwdClient group: 'tabulator', name: 'tabulator-master', version: '2.12.0', ext: 'zip' // WARNING: this zip name is hardcoded in WebResourceHandler
- fwdClient group: 'virtualscroller', name: 'virtualscroller', version: '1', ext: 'zip'
- fwdClient group: 'webcola', name: 'webcola', version: '3.3.9', ext: 'zip'
Webjars means that dependency is migrated from ZIP file uploaded to GCD repository to central MAVEN repository managed jar file wrapping needs JS library (see https://www.webjars.org/)
Embedded applications need to be updated - a sample patch for hotel_gui
is attached.
Rebased to trunk/15150
, pushed @6692a/15171
Hynek - you can check the changes - all are in the last commit.
#80 Updated by Hynek Cihlar 3 months ago
Code review 6692a revision 15171. The changes look good.
#81 Updated by Roger Borrello 3 months ago
- OpenJDK or Oracle?
- What is the default to be set? Java 8 or Java 17? When do we fish or cut-bait on the switch of the default to Java 17?
- Do we need Docker images based off both, or do we make a wholesale changeover?
- Are script that were changed to handle Java 11 forward compatible with Java 17 (provided they determine Java 11 or greater)? Specifically the SPI configuration is the only thing that really was different in the move from Java 8 to Java 11 that I added to server/client scripts.
- Do we move customers (mostly I care about my customer :-) to convert/run Java 17 ASAP?
#82 Updated by Greg Shah 3 months ago
OpenJDK or Oracle?
In the code we should not have dependencies on either one.
In practive, we tend to use OpenJDK because it is good and has permissive licensing.
What is the default to be set? Java 8 or Java 17?
Java 8
When do we fish or cut-bait on the switch of the default to Java 17?
Not yet. We need to look into the performance differences and see if we can eliminate those. If so, then we will gladly move to Java 17 by default.
Do we need Docker images based off both
Yes
or do we make a wholesale changeover?
No
Are script that were changed to handle Java 11 forward compatible with Java 17 (provided they determine Java 11 or greater)? Specifically the SPI configuration is the only thing that really was different in the move from Java 8 to Java 11 that I added to server/client scripts.
This one is for Tomasz.
Do we move customers (mostly I care about my customer :-) to convert/run Java 17 ASAP?
No, for now we let customers decide when to move.
#83 Updated by Roger Borrello 3 months ago
Greg Shah wrote:
OpenJDK or Oracle?
In the code we should not have dependencies on either one.
In practice, we tend to use OpenJDK because it is good and has permissive licensing.
This was more for the standard desktop and other Ansible-scripted environments I am responsible for. Currently I use openjdk-8
, so I'll stick with OpenJDK for Java 17.
#84 Updated by Roger Borrello 3 months ago
Greg Shah wrote:
Do we need Docker images based off both
Yes
or do we make a wholesale changeover?
No
I believe I can include both in the base image. But when it comes to the FWD image, I can specify some sort of option in the build of the Docker image such that the default JVM can be specified on the command line.
Follow-up question... if FWD is built with a specific Java, is it forever connected to conversion/runtime of an application using the same version? Or can FWD built with Java 17 be used in a conversion that is done with Java 8 (and vice-versa)? If this is not the case, perhaps I could include both built FWDs in the FWD Docker image, and allow the container creation to choose the one that would be used.
#86 Updated by Tomasz Domin 3 months ago
Roger Borrello wrote:
I have some basic questions, since this task is moving steadily towards implementation. Great job! These come from my Docker, standard laptop (#6894) and CI/CD server (#7183) build needs, as well as concern for our customer application timing. Maybe these same questions where answered with the #5567 task, but we'll need this information gathered regardless.
- OpenJDK or Oracle?
I am on OpenJDK and have no recent experience with Oracle, I guess it depends on customer requirements.
- Do we need Docker images based off both, or do we make a wholesale changeover?
I work with separate images for each supported java version if you remember thats why I needed suffix option when building docker images:
base_mariadb_11 jdk11 5dc41c065153 2 months ago 1.07GB base_mariadb_11 jdk17 5dc41c065153 2 months ago 1.07GB base_mariadb_11 jdk8 5dc41c065153 2 months ago 1.07GB base_postgres_14 jdk11 e7182121e72c 2 months ago 935MB base_postgres_14 jdk17 e7182121e72c 2 months ago 935MB base_postgres_14 jdk8 e7182121e72c 2 months ago 935MB
- Are script that were changed to handle Java 11 forward compatible with Java 17 (provided they determine Java 11 or greater)? Specifically the SPI configuration is the only thing that really was different in the move from Java 8 to Java 11 that I added to server/client scripts.
Yes they are, in addition in few cases (mostly GWT related) I needed to open module API with --add-opens
, You can see sample changes #8208-6 (the change for logging is not needed anymore).
Follow-up question... if FWD is built with a specific Java, is it forever connected to conversion/runtime of an application using the same version? Or can FWD built with Java 17 be used in a conversion that is done with Java 8 (and vice-versa)? If this is not the case, perhaps I could include both built FWDs in the FWD Docker image, and allow the container creation to choose the one that would be used.
I guess its better to stick to the same rule as I proposed for Java 11 - use a single Java version for full building process, despite it would be possible to run Java 8 compiled code on Java 17 (but not vice-versa) or convert with Java 8 and compile with Java 17, there is no difference in generated code (for now).
#87 Updated by Roger Borrello 3 months ago
Tomasz Domin wrote:
I work with separate images for each supported java version if you remember thats why I needed suffix option when building docker images:
base_mariadb_11 jdk11 5dc41c065153 2 months ago 1.07GB base_mariadb_11 jdk17 5dc41c065153 2 months ago 1.07GB base_mariadb_11 jdk8 5dc41c065153 2 months ago 1.07GB base_postgres_14 jdk11 e7182121e72c 2 months ago 935MB base_postgres_14 jdk17 e7182121e72c 2 months ago 935MB base_postgres_14 jdk8 e7182121e72c 2 months ago 935MB
This looks odd to me, Tomasz. The base_mariadb_11
images have the same Image ID of 5dc41c065153
, which indicates they are the same image, just with different tags. Am I missing something?
#88 Updated by Tomasz Domin 3 months ago
Roger Borrello wrote:
Tomasz Domin wrote:
I work with separate images for each supported java version if you remember thats why I needed suffix option when building docker images:
[...]
This looks odd to me, Tomasz. The
base_mariadb_11
images have the same Image ID of5dc41c065153
, which indicates they are the same image, just with different tags. Am I missing something?
You are right and I chose wrong examples - I guess there is no java in that images :). Images with java have different signatures:
base_ubuntu_22.04 jdk11 e19c77610df2 2 months ago 1.56GB base_ubuntu_22.04 jdk17 39c29daa7d55 2 months ago 1.6GB base_ubuntu_22.04 jdk8 2900252d14f3 2 months ago 1.5GB base_ubuntu_22.04_pg14 jdk11 038c9d7a1813 2 months ago 2.38GB base_ubuntu_22.04_pg14 jdk17 b420158e6422 2 months ago 2.42GB base_ubuntu_22.04_pg14 jdk8 c15a2d245bba 2 months ago 2.32GB xxxxx_ubuntu_xfer 14 76c14511151e 2 months ago 53.1GB xxxxx_ubuntu_xfer 14_jdk11 aaa7321e868d 2 months ago 53.1GB xxxxx_ubuntu_xfer 14_jdk17 2e1117489357 2 months ago 53.2GB xxxxx_ubuntu_xfer 14_jdk8 76c14511151e 2 months ago 53.1GB
#89 Updated by Greg Shah 3 months ago
Code Review Task Branch 6692a Revision 15171
Although I do like managing the dependencies explicitly in our JS code, I don't think we should be loading all of the embedded dependencies as part of fwd_sdk.js
. The tabulator
and d3
are definitely things that are only used in the analytics (the report server). I don't recall what moment
is.
We should only load the minimum dependencies based on the mode (report server, virtual desktop or embedded). In other words, if something is not used in a specific mode then we should not be loading it. Doing that reduces the security exposure (less libraries loaded equals less possible vulnverabilities exposed). It also makes it less likely that other libraries loaded will have conflicts. We should expect customers to be loading their own libraries, especially in embedded mode.
#91 Updated by Galya B 3 months ago
Greg Shah wrote:
Galya: Please review 6692a revision 15171.
fwd_sdk.js
is not the right place to load the libraries, it is a lightweight interface for communication with the server on the login page, while these libraries are used after login. Also they are used only with embedded and even then it's not guaranteed. Check hotel_gui where web_partial_login_embedded.html
is overwritten in webres with the custom embedded implementation. So it's safe to update the dependencies in gradle and the local paths in EmbeddedWebHandler
as it has been done, but no changes to the front-end are needed, since the url paths are not modified. The changes in fwd_sdk.js
should be reverted and the relevant part of the comment in EmbeddedWebHandler
too. Also, I've noticed the warnings in build.gradle should be updated to state it's EmbeddedWebHandler
, not WebResourceHandler
.
#92 Updated by Hynek Cihlar 3 months ago
I agree with the comments from Greg and Galya. Still it makes sense to put the dependencies that are integral part of FWD (surely virtual mode, report server, maybe some dependencies for embedded mode) into a single js to be easily included in the stock welcome pages and in the specific projects. That is a single js for every mode.
#93 Updated by Galya B 3 months ago
Hynek Cihlar wrote:
I agree with the comments from Greg and Galya. Still it makes sense to put the dependencies that are integral part of FWD (surely virtual mode, report server, maybe some dependencies for embedded mode) into a single js to be easily included in the stock welcome pages and in the specific projects. That is a single js for every mode.
What is the benefit?
The libraries in concern in r15171 are used only by custom front-ends in the embedded mode.
#94 Updated by Hynek Cihlar 3 months ago
Galya B wrote:
Hynek Cihlar wrote:
I agree with the comments from Greg and Galya. Still it makes sense to put the dependencies that are integral part of FWD (surely virtual mode, report server, maybe some dependencies for embedded mode) into a single js to be easily included in the stock welcome pages and in the specific projects. That is a single js for every mode.
What is the benefit?
The libraries in concern in r15171 are used only by custom front-ends in the embedded mode.
There are specific dependencies needed for FWD to run in embedded mode. If they are included in a single bundle which will be managed inside FWD itself, it will simplify deployment/upgrades.
The need for an upgrade will come from FWD product upgrade, but also from the vulnerability check, which may happen often.
#95 Updated by Galya B 3 months ago
Hynek Cihlar wrote:
Galya B wrote:
Hynek Cihlar wrote:
I agree with the comments from Greg and Galya. Still it makes sense to put the dependencies that are integral part of FWD (surely virtual mode, report server, maybe some dependencies for embedded mode) into a single js to be easily included in the stock welcome pages and in the specific projects. That is a single js for every mode.
What is the benefit?
The libraries in concern in r15171 are used only by custom front-ends in the embedded mode.
There are specific dependencies needed for FWD to run in embedded mode. If they are included in a single bundle which will be managed inside FWD itself, it will simplify deployment/upgrades.
The need for an upgrade will come from FWD product upgrade, but also from the vulnerability check, which may happen often.
I think this is not related to the current upgrade to java 17. Do you mind to create a new task for further discussion?
#96 Updated by Hynek Cihlar 3 months ago
Galya B wrote:
I think this is not related to the current upgrade to java 17. Do you mind to create a new task for further discussion?
Makes sense, see #8651.
#97 Updated by Hynek Cihlar 3 months ago
- Related to Feature #8651: Centralize inclusion of JS dependencies added
#98 Updated by Tomasz Domin 3 months ago
Greg Shah wrote:
Code Review Task Branch 6692a Revision 15171
Although I do like managing the dependencies explicitly in our JS code, I don't think we should be loading all of the embedded dependencies as part of
fwd_sdk.js
. Thetabulator
andd3
are definitely things that are only used in the analytics (the report server). I don't recall whatmoment
is.
In build.gradle
dependencies they are all grouped under fwdClient
group, should they be split into subgroups for clarity ?
We should only load the minimum dependencies based on the mode (report server, virtual desktop or embedded). In other words, if something is not used in a specific mode then we should not be loading it. Doing that reduces the security exposure (less libraries loaded equals less possible vulnverabilities exposed). It also makes it less likely that other libraries loaded will have conflicts. We should expect customers to be loading their own libraries, especially in embedded mode.
I've checked and virtual desktop does not need any of these libraries, they are specific to embedded mode (as stated below). Not sure what reporting server needs.
Galya B wrote:
Greg Shah wrote:
Galya: Please review 6692a revision 15171.
...So it's safe to update the dependencies in gradle and the local paths in @EmbeddedWebHandler
as it has been done, but no changes to the front-end are needed, since the url paths are not modified.
Its not true for all the cases - url path are modified - see jquery
, and may be further modified in future. The way they are modified depends on the way dependencies are managed - e.g. WebJars or other way, URL mapping in EmbeddedWebHandler
only works for path prefix.
Also, I've noticed the warnings in build.gradle should be updated to state it's
EmbeddedWebHandler
, notWebResourceHandler
.
Nice catch, I'll update it.
Galya B wrote:
Hynek Cihlar wrote:
I agree with the comments from Greg and Galya. Still it makes sense to put the dependencies that are integral part of FWD (surely virtual mode, report server, maybe some dependencies for embedded mode) into a single js to be easily included in the stock welcome pages and in the specific projects. That is a single js for every mode.
What is the benefit?
The libraries in concern in r15171 are used only by custom front-ends in the embedded mode.
I agree with Hynek regarding benefits, there are JS script we do care about in FWD and lets state it clear by putting them into a dedicated file.
It should also make updating/upgrading dependencies easier - there are two files to be changed only, no need to dig into customer embedded mode implementations.
I also agree that maybe instead putting embedded mode dependencies into fwd_sdk.js
we should put it into another file, maybe like fwd_embedded.js
?
#99 Updated by Galya B 3 months ago
Tomasz Domin wrote:
Galya B wrote:
Greg Shah wrote:
Galya: Please review 6692a revision 15171.
...So it's safe to update the dependencies in gradle and the local paths in @EmbeddedWebHandler
as it has been done, but no changes to the front-end are needed, since the url paths are not modified.Its not true for all the cases - url path are modified - see
jquery
, and may be further modified in future. The way they are modified depends on the way dependencies are managed - e.g. WebJars or other way, URL mapping inEmbeddedWebHandler
only works for path prefix.
The third argument in the WebResourceHandler
constructor is not part of the url, it's used for server-side mapping of the url context path to the local resource path. That being said, there is still a flaw in the design of this API, because the resources are supposed to be used by custom customer code and upgrading the versions and/or paths will break their dependencies. EmbeddedWebHandler
maps a whole lib dir to a context path, but the url paths accessing specific lib files will have to be changed in all customer front-ends.
So the question is do we expose these libraries only for hotel_gui embedded example or we want to allow the customers to build their pages upon them. If the first is true, then you just need to update hotel_gui/webres/web_partial_login_embedded.html
as well. If the second is true, we need to come up with a better API and the changes to the updates of the js libs can be reverted for now.
I also agree that maybe instead putting embedded mode dependencies into
fwd_sdk.js
we should put it into another file, maybe likefwd_embedded.js
?
Let's discuss it further in #8651.
#100 Updated by Galya B 3 months ago
Tomasz Domin wrote:
Galya B wrote:
The libraries in concern in r15171 are used only by custom front-ends in the embedded mode.
I agree with Hynek regarding benefits, there are JS script we do care about in FWD and lets state it clear by putting them into a dedicated file.
It should also make updating/upgrading dependencies easier - there are two files to be changed only, no need to dig into customer embedded mode implementations.I also agree that maybe instead putting embedded mode dependencies into
fwd_sdk.js
we should put it into another file, maybe likefwd_embedded.js
?
Actually these js dependencies should be removed from the server build. They should be added by the customer project, if used in their embedded page. There is already a mechanism for adding paths for custom web resources in the customer projects. This way FWD will not be responsible for upgrading / breaking customer front-end code. We'll update hotel_gui
by adding the libs in the webres
dir and update the src urls in web_partial_login_embedded.html
. We can do it this way for hotel_gui, but in general I would recommend customers to include dependencies from the original lib urls for better cacheability or use their own package managers and minifier pipelines before distributing by adding in webres.
Greg, Constantin, what do you think about removing the js files for the custom embedded pages from the server dependencies? I don't see a reason for them to be always packed with FWD.
#101 Updated by Galya B 2 months ago
org.slf4j:jcl-over-slf4j:1.7.36
is replaced byorg.slf4j:slf4j-jdk14:2.0.12
. FWD has custom slf4j implementation, so we must not haveslf4j-jdk14
or similar in our dependencies. Alsojcl-over-slf4j
is needed, it's a bridge binding other APIs to slf4j.- As for
commons-logging:commons-logging
: it is a facade for logging, alternative tojcl-over-slf4j
, so it moves 3rd party logging away from our slf4j implementation. If its found in the transitive dependencies, it should be added to:if (JavaVersion.current().isCompatibleWith(JavaVersion.VERSION_11)) { exclude group: 'commons-logging', module: "commons-logging"
org.jboss.logging:jboss-logging:3.5.3.Final
is added, but I don't see where it's used.- As discussed in #8555
org.apache.logging.log4j:log4j
dependencies should be removed.
#102 Updated by Galya B 2 months ago
- File logging.patch
added
Find attached the required changes to fix the logging dependencies and migrate slf4j implementation to version 2. After rebase on trunk, ghost4j
will be removed as dependency as well.
With slf4j api v2 the separate fwd-slf4j.jar
is removed, because the loading mechanism has changed, so the implementation has been moved to src/com/goldencode/p2j/util/logging
. The slf4j implementation is selected with java system property slf4j.provider
and will be added to server.sh
/ client startup scripts to default to com.goldencode.p2j.util.logging.CentralSlf4jProvider
or to another string, if the customer has a different impl.
The attached patch is for review and should be committed to 6692a.
#103 Updated by Galya B 2 months ago
src/com/goldencode/p2j/report/web/res/index.html
(the3pl
context is removed inReportWebServer.ThirdPartyDependenciesHandler
when mapping to res files);- After merge,
hotel_gui/webres/web_partial_login_embedded.html
; - After merge, any customer code using web embedded. We probably need to find another long-term solution for the dependencies in hotel_gui and customer embedded pages, but we can do so in #8651.
#104 Updated by Greg Shah 2 months ago
The logging patch looks reasonable. Tomasz: do you have any objections? If not, this should be committed into 6692a.
will be added to
server.sh
/ client startup scripts to default tocom.goldencode.p2j.util.logging.CentralSlf4jProvider
or to another string, if the customer has a different impl
Galya: Do you have a suggested patch for the Hotel GUI project?
#105 Updated by Tomasz Domin 2 months ago
Greg Shah wrote:
The logging patch looks reasonable. Tomasz: do you have any objections? If not, this should be committed into 6692a.
No, I don't, changes to logging were needed and Galya helped me a lot with her logging patch.
I am in a process of rebasing to latest trunk and committing the changes
#106 Updated by Tomasz Domin 2 months ago
- File hotel_gui_slf20.diff
added
- Rebased to
trunk/15157
- upgraded com.google.gwt/org.gwtproject dependencies
- reverted org.apache.pdfbox to latest 2.0.x version (3.0 has a different API)
- merged
logging.patch
from Galya
Pushed 6692a/15182
Attached a patch to hotel_gui
to make slf4j2 logging work (basically following property -Dslf4j.provider=com.goldencode.p2j.util.logging.CentralSlf4jProvider
needs to be added to a server command line)
Tested changes with hotel_gui
app, logging seems to be working correctly.
#107 Updated by Greg Shah 2 months ago
Attached a patch to
hotel_gui
to make slf4j2 logging work (basically following property-Dslf4j.provider=com.goldencode.p2j.util.logging.CentralSlf4jProvider
needs to be added to a server command line)
Is our default safe? In other words, can we run without setting anything on the command line? I would hope that setting that value would only be needed to override the default.
#108 Updated by Galya B 2 months ago
Greg Shah wrote:
Attached a patch to
hotel_gui
to make slf4j2 logging work (basically following property-Dslf4j.provider=com.goldencode.p2j.util.logging.CentralSlf4jProvider
needs to be added to a server command line)Is our default safe? In other words, can we run without setting anything on the command line? I would hope that setting that value would only be needed to override the default.
From https://www.slf4j.org/faq.html#changesInVersion200
In SLF4J 2.0.x and later, during its initalization, LoggerFactory looks up SLF4JServiceProvider instances using the Java platfom's ServiceLoader mechanism. An artifact containing an implementation of the SLF4JServiceProvider interface is called a "provider".
since 2.0.9 You can specify the provider class explicitly via the "slf4j.provider" system property. This bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization.
With slf4j api v2 there are two methods of loading the logging provider: The default one with ServiceLoader
should be automatic, but I find in example implementations that the custom package containing the SLF4JServiceProvider
implementation has module-info.java
where:
module custom.package { requires org.slf4j; requires java.logging; provides org.slf4j.spi.SLF4JServiceProvider with custom.package.CentralSlf4jProvider; exports org.slf4j.jul; opens custom.package to org.slf4j; }
And since I couldn't find any module info classes in our code, I wasn't sure how the provider can be found automatically. If the initialization is delayed, the libs may not catch the provider. That's why I proposed the quicker, more reliable approach with system property, but it needs to be explicitly defined in every startup script and explicitly overwritten (to empty) for customers who use their own slf4j implementation.
P.S. When slf4j impl is found there are a few lines in server logs indicating it has been loaded successfully:
INFO | com.mchange.v2.log.MLog | ThreadName:MLog-Init-Reporter | MLog clients using slf4j logging.
INFO | org.eclipse.jetty.util.log | ThreadName:main, Session:00000000, Thread:00000001, User:standard | Logging initialized @6054ms to org.eclipse.jetty.util.log.Slf4jLog
#109 Updated by Tomasz Domin 2 months ago
- File CentralSlf4jProvider.diff
added
Galya B wrote:
From https://www.slf4j.org/faq.html#changesInVersion200
In SLF4J 2.0.x and later, during its initalization, LoggerFactory looks up SLF4JServiceProvider instances using the Java platfom's ServiceLoader mechanism. An artifact containing an implementation of the SLF4JServiceProvider interface is called a "provider".
since 2.0.9 You can specify the provider class explicitly via the "slf4j.provider" system property. This bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization.
With slf4j api v2 there are two methods of loading the logging provider: The default one with
ServiceLoader
should be automatic, but I find in example implementations that the custom package containing theSLF4JServiceProvider
implementation hasmodule-info.java
where:
I've added CentralSlf4jProvider
as service and it seems changes to server.sh
are not needed anymore.
Attached a patch CentralSlf4jProvider.diff
to enable a service without a need for a command line parameter - it works fine for hotel_gui
.
Galya B wrote:
Greg Shah wrote:
Attached a patch to
hotel_gui
to make slf4j2 logging work (basically following property-Dslf4j.provider=com.goldencode.p2j.util.logging.CentralSlf4jProvider
needs to be added to a server command line)Is our default safe? In other words, can we run without setting anything on the command line? I would hope that setting that value would only be needed to override the default.
With CentralSlf4jProvider.diff
I think default is safe.
Galya - I have a question on slf4j
bridges - why only jcl-over-slf4j
is included ? I guess log4j
is eliminated so we dont need log4j-over-slf4j
, but what about jul-to-slf4j
?
#110 Updated by Tomasz Domin 2 months ago
- File CentralSlf4jProvider.diff
added
Updated the patch, I needed to put a correct name into build.xml
#111 Updated by Galya B 2 months ago
Tomasz Domin wrote:
I've added
CentralSlf4jProvider
as service and it seems changes toserver.sh
are not needed anymore.
Attached a patchCentralSlf4jProvider.diff
to enable a service without a need for a command line parameter - it works fine forhotel_gui
.
I see how this works and it can give us a default, but now the issue is that some customers need to disable our slf4j implementation and I thought it will be easier with the property. Although #7589 is not likely to happen with slf4j api v2, we still need to allow the customers to plug in their own logging. With the jar approach I'm not sure if the service provider can be changed or disabled in customer projects having p2j.jar
in the classpath.
Galya - I have a question on
slf4j
bridges - why onlyjcl-over-slf4j
is included ? I guesslog4j
is eliminated so we dont needlog4j-over-slf4j
, but what aboutjul-to-slf4j
?
When I originally migrated logging to the CentralLogger
from stderr
(where the java.util.logging
writes also went) I haven't found missing logs or a library complaining about loggers. If we can pinpoint a library that is important to log, but the logs are missing, then we can consider some additional bridges. Otherwise, we should not add more logging dependencies interfering with the customer projects. Also jul-to-slf4j
seems to have major performance issues, when not configured well, more at https://www.slf4j.org/legacy.html.
#113 Updated by Tomasz Domin 2 months ago
Galya B wrote:
Tomasz, can you test if the property overwrites the service loader? If it works, it should be fine.
Yes, in case slf4j.provider
is defined service loader does not even start - SLF4J simply loads specified provider e.g.
For -Dslf4j.provider=com.goldencode.p2j.util.logging.CentralSlf4jProvider
SLF4J(I): Attempting to load provider "com.goldencode.p2j.util.logging.CentralSlf4jProvider" specified via "slf4j.provider" system property
or for
-Dslf4j.provider=org.slf4j.simple.SimpleServiceProvider
SLF4J(I): Attempting to load provider "org.slf4j.simple.SimpleServiceProvider" specified via "slf4j.provider" system property
Galya B wrote:
Also, to make sure the patch for the service loader works, make sure to find the two messages from the bottom of #6692-108 in the server logs.
Yes, they are there:
tjd/1.8.0_402:~/projects/hotel_gui_6692a$ grep -e MLog -e "Logging initialized" deploy/logs/* deploy/logs/fwd_server_20240423_161807_0_0.log:24/04/23 16:18:09.436+0200 | INFO | com.mchange.v2.log.MLog | ThreadName:MLog-Init-Reporter | MLog clients using slf4j logging. deploy/logs/fwd_server_20240423_161807_0_0.log:24/04/23 16:18:11.902+0200 | INFO | org.eclipse.jetty.util.log | ThreadName:main, Session:00000000, Thread:00000001, User:standard | Logging initialized @4701ms to org.eclipse.jetty.util.log.Slf4jLog
#116 Updated by Tomasz Domin 2 months ago
Galya B wrote:
OK, just one last clarification: Can you override the service loader with an empty property
-Dslf4j.provider=
?
No, it cant.
But I found a way for disabling any service provider when service loader tries to discover it - it is needed throw an RuntimeException in its constructor :) like:
public CentralSlf4jProvider () { if ("true".equals( System.getProperty("disableSLF4JServiceProvider"))) { throw new RuntimeException(); } }
In that case we get: org.slf4j.spi.SLF4JServiceProvider: Provider com.goldencode.p2j.util.logging.CentralSlf4jProvider could not be instantiated
and SLF tries to load the next one.
#117 Updated by Galya B 2 months ago
It could be an option if needed later on. For now I think it's not necessary. But I remembered a few more places that need update. The default "fwd-slf4j"
in ClientBuilderOptions
should be null
, fwd-slf4j.jar
should be removed from postbuild.sh
, import.sh
. ./slf4j-impl.jar
should be removed from the options in spawn.c
and winspawn.c
. These are not critical, just cleanup.
#118 Updated by Roger Borrello 2 months ago
Galya B wrote:
But I remembered a few more places that need update. The default
"fwd-slf4j"
inClientBuilderOptions
should benull
,fwd-slf4j.jar
should be removed frompostbuild.sh
,import.sh
../slf4j-impl.jar
should be removed from the options inspawn.c
andwinspawn.c
. These are not critical, just cleanup.
Greg, should I update postbuild.sh
and import.sh
in this branch?
Also, a question, since I may have missed a detail... are there changes to be made in the client.sh
and/or server.sh
files to set options appropriately as defaults? Note that I had made changes to install_spawner.sh
when we needed to include fwd-slf4j.jar
, so we may need to make changes to match this branch when that time comes.
#119 Updated by Galya B 2 months ago
Roger Borrello wrote:
Also, a question, since I may have missed a detail... are there changes to be made in the
client.sh
and/orserver.sh
files to set options appropriately as defaults? Note that I had made changes toinstall_spawner.sh
when we needed to includefwd-slf4j.jar
, so we may need to make changes to match this branch when that time comes.
We'll have to revert to cleanup, because the new mechanism of loading will have the default as part of p2j.jar
. Only clients who don't need our implementation will need to add a property to client.sh
and/or server.sh
to change the slf4j provider. I think the customer you're asking about will need simply a revert when time comes.
#120 Updated by Roger Borrello 2 months ago
Galya B wrote:
We'll have to revert to cleanup, because the new mechanism of loading will have the default as part of
p2j.jar
. Only clients who don't need our implementation will need to add a property toclient.sh
and/orserver.sh
to change the slf4j provider. I think the customer you're asking about will need simply a revert when time comes.
Thanks for the details!
#121 Updated by Greg Shah 2 months ago
Also, a question, since I may have missed a detail... are there changes to be made in the
client.sh
and/orserver.sh
files to set options appropriately as defaults?
I'm OK with providing an option to override the default. If the option is not specified, then no property should be set (so that the default will naturally be used).
This way customers can use the standard version of our scripts.
#122 Updated by Tomasz Domin 2 months ago
Greg Shah wrote:
Also, a question, since I may have missed a detail... are there changes to be made in the
client.sh
and/orserver.sh
files to set options appropriately as defaults?I'm OK with providing an option to override the default. If the option is not specified, then no property should be set (so that the default will naturally be used).
This way customers can use the standard version of our scripts.
Default setting will use CentralSlf4jProvider
, I've added an option to block it by setting disableCentralSlf4jProvider
system property. In that case an alternative slf4j provider needs to be added to the JVM classpath.
Pushed up to revision 15183.
#124 Updated by Eugenie Lyzenko 2 months ago
Attempting to use 6692a
with Java 8 causes exceptions:
... Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodError: org.bouncycastle.crypto.engines.AESEngine.newInstance()Lorg/bouncycastle/crypto/MultiBlockCipher; at com.goldencode.p2j.util.TransactionManager.abnormalEnd(TransactionManager.java:5958) at com.goldencode.p2j.util.TransactionManager.access$9000(TransactionManager.java:720) at com.goldencode.p2j.util.TransactionManager$TransactionHelper.abnormalEnd(TransactionManager.java:9416) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8871) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.Pwma2.versleutelSecret(Pwma2.java:91) at <cust_app>.src.sys.Pwma2MethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) ... 136 more Caused by: java.lang.NoSuchMethodError: org.bouncycastle.crypto.engines.AESEngine.newInstance()Lorg/bouncycastle/crypto/MultiBlockCipher; at com.goldencode.p2j.util.CryptoUtils$CipherParams.cipher(CryptoUtils.java:412) at com.goldencode.p2j.util.CryptoUtils$CipherParams.process(CryptoUtils.java:364) at com.goldencode.p2j.util.SecurityOps.encryptDecryptWorker(SecurityOps.java:3877) at com.goldencode.p2j.util.SecurityOps.encrypt(SecurityOps.java:1923) at com.goldencode.p2j.util.SecurityOps.encrypt(SecurityOps.java:1836) at <cust_app>.src.sys.Pwma2.lambda$versleutelSecret$3(Pwma2.java:100) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) ... 144 more ...
Is it expected? Moving to Java 17 stops compatibility with Java 8?
#125 Updated by Tomasz Domin 2 months ago
Eugenie Lyzenko wrote:
Attempting to use
6692a
with Java 8 causes exceptions:[...]
Is it expected? Moving to Java 17 stops compatibility with Java 8?
No, it is not expected, thank you for testing.
Note 6692 is not only about Java 17, but also about updating a lot of dependencies which has not been touched for years and it seems some should stay in place.
#126 Updated by Eugenie Lyzenko 2 months ago
Tomasz Domin wrote:
Eugenie Lyzenko wrote:
Attempting to use
6692a
with Java 8 causes exceptions:[...]
Is it expected? Moving to Java 17 stops compatibility with Java 8?
No, it is not expected, thank you for testing.
Note 6692 is not only about Java 17, but also about updating a lot of dependencies which has not been touched for years and it seems some should stay in place.
I'm going to check Java 17 now. Is the code converted with Java 8 compatible with Java 17? Or I have to reconvert application project with Java 17 to be able to run it with Java 17 runtime?
#127 Updated by Tomasz Domin 2 months ago
Eugenie Lyzenko wrote:
I'm going to check Java 17 now. Is the code converted with Java 8 compatible with Java 17? Or I have to reconvert application project with Java 17 to be able to run it with Java 17 runtime?
Yes, you can run Java 8 code on Java 17, but that is not something we'd like to test. I think our goal is to test complete conversion/runtime for java 8 and separately for Java 17, so I'd recommend to reconvert.
#128 Updated by Eugenie Lyzenko 2 months ago
Tomasz Domin wrote:
Eugenie Lyzenko wrote:
I'm going to check Java 17 now. Is the code converted with Java 8 compatible with Java 17? Or I have to reconvert application project with Java 17 to be able to run it with Java 17 runtime?
Yes, you can run Java 8 code on Java 17, but that is not something we'd like to test. I think our goal is to test complete conversion/runtime for java 8 and separately for Java 17, so I'd recommend to reconvert.
OK. Understood. I'll postpone this step until I get conversion for Java 17.
#129 Updated by Tomasz Domin 2 months ago
Branch 6692a
has been tested with hotel_gui
, hotel_chui
and standard regression testing suite. But it seems that is not enough, customer applications have specific deployments that need to be tested in addition.
I guess dependencies updates bring more risks than JVM update.
- decide about JS dependencies centralization -> it seems we'll revert to the old way
- update migration documentation - add some common Q&A's to help with customer application migration
- freeze dependencies updates for
6692a
- rebase to a stable FWD trunk
- test FWD for regression related with dependencies updates
- test branch
6692a
with Java 8 - test branch
6692a
with Java 17
- test branch
- test customer applications for regression - the most important applications - I guess we need a subtask for each application:
- test each application on branch
6692a
with Java 8 - test each application on branch
6692a
with Java 17
- test each application on branch
#130 Updated by Constantin Asofiei 2 months ago
I've tried ETF, but a suite gets into an infinite loop, while one passes. This was with Java 8 conversion and Java 17 FWD build and execution.
#131 Updated by Eugenie Lyzenko 2 months ago
Seems like I have new issue:
24/04/30 23:41:59.829+0300 | SEVERE | com.goldencode.p2j.main.CommonDriver | ThreadName:main, Session:00000000, Thread:00000001, User:standard | System exits with code -13 caused by: com.goldencode.p2j.cfg.ConfigurationException: Initialization failure at com.goldencode.p2j.main.StandardServer.hookInitialize(StandardServer.java:2507) at com.goldencode.p2j.main.StandardServer.bootstrap(StandardServer.java:1230) at com.goldencode.p2j.main.ServerDriver.start(ServerDriver.java:534) at com.goldencode.p2j.main.CommonDriver.process(CommonDriver.java:593) at com.goldencode.p2j.main.ServerDriver.process(ServerDriver.java:225) at com.goldencode.p2j.main.ServerDriver.main(ServerDriver.java:1010) Caused by: java.lang.NoClassDefFoundError: org/eclipse/jetty/annotations/AnnotationConfiguration at com.goldencode.p2j.web.GenericWebServer.initializeWebApp(GenericWebServer.java:464) at [big_GUI_app].initialize(big_GUI_app_Web.java:28) at com.goldencode.p2j.main.StandardServer.hookInitialize(StandardServer.java:2503) ... 5 more Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.annotations.AnnotationConfiguration at java.net.URLClassLoader.findClass(URLClassLoader.java:387) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:359) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) ... 8 more
Seems like config issue. With spawner may be.
What command do you use to set up spawner? Do we need fwd-slf4j.jar
in spawner directory?
#132 Updated by Eugenie Lyzenko 2 months ago
Tomasz Domin wrote:
Branch
6692a
has been tested withhotel_gui
,hotel_chui
and standard regression testing suite.
Have you tested hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.
#133 Updated by Roger Borrello 2 months ago
Eugenie Lyzenko wrote:
Have you tested
hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.
I believe there is an issue using hotel_gui
web client on H2, because the password will never match the one read from the DB. Have you tried PostgreSQL?
#134 Updated by Eugenie Lyzenko 2 months ago
Roger Borrello wrote:
Eugenie Lyzenko wrote:
Have you tested
hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.I believe there is an issue using
hotel_gui
web client on H2, because the password will never match the one read from the DB. Have you tried PostgreSQL?
This is not application login. But initial Chrome OS login page. Most likely spawn issue instead.
#135 Updated by Eugenie Lyzenko 2 months ago
OK. To start application with Java 8 we need to add at least the following into build.gradle
:
dependencies { ... fwdClientServer group: 'org.eclipse.jetty', name: 'jetty-annotations', version: '9.4.53.v20231009' ...
The application starts and work normally for smoke tests. However I see now the following error:
... {/home/evl/big_gui_app_full/deploy/lib/big_gui_app.war} javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:672) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350) at javax.naming.InitialContext.lookup(InitialContext.java:417) at org.eclipse.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:254) at org.eclipse.jetty.plus.webapp.EnvConfiguration.preConfigure(EnvConfiguration.java:66) at org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:488) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:523) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.server.Server.start(Server.java:423) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) at org.eclipse.jetty.server.Server.doStart(Server.java:387) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at com.goldencode.p2j.web.GenericWebServer.startup(GenericWebServer.java:640) at com.goldencode.p2j.web.GenericWebServer.lambda$initializeWebApp$0(GenericWebServer.java:529) at java.lang.Thread.run(Thread.java:750) ...
Need to have updated .war
file?
Tomorrow I hope to get Java 17 converted application to test in different Java version.
#136 Updated by Eugenie Lyzenko 2 months ago
Eugenie Lyzenko wrote:
Roger Borrello wrote:
Eugenie Lyzenko wrote:
Have you tested
hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.I believe there is an issue using
hotel_gui
web client on H2, because the password will never match the one read from the DB. Have you tried PostgreSQL?This is not application login. But initial Chrome OS login page. Most likely spawn issue instead.
This was due to not configured SSO for hotel GUI. I disabled SSO and it works now.
#137 Updated by Greg Shah 2 months ago
Eugenie Lyzenko wrote:
Eugenie Lyzenko wrote:
Roger Borrello wrote:
Eugenie Lyzenko wrote:
Have you tested
hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.I believe there is an issue using
hotel_gui
web client on H2, because the password will never match the one read from the DB. Have you tried PostgreSQL?This is not application login. But initial Chrome OS login page. Most likely spawn issue instead.
This was due to not configured SSO for hotel GUI. I disabled SSO and it works now.
We do need to make sure that SSO also works. When you say "not configured SSO", what do you mean?
#138 Updated by Eugenie Lyzenko 2 months ago
Greg Shah wrote:
Eugenie Lyzenko wrote:
Eugenie Lyzenko wrote:
Roger Borrello wrote:
Eugenie Lyzenko wrote:
Have you tested
hotel_gui
with web client and Java 8? In my case the client session can not be started due to login/password issue in web browser.I believe there is an issue using
hotel_gui
web client on H2, because the password will never match the one read from the DB. Have you tried PostgreSQL?This is not application login. But initial Chrome OS login page. Most likely spawn issue instead.
This was due to not configured SSO for hotel GUI. I disabled SSO and it works now.
We do need to make sure that SSO also works. When you say "not configured SSO", what do you mean?
I meant the following:
... <node-attribute name="ssoplugin" value="com.goldencode.hotel.HotelGuiSsoAuthenticator"/> <node-attribute name="ssopluginoption" value="bogus"/> ...
I thought the "bogus"
should be replaced with some value generated for specific deploy system. If the "bogus"
is the real value then SSO does not work in Hotel GUI I guess (for trunk as well).
#139 Updated by Galya B 2 months ago
Eugenie Lyzenko wrote:
This was due to not configured SSO for hotel GUI. I disabled SSO and it works now.
Intriguing. I thought embedded web can't be even started without SSO.
StandardServer
:
boolean ssoEnabled = SecurityManager.getInstance().ssoSm.isSsoEnabled(); boolean embedded = false; if (ssoEnabled && Utils.getDirectoryNodeBoolean(null,"webClient/embedded", false, false)) { // embedded works only with SSO enabled num++; embedded = true; }
Eugenie Lyzenko wrote:
I thought the
"bogus"
should be replaced with some value generated for specific deploy system. If the"bogus"
is the real value then SSO does not work in Hotel GUI I guess (for trunk as well).
It says in Single Sign On that ssopluginoption
is:
A free text that is fed to the custom
SsoAuthenticator
implementation on instantiation. Can be used to pass in any type of configs;
In hotel gui's implementation HotelGuiSsoAuthenticator
it's used to pass in the default fwd account for the new session and it does it very well.
If you have any other issues with hotel_gui please find the relevant log messages and post in the relevant task.
#140 Updated by Eugenie Lyzenko 2 months ago
Galya B wrote:
Eugenie Lyzenko wrote:
This was due to not configured SSO for hotel GUI. I disabled SSO and it works now.
Intriguing. I thought embedded web can't be even started without SSO.
StandardServer
:
[...]Eugenie Lyzenko wrote:
I thought the
"bogus"
should be replaced with some value generated for specific deploy system. If the"bogus"
is the real value then SSO does not work in Hotel GUI I guess (for trunk as well).It says in Single Sign On that
ssopluginoption
is:A free text that is fed to the custom
SsoAuthenticator
implementation on instantiation. Can be used to pass in any type of configs;In hotel gui's implementation
HotelGuiSsoAuthenticator
it's used to pass in the default fwd account for the new session and it does it very well.If you have any other issues with hotel_gui please find the relevant log messages and post in the relevant task.
Do you have worked SSO
enabled Hotel GUI
for Web client with current FWD
trunk?
#144 Updated by Eugenie Lyzenko 2 months ago
Galya B wrote:
Eugenie Lyzenko wrote:
Do you have worked
SSO
enabledHotel GUI
for Web client with currentFWD
trunk?I'm not babysitting the project.
?
The question was simple. I did not suppose you will fix something. I asked whether you can run SSO enabled Hotel GUI in Web client mode with recent trunk. Or not. It will take ~10 min to do if starting from scratch. If you have an answer - it will be great. But if you have no time - never mind.
#146 Updated by Eugenie Lyzenko 2 months ago
The first results for using Java 17 with big GUI application.
1. Conversion was completed. Build compiled.
2. The script install_spawner.sh
is need to be changed. I think can be used from Hotel GUI directory.
3. The server start up script is also to be changed due to -Djava.ext.dirs
is no more valid option in Java 17:
... -cpath="-classpath $cpath" +cpath="-classpath $cpath:../lib/spi" ... -spi="-Djava.locale.providers=SPI,JRE -Djava.ext.dirs=$(${prog} ${cpath} com.goldencode.util.PrintSystemProp java.ext.dirs):../lib/spi" +spi="-Djava.locale.providers=SPI,JRE" ...
4. With these changes the server starting having the error noted in #6692-135. However the application is not usable. Login attempts crashes with exception:
... 24/05/01 23:25:18.196+0300 | SEVERE | com.goldencode.p2j.util.TransactionManager | ThreadName:Conversation [0000000D:bogus], Session:00000013, Thread:00000005, User:bogus | Abnormal end; original error: java.lang.IllegalAccessError: class <cust_app>.src.sys.apps.UsermgtbaseMethodAccess tried to access protected method 'void <cust_app>.src.sys.apps.Usermgtbase.clearResponseHandler(com.goldencode.p2j.util.object)' (<cust_app>.src.sys.apps.UsermgtbaseMethodAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @366c4480; <cust_app>.src.sys.apps.Usermgtbase is in unnamed module of loader 'app') at <cust_app>.src.sys.apps.UsermgtbaseMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.invokeLegacyMethod(ControlFlowOps.java:5164) at com.goldencode.p2j.util.ProcedureManager$LegacySubscription.publish(ProcedureManager.java:6009) at com.goldencode.p2j.util.ProcedureManager.lambda$publish$3(ProcedureManager.java:1355) at com.goldencode.p2j.util.ProcedureManager.publish(ProcedureManager.java:1414) at com.goldencode.p2j.util.ProcedureManager.publish(ProcedureManager.java:1262) at com.goldencode.p2j.util.ClassEvent.publish(ClassEvent.java:143) at <cust_app>.src.sys.apps.Httpsocketwithjwt.publish_clearResponse(Httpsocketwithjwt.java:87) at <cust_app>.src.sys.apps.Httpsocketwithjwt.lambda$post$7(Httpsocketwithjwt.java:336) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:814) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:787) at <cust_app>.src.sys.apps.Httpsocketwithjwt.post(Httpsocketwithjwt.java:316) at <cust_app>.src.sys.apps.Usermgtbase.lambda$callService$11(Usermgtbase.java:212) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.functionBlock(BlockManager.java:9840) at com.goldencode.p2j.util.BlockManager.function(BlockManager.java:1105) at com.goldencode.p2j.util.BlockManager.function(BlockManager.java:1073) at <cust_app>.src.sys.apps.Usermgtbase.callService(Usermgtbase.java:179) at <cust_app>.src.sys.apps.Connecttoum.lambda$validateCredentials$75(Connecttoum.java:798) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.functionBlock(BlockManager.java:9840) at com.goldencode.p2j.util.BlockManager.function(BlockManager.java:1105) at com.goldencode.p2j.util.BlockManager.function(BlockManager.java:1073) at <cust_app>.src.sys.apps.Connecttoum.validateCredentials(Connecttoum.java:770) at <cust_app>.src.sys.apps.Sessioncontext.lambda$validateCredentials$84(Sessioncontext.java:2370) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.apps.Sessioncontext.validateCredentials(Sessioncontext.java:2360) at <cust_app>.src.sys.apps.SessioncontextMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.apps.Sessioncontext.lambda$logincore$239(Sessioncontext.java:4115) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.apps.Sessioncontext.logincore(Sessioncontext.java:4078) 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.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9550) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.apps.Sessioncontext.lambda$login$231(Sessioncontext.java:4045) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.apps.Sessioncontext.login(Sessioncontext.java:4043) 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.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9550) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.apps.Sessioncontext.lambda$loginClient$207(Sessioncontext.java:3786) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.apps.Sessioncontext.loginClient(Sessioncontext.java:3784) at <cust_app>.src.sys.apps.SessioncontextMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeInImpl(ControlFlowOps.java:6900) at com.goldencode.p2j.util.ControlFlowOps.invokeInWithMode(ControlFlowOps.java:1914) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1340) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.apps.Loginclient.lambda$execute$2(Loginclient.java:173) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:603) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:576) at <cust_app>.src.sys.apps.Loginclient.execute(Loginclient.java:124) at <cust_app>.src.sys.apps.LoginclientMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.Pdbconn.lambda$maakConnecties$13(Pdbconn.java:285) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.Pdbconn.maakConnecties(Pdbconn.java:270) at <cust_app>.src.sys.PdbconnMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeInImpl(ControlFlowOps.java:6900) at com.goldencode.p2j.util.ControlFlowOps.invokeInWithMode(ControlFlowOps.java:1914) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1340) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.UserLog.lambda$inloggen$33(UserLog.java:910) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:763) at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:740) at <cust_app>.src.sys.UserLog.inloggen(UserLog.java:904) at <cust_app>.src.sys.UserLogMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.sys.UserLog$2.body(UserLog.java:516) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.Trigger.run(Trigger.java:317) at com.goldencode.p2j.ui.LogicalTerminal.lambda$trigger$7(LogicalTerminal.java:11732) at com.goldencode.p2j.ui.LogicalTerminal.invokeOnServer(LogicalTerminal.java:18849) at com.goldencode.p2j.ui.LogicalTerminal.trigger(LogicalTerminal.java:11732) at com.goldencode.p2j.ui.LogicalTerminalMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:156) at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:788) at com.goldencode.p2j.net.Conversation.block(Conversation.java:422) at com.goldencode.p2j.net.Conversation.waitMessage(Conversation.java:348) at com.goldencode.p2j.net.Queue.transactImpl(Queue.java:1222) at com.goldencode.p2j.net.Queue.transact(Queue.java:683) at com.goldencode.p2j.net.BaseSession.transact(BaseSession.java:273) at com.goldencode.p2j.net.HighLevelObject.transact(HighLevelObject.java:221) at com.goldencode.p2j.net.RemoteObject$RemoteAccess.invokeCore(RemoteObject.java:1466) at com.goldencode.p2j.net.InvocationStub.invoke(InvocationStub.java:144) at jdk.proxy2/jdk.proxy2.$Proxy28.waitFor(Unknown Source) at com.goldencode.p2j.ui.LogicalTerminal.waitFor(LogicalTerminal.java:7239) at com.goldencode.p2j.ui.LogicalTerminal.waitFor(LogicalTerminal.java:7001) at <cust_app>.src.sys.UserLog.lambda$execute$17(UserLog.java:648) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.doBlockWorker(BlockManager.java:10411) at com.goldencode.p2j.util.BlockManager.doBlock(BlockManager.java:1549) at <cust_app>.src.sys.UserLog.lambda$execute$18(UserLog.java:617) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:603) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:576) at <cust_app>.src.sys.UserLog.execute(UserLog.java:297) at <cust_app>.src.sys.UserLogMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9545) at com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invoke(ControlFlowOps.java:9501) at com.goldencode.p2j.util.ControlFlowOps.lambda$invokeImpl$11(ControlFlowOps.java:7460) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7475) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:4512) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:7041) at com.goldencode.p2j.util.ControlFlowOps.invokeImpl(ControlFlowOps.java:6944) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1391) at com.goldencode.p2j.util.ControlFlowOps.invokeWithMode(ControlFlowOps.java:1373) at com.goldencode.p2j.util.ControlFlowOps.invoke(ControlFlowOps.java:1321) at com.goldencode.p2j.util.InvokeConfig.run(InvokeConfig.java:426) at <cust_app>.src.root.Startmtc.lambda$execute$1(Startmtc.java:219) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.doBlockWorker(BlockManager.java:10411) at com.goldencode.p2j.util.BlockManager.doBlock(BlockManager.java:1549) at <cust_app>.src.root.Startmtc.lambda$execute$3(Startmtc.java:156) at com.goldencode.p2j.util.Block.body(Block.java:636) at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:9204) at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:8825) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:603) at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:576) at <cust_app>.src.root.Startmtc.execute(Startmtc.java:122) 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.goldencode.p2j.util.Utils.invoke(Utils.java:1774) at com.goldencode.p2j.main.StandardServer$MainInvoker.execute(StandardServer.java:2795) at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:2067) at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1989) at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:676) at com.goldencode.p2j.main.StandardServerMethodAccess.invoke(Unknown Source) at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:156) at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:788) at com.goldencode.p2j.net.Conversation.block(Conversation.java:422) at com.goldencode.p2j.net.Conversation.run(Conversation.java:235) at java.base/java.lang.Thread.run(Thread.java:842) ...
I do not exactly know what it means. Probably conversion issue. Or missed external jars (some jetty for example). If someone can clarify it would be great.
#147 Updated by Constantin Asofiei 2 months ago
From Tomasz via email:
You need to add -Djava.locale.providers=SPI,CLDR,COMPAT instead of and put fwdcpi.jar on a classpath, the same way as for Java 11
e.g. like this (fwdcpi.jar is put into right place by build.xml):
if [ -z $JAVA_11_SPI ] ; then prog_result=$(${prog} -classpath ${cpath} com.goldencode.util.PrintSystemProp java.ext.dirs 2> /dev/null) spi="-Djava.locale.providers=SPI,JRE -Djava.ext.dirs=${prog_result}:../lib/spi" else spi="-Djava.locale.providers=SPI,CLDR,COMPAT" fi
#148 Updated by Eugenie Lyzenko 2 months ago
Also I've found Java doc issue:
... [ant:javadoc] Generating /mnt/md0/evl_raid0/p2j_6692a/dist/docs/api/com/goldencode/p2j/persist/dialect/MariaDbLenientDialect.html... [ant:javadoc] error: An internal exception has occurred. [ant:javadoc] (java.lang.IllegalStateException: ERRONEOUS) [ant:javadoc] Please file a bug against the javadoc tool via the Java bug reporting page [ant:javadoc] (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) [ant:javadoc] for duplicates. Include error messages and the following diagnostic in your report. Thank you. [ant:javadoc] java.lang.IllegalStateException: ERRONEOUS [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.seeTagToContent(HtmlDocletWriter.java:1019) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.TagletWriterImpl.seeTagOutput(TagletWriterImpl.java:318) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.SeeTaglet.getAllBlockTagOutput(SeeTaglet.java:82) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.TagletWriter.getBlockTagOutput(TagletWriter.java:288) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getBlockTagOutput(HtmlDocletWriter.java:365) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getBlockTagOutput(HtmlDocletWriter.java:351) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.addTagsInfo(HtmlDocletWriter.java:337) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.MethodWriterImpl.addTags(MethodWriterImpl.java:175) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MethodBuilder.buildTagInfo(MethodBuilder.java:190) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:128) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MethodBuilder.build(MethodBuilder.java:106) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:398) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildMemberDetails(ClassBuilder.java:346) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:149) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.build(ClassBuilder.java:113) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:376) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:286) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:199) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:212) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:115) [ant:javadoc] at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:103) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:556) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:393) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:342) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) [ant:javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) [ant:javadoc] 1 error [ant:javadoc] 50 warnings ...
Is it a known issue?
#149 Updated by Tomasz Domin 2 months ago
Tomasz Domin wrote:
- test customer applications for regression - the most important applications - I guess we need a subtask for each application:
- test each application on branch
6692a
with Java 8- test each application on branch
6692a
with Java 17
A remark - I don't think any of customer application would be ready for Java 17 right away - they most probably need migration (mainly due to java.lang.Record
and com.goldencode.p2j.persist.Record;
name conflict).
They also need SPI
migration if application were never migrated to Java 11.
- testing
Java 8
with internal apps: Hotel applications and regression testing - to check if dependencies upgrades didnt break them - testing customer applications with
6692a
andJava 8
- to make sure dependencies upgrades didn't break the apps. - testing
Java 17
with internal apps: Hotel applications and regression testing (mostly done - needs to be redone) - merge
6692a
totrunk
- so dependencies got updated and there is possibility to switch to Java 17 - migrate selected customer application to
Java 17
- they should work in Java 8 mode without any changes, Java 17 most like will need migration.
#150 Updated by Greg Shah 2 months ago
A remark - I don't think any of customer application would be ready for Java 17 right away - they most probably need migration (mainly due to
java.lang.Record
andcom.goldencode.p2j.persist.Record;
name conflict).
Are you saying code changes are needed? I don't think we expose com.goldencode.p2j.persist.Record
in converted code.
Eric: You never responded to Tomasz' note about this conflict in #6692-10.
An explicit import will work throughout FWD. As long as this class is not exposed to converted code, then it isn't an issue.
They also need
SPI
migration if application were never migrated to Java 11.
Isn't this just ensuring that the latest server.sh is used? What else is needed?
migrate selected customer application to
Java 17
- they should work in Java 8 mode without any changes, Java 17 most like will need migration.
What migration is needed, except for the above Record and SPI issues?
#151 Updated by Eugenie Lyzenko 2 months ago
Tomasz Domin wrote:
Tomasz Domin wrote:
- test customer applications for regression - the most important applications - I guess we need a subtask for each application:
- test each application on branch
6692a
with Java 8- test each application on branch
6692a
with Java 17
I think this is critical to merge or not the 6692a
to trunk.
At this time using Java 17 makes GUI application unusable. The conversion seems OK but runtime - certainly no. It is a complex application and I can not even estimate what conflicts with Java 17(and what time needs to resolve). The reflection feature is the first that is coming to my mind.
#153 Updated by Tomasz Domin 2 months ago
Greg Shah wrote:
Are you saying code changes are needed? I don't think we expose
com.goldencode.p2j.persist.Record
in converted code.
Correct, code changes are needed. com.goldencode.p2j.persist.Record
is not part of converted code, but it may be part of a customer application, like it is for regression tests.
Eric: You never responded to Tomasz' note about this conflict in #6692-10.
An explicit import will work throughout FWD. As long as this class is not exposed to converted code, then it isn't an issue.
I was concerned about that as I guess import violates code formatting rules, Java Import Statements
section ;)
They also need
SPI
migration if application were never migrated to Java 11.Isn't this just ensuring that the latest server.sh is used? What else is needed?
Yes, it is, but not all customer projects switched to latest server.sh
(see Constantin's errors)
migrate selected customer application to
Java 17
- they should work in Java 8 mode without any changes, Java 17 most like will need migration.What migration is needed, except for the above Record and SPI issues?
I know only of those two issues plus sometimes opening API is needed (like in CA's project)
I guess its wording issue - maybe I should use a different word than migration.
#154 Updated by Eugenie Lyzenko 2 months ago
Tomasz Domin wrote:
Greg Shah wrote:
Are you saying code changes are needed? I don't think we expose
com.goldencode.p2j.persist.Record
in converted code.Correct, code changes are needed.
com.goldencode.p2j.persist.Record
is not part of converted code, but it may be part of a customer application, like it is for regression tests.Eric: You never responded to Tomasz' note about this conflict in #6692-10.
An explicit import will work throughout FWD. As long as this class is not exposed to converted code, then it isn't an issue.
I was concerned about that as I guess import violates code formatting rules,
Java Import Statements
section ;)They also need
SPI
migration if application were never migrated to Java 11.Isn't this just ensuring that the latest server.sh is used? What else is needed?
Yes, it is, but not all customer projects switched to latest
server.sh
(see Constantin's errors)migrate selected customer application to
Java 17
- they should work in Java 8 mode without any changes, Java 17 most like will need migration.What migration is needed, except for the above Record and SPI issues?
I know only of those two issues plus sometimes opening API is needed (like in CA's project)
I guess its wording issue - maybe I should use a different word than migration.
The other points are for every specific project:
1. Making build.gradle
fully compatible for every projects to use with Java 17.
2. server.sh
is need to be changed to resolve reflection issues.
3. install_spawner.sh
is need to be changed/updated to work with Java 17.
4. The build.xml
should be made tolerant with Java 17 mandatory output like "Picking _JAVA_OPTONS ...". FWD
version string building is now affected.
5. The Javadoc issue (#6692-148) should be fixed.
#155 Updated by Greg Shah 2 months ago
Are you saying code changes are needed? I don't think we expose
com.goldencode.p2j.persist.Record
in converted code.Correct, code changes are needed.
com.goldencode.p2j.persist.Record
is not part of converted code, but it may be part of a customer application, like it is for regression tests.
Are you talking about the ChUI Regression tests? Do we use com.goldencode.p2j.persist.Record
directly in that customer code?
That usage is unexpected and should not be widespread.
Eric: Am I wrong?
I was concerned about that as I guess import violates code formatting rules,
The rules explicitly say that they can be used when there are conflicts.
#156 Updated by Eric Faulhaber about 2 months ago
Greg Shah wrote:
A remark - I don't think any of customer application would be ready for Java 17 right away - they most probably need migration (mainly due to
java.lang.Record
andcom.goldencode.p2j.persist.Record;
name conflict).Are you saying code changes are needed? I don't think we expose
com.goldencode.p2j.persist.Record
in converted code.Eric: You never responded to Tomasz' note about this conflict in #6692-10.
I agree with your choice: explicitly import com.goldencode.p2j.persist.Record
where needed in the FWD runtime.
An explicit import will work throughout FWD. As long as this class is not exposed to converted code, then it isn't an issue.
It is the direct base class of all generated, persistent DMOs, but since we don't emit source for the implementation classes, we don't need to worry about the import.
The only other concern would be hand-written Java business logic which references Record
directly.
#157 Updated by Tomasz Domin about 2 months ago
I have just pushed 6692a/15188
with following updates:
- Support for versioned JS dependencies in
ReportWebServer
(shared with Embedded mode) - Downgrade
args4j
to java 8 compatible version - revert
fwd_sdk.js
totrunk
version - Dependencies upgrade, switch back to jetty-all uber jar refs
The version is tested with Java 8 and Java 17 with slightly updated Hotel GUI application:
- embedded mode (needs a small patch due to changes JS dependencies are referred now)
- virtual desktop
- swing client
- PDF generation (invoice generation)
- administration console
- reporting server (needs a small patch due to changes JS dependencies are referred now)
Next steps:
- updating documentation Switching_Between_Java_8_and_Java_11 - mostly done
- cleaning javadoc warnings and errors
- regression testing with the last fully working 6667i branch
- testing customer applications with Java 8
Optional steps (only for applications that need Java 17):
- update customer applications to support Java 17
- testing customer applications with Java 17
#158 Updated by Tomasz Domin about 2 months ago
Tomasz Domin wrote:
I have just pushed
6692a/15188
with following updates:Next steps:
- updating documentation Switching_Between_Java_8_and_Java_11 - mostly done
Created and updated Switching_Between_Java_8_and_Java_11_or_Java_17. Note that Java 11 upgrade is a step on upgrading to Java 17.
- cleaning javadoc warnings and errors
Working on it.
- regression testing with the last fully working 6667i branch
Regression tests for branch 6692a/15280 based on 6667i/15249 based on trunk/15157 passed successfully.
Note that 6692a/15280
is the same 6692a/15188
rebased on 6667i/15249, rebasing was needed for regression testing (before 6667i is merged to trunk).
For Java 8:
java_8_xfer_6692a_15280_6667i_15249_6692a_trunk_15157_ctrlc-20240508184558
java_8_xfer_6692a_15280_6667i_15249_6692a_trunk_15157_main-20240508184442
java_8_xfer_6692a_15280_6667i_15249_6692a_trunk_15157_main-20240508184552
For Java 17:
java_17_xfer_6692a_15280_6667i_15249_6692a_trunk_15157_main-20240508214327
java_17_xfer_6692a_15280_6667i_15249_6692a_trunk_15157_ctrlc-20240508214400
- testing customer applications with Java 8
Working on testing customer application with Java 8 and Java 17.
#159 Updated by Tomasz Domin about 2 months ago
I had some issues with FWD build.gradle
as it is using javascript
which is no longer available in JVM since JDK15
Initially I ignored the problem, as using gradle
when using it as a frontend everything works, until I've found that customers are using ant
frontend e.g. to install spawner
.
I replaced user properties mapping javascript
function with ant
a tricky native code, but there is one script more to replace in retrieve-version
target. I guess all scripting like processing should be moved to build.gradle
, shouldn't it ?
Additionally - in upgraded gradle
version its not possible to elevate privileges in subshell with sudo
as there is no access to terminal anymore, so postinstall.sh
needs to be called from install_spawner.sh
and not from ant
or gradle
. postinstall
will still work when called from build.gradle
or build.xml
unless it requires elevated priviledges.
I guess that was already planned to be changed as hotel_gui
has already that change implemented.
#160 Updated by Roger Borrello about 2 months ago
Tomasz Domin wrote:
I guess that was already planned to be changed as
hotel_gui
has already that change implemented.
Creating the Docker images brought on the requirement that install_spawner.sh
and import should be able to be performed without requiring a build environment (notably ant
) be available. Hence the update as shown in hotel_gui
. Other projects that are using Docker (at least one of them) also took on that tactic.
#161 Updated by Tomasz Domin about 2 months ago
Roger Borrello wrote:
Tomasz Domin wrote:
I guess that was already planned to be changed as
hotel_gui
has already that change implemented.Creating the Docker images brought on the requirement that
install_spawner.sh
and import should be able to be performed without requiring a build environment (notablyant
) be available. Hence the update as shown inhotel_gui
. Other projects that are using Docker (at least one of them) also took on that tactic.
The problem I have is I am getting "sudo: a terminal is required to read the password" when running postinstall.sh
from ant
which calls gradle
, which calls ant
back. I found you had that issue when working on dockers in #6214-35.
Directly calling ant ant-native -Dpost.build=yes
works, neither ./gradlew native -Dpost.build=yes
nor ant --Dpost.build=yes
I guess new gradle
disconnects ant subprocess from terminal console, thus sudo
in scripts cannot execute anymore.
#162 Updated by Roger Borrello about 2 months ago
Tomasz Domin wrote:
Roger Borrello wrote:
Tomasz Domin wrote:
I guess that was already planned to be changed as
hotel_gui
has already that change implemented.Creating the Docker images brought on the requirement that
install_spawner.sh
and import should be able to be performed without requiring a build environment (notablyant
) be available. Hence the update as shown inhotel_gui
. Other projects that are using Docker (at least one of them) also took on that tactic.The problem I have is I am getting "sudo: a terminal is required to read the password" when running
postinstall.sh
fromant
which callsgradle
, which callsant
back. I found you had that issue when working on dockers in #6214-35.Directly calling
ant ant-native -Dpost.build=yes
works, neither./gradlew native -Dpost.build=yes
norant --Dpost.build=yes
I guess newgradle
disconnects ant subprocess from terminal console, thussudo
in scripts cannot execute anymore.
Would it work if postbuild.sh
were added to sudoers
so a password weren't prompted for?
#163 Updated by Tijs Wickardt about 2 months ago
Roger Borrello wrote:
Tomasz Domin wrote:
Roger Borrello wrote:
Tomasz Domin wrote:
I guess that was already planned to be changed as
hotel_gui
has already that change implemented.Creating the Docker images brought on the requirement that
install_spawner.sh
and import should be able to be performed without requiring a build environment (notablyant
) be available. Hence the update as shown inhotel_gui
. Other projects that are using Docker (at least one of them) also took on that tactic.The problem I have is I am getting "sudo: a terminal is required to read the password" when running
postinstall.sh
fromant
which callsgradle
, which callsant
back. I found you had that issue when working on dockers in #6214-35.Directly calling
ant ant-native -Dpost.build=yes
works, neither./gradlew native -Dpost.build=yes
norant --Dpost.build=yes
I guess newgradle
disconnects ant subprocess from terminal console, thussudo
in scripts cannot execute anymore.Would it work if
postbuild.sh
were added tosudoers
so a password weren't prompted for?
Or !requiretty
(do not require a tty)
#164 Updated by Tomasz Domin about 2 months ago
I've pushed 6692a/15240
based on current trunk/15205
I guess which is ready for testing.
Please review commits 15226-15240, those are mainly dependencies changes and cleaning, also including CentralSlf4jProvider.
- conversion
- embedded mode
- virtual desktop
- swing client
- PDF generation (invoice generation) in web application
- administration console
- reporting server including callgraph
- OpenJDK Runtime Environment (build 1.8.0_402-8u402-ga-2ubuntu1~22.04-b06)
- OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
Customer application #8719 both in Java 8 and Java 17 - it seems to be working with some errors reported like in the pointed thread - I will check those errors later, as they dont stop application from running it seems.
I've updated the documentation - in the end I decided to document a switch from Java 8 to Java 17 and ignore Java 11 this time:
Switching_Between_Java_8_and_Java_17
For ones that are interested - please retest 6692a
branch with you customer application.
For each customer application please create a separate task like #8719 in the appropriate place (usually dedicated for given customer application) and link it here.
Please first start with testing with Java 8, it should work straightforward except there may be some changes needed for JS dependencies (read the docs ;))
There could be some issues due to dependencies updates, which result in changes in APIs or transitive dependencies missing.
Then try to port your application to Java 17 - please read the docs and remember keywords - clean deploy, SPI, spawner, Record type, API add-opens :)
I'll try to answers questions and issues today, as over next days I have a limited availability, so I will read emails after I am back on Monday.
#169 Updated by Greg Shah about 2 months ago
The final phase of testing for 6692a is starting now. When each of the following are resolved, we will merge to trunk.
- #8771 (CA)
- #8772 (CA)
- #8773 (CA)
- #8774 (ICP/AL2)
The specific testing is being done in separate tasks since each of these is a large customer application and we don't want to discuss customer details in this public task.
#170 Updated by Greg Shah about 2 months ago
In each of these testing processes, please use the details in Switching_Between_Java_8_and_Java_17 to migrate the application to 6692a. Then run testing in both Java 8 and Java 17. The code should be converted/compiled using the same Java release that is being tested at runtime.
Some of these applications use the FWD version of the "Java Open Client" (appserver access classes). This is a portion of FWD that can be used to make appserver calls to a remote FWD server. We should consider the question: do those classes need to be compiled in Java 17 when communicating with a FWD server that is running Java 17? We have a similar question related to proxy classes that may be used over this same mechanism.
#171 Updated by Greg Shah about 1 month ago
The converted code javac times (and heap requirements) as seen in #8773 and #8771, are something for which we need to find a resolution. Moving from 24G to 64G heap and still having 3x the compile time is not OK.
Perhaps we can figure out the cause using some thread dumps from javac?
Tomasz: Did this happen before you updated all the dependencies?
#172 Updated by Tomasz Domin about 1 month ago
Greg Shah wrote:
The converted code javac times (and heap requirements) as seen in #8773 and #8771, are something for which we need to find a resolution. Moving from 24G to 64G heap and still having 3x the compile time is not OK.
Perhaps we can figure out the cause using some thread dumps from javac?
Tomasz: Did this happen before you updated all the dependencies?
AFAIR It was happening from the first build of customer application in 6692a for Java 8.
I will investigate it further.
#173 Updated by Constantin Asofiei about 1 month ago
This change removes mime4j benchmark, which required jmh:
=== modified file 'build.gradle' --- old/build.gradle 2024-05-13 16:25:59 +0000 +++ new/build.gradle 2024-05-22 17:51:19 +0000 @@ -509,7 +509,9 @@ fwdClientServer group: 'org.apache.commons', name: 'commons-text', version: '1.11.0' fwdClientServer group: 'org.apache.axis2', name: 'axis2-kernel', version: '1.8.2' // upgrade apache-mime4j-core for axis2-kernel:1.8.2 - fwdClientServer group: 'org.apache.james', name: 'apache-mime4j-core', version: '0.8.11' + fwdClientServer (group: 'org.apache.james', name: 'apache-mime4j-core', version: '0.8.11') { + exclude group: 'org.apache.james', module: 'apache-mime4j-benchmark' + } fwdClientServer group: 'org.apache.ws.commons.axiom', name: 'axiom-api', version: '1.4.0' fwdClientServer group: 'org.apache.ws.commons.axiom', name: 'axiom-impl', version: '1.4.0' @@ -565,7 +567,9 @@ exclude group: 'bouncycastle' } fwdServer group: 'commons-io', name: 'commons-io', version: '2.15.1' - fwdServer group: 'org.apache.james', name: 'apache-mime4j', version: '0.8.9' + fwdServer (group: 'org.apache.james', name: 'apache-mime4j', version: '0.8.9') { + exclude group: 'org.apache.james', module: 'apache-mime4j-benchmark' + } fwdServer (group: 'org.apache.poi', name: 'poi', version: '5.2.5') { exclude group: 'org.apache.commons' }
These jars were removed with this change:
apache-mime4j-benchmark-0.8.9.jar commons-math3-3.2.jar hamcrest-core-1.3.jar jmh-core-1.35.jar jmh-generator-annprocess-1.35.jar jopt-simple-5.0.4.jar junit-4.13.2.jar
The gradle dependency listing shows that these are required only for mime4j benchmark, so I think we are OK to remove this.
For #8771 the compile time and heap usage is resolved.
#174 Updated by Greg Shah about 1 month ago
Please commit the change. Let's restart testing.
#175 Updated by Constantin Asofiei about 1 month ago
Greg Shah wrote:
Please commit the change. Let's restart testing.
Committed to 6692a rev 15241.
#176 Updated by Constantin Asofiei about 1 month ago
6692a rev 15242 - GenericWebServer now exposes all jetty-
jars to the .war launched app (fixes the JNDI problem).
#177 Updated by Tomasz Domin about 1 month ago
6692a rev 15243 - Restore dependencies: implicit for batik-ext
and explicit for slf4j-api
and jcl-over-slf4j
which have been removed when migrating to jetty-all
#178 Updated by Tomasz Domin about 1 month ago
6692a rev 15244 - Removed unneeded janusgraph
dependency: metrics-graphite
and transitive amqp-client
#179 Updated by Roger Borrello about 1 month ago
I have updated the container
project so that base images are created that contain JDK 17. After a complete build of the base images with build_base_ubuntu.sh -p
the goldencode repository contains:
REPOSITORY TAG IMAGE ID CREATED SIZE goldencode/base_ubuntu_22.04 jdk17_latest 19f977f19cc5 About an hour ago 1.6GB goldencode/base_ubuntu_22.04 jdk8_latest b8159b58870d 3 weeks ago 1.48GB goldencode/base_ubuntu_22.04 latest b8159b58870d 3 weeks ago 1.48GB goldencode/base_ubuntu_22.04_pg14 jdk17_latest 272729a5da22 23 minutes ago 2.41GB goldencode/base_ubuntu_22.04_pg14 jdk8_latest 2673c22aa02c 3 weeks ago 2.29GB goldencode/base_ubuntu_22.04_pg14 latest 2673c22aa02c 3 weeks ago 2.29GB
The latest
tags are still the jdk8 version, for now.
I will get to the FWD images sometime. For those I will add an option to indicate which JDK to use for the image build, which will drive the image tag that is created. Is there a preference to the repository name containing the jdk used, or the tag?
This: fwd_4.0_ubuntu_22.04_pg14_jdk17:trunk_15258
and fwd_4.0_ubuntu_22.04_jdk17:latest
Or: fwd_4.0_ubuntu_22.04_pg14:jdk17_trunk_15258
and fwd_4.0_ubuntu_22.04:jdk17_latest
and the :latest
would be the JDK 8 version for now.
The latter would better lend itself to the usage of :latest
which is typical for tagging the most reliable version.
#180 Updated by Tomasz Domin about 1 month ago
6692a rev 15244 - Reverted mariadb-java-client
to FWD
compatible version: "3.1.2"
Greg - please let me know when you think its time to rebase 6692a
to latest trunk
, I think there are some tests still in progress, but I think its about now :)
#181 Updated by Greg Shah about 1 month ago
Tomasz Domin wrote:
6692a rev 15244 - Reverted
mariadb-java-client
toFWD
compatible version: "3.1.2"Greg - please let me know when you think its time to rebase
6692a
to latesttrunk
, I think there are some tests still in progress, but I think its about now :)
All the testing from #6692-169 has passed (with some conditions). We are finalizing the application-specific migration documentation but otherwise are ready to move ahead.
Please do rebase 6692a now. The only testing that is open is #8719, which I'd really like to complete today so we can merge this week.
#182 Updated by Tomasz Domin about 1 month ago
Roger Borrello wrote:
I have updated the
container
project so that base images are created that contain JDK 17. After a complete build of the base images withbuild_base_ubuntu.sh -p
the goldencode repository contains:This:
fwd_4.0_ubuntu_22.04_pg14_jdk17:trunk_15258
andfwd_4.0_ubuntu_22.04_jdk17:latest
This is my preference assuming the most variable part of the image is FWD :)
I'd also remove trunk
part leaving only number like fwd_4.0_ubuntu_22.04_pg14_jdk17:15258
assuming it will apply to trunk
build by default.
In addition we need to think if fwd_4.0
part should be renamed to plain FWD
and 4.0
should become a tag like fwd_ubuntu_22.04_pg14_jdk17:4.0
once we switch to versioning numbers instead of trunk revisions (if it is planned at all). It may be even something like this fwd_ubuntu_22.04_pg14_jdk17:4.0.15258
when putting trunk revision as a version revision.
#183 Updated by Tomasz Domin about 1 month ago
Rebased to current trunk/15259
Pushed 6692a/15299
#184 Updated by Greg Shah about 1 month ago
- Status changed from Internal Test to Merge Pending
OK, all the applications have reached a minimum level of support for 6692a.
Please merge 6692a to trunk, after 8125c. In the notice, please link to the migration instructions AND add specific linkages to the Redmine task (and note) that documents each of the application's steps for migration. We will have to share those with each customer.
#185 Updated by Tomasz Domin 30 days ago
Rebased to current trunk/15264
Pushed with overwrite 6692a/15304
Preparing to merge to trunk.
#186 Updated by Tomasz Domin 30 days ago
Merged into trunk revision 15265.
#188 Updated by Tomasz Domin 30 days ago
Pushed hotel_gui
revision 326 updated to support Java 17.
#192 Updated by Roger Borrello 28 days ago
Tomasz Domin wrote:
Roger Borrello wrote:
I have updated the
container
project so that base images are created that contain JDK 17. After a complete build of the base images withbuild_base_ubuntu.sh -p
the goldencode repository contains:This:
fwd_4.0_ubuntu_22.04_pg14_jdk17:trunk_15258
andfwd_4.0_ubuntu_22.04_jdk17:latest
This is my preference assuming the most variable part of the image is FWD :)
I'd also removetrunk
part leaving only number likefwd_4.0_ubuntu_22.04_pg14_jdk17:15258
assuming it will apply totrunk
build by default.
In addition we need to think iffwd_4.0
part should be renamed to plainFWD
and4.0
should become a tag likefwd_ubuntu_22.04_pg14_jdk17:4.0
once we switch to versioning numbers instead of trunk revisions (if it is planned at all). It may be even something like thisfwd_ubuntu_22.04_pg14_jdk17:4.0.15258
when putting trunk revision as a version revision.
I really tried to get the base_ubuntu_22.04
image to be versatile enough to simply receive a -e JDK_VERSION=17
to get the container utilizing the base image to "self-direct" the default JVM so that a single image would be all that was needed. In the end, it was just not working to try to get the non-interactive shell that is used when you start a container to be able to run the /usr/local/bin/switch-java.sh
script I had created:
#!/bin/bash if [ "$JDK_VERSION" == "17" ]; then update-alternatives --quiet --set java /usr/lib/jvm/java-17-openjdk-amd64/bin/java update-alternatives --quiet --set javac /usr/lib/jvm/java-17-openjdk-amd64/bin/javac # configure JNI linking - https://proj.goldencode.com/projects/p2j/wiki/Configure_JNI_Linking [ -L "/usr/lib/libjvm.so" ] && rm /usr/lib/libjvm.so ln -s /usr/lib/jvm/java-17-openjdk-amd64/lib/server/libjvm.so /usr/lib/libjvm.so echo "Setup JDK 17" > /tmp/switch-java.log else update-alternatives --quiet --set java /usr/lib/jvm/java-8-openjdk-amd64/bin/java update-alternatives --quiet --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac # configure JNI linking - https://proj.goldencode.com/projects/p2j/wiki/Configure_JNI_Linking [ -L "/usr/lib/libjvm.so" ] && rm /usr/lib/libjvm.so ln -s /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so echo "Setup JDK 8" > /tmp/switch-java.log fi
I added invocation of it (with the appropriate update to
sudoers.d
so the script could run sudo) to the /root/.bashrc
, and the /etc/skel/.bashrc
scripts, so that sourcing would setup the correct JDK. But things like sh -c "my_command"
being passed on the command-line to the container wouldn't work in that configuration. In the end, I created the base images with JDK 8 as the default, and the current image names, and JDK 17 with _jdk17
appended to the end of the image name.
I updated the wiki with all the updates.
I didn't change any of the other naming schemes, at this point. I do like them, but until we have a definitive plan for revisions, let's leave it alone.
#193 Updated by Roger Borrello 28 days ago
Here is the current list:
REPOSITORY TAG IMAGE ID CREATED SIZE goldencode/fwd_4.0_ubuntu_22.04_pg14 latest 491de70050f5 5 hours ago 6.15GB goldencode/fwd_4.0_ubuntu_22.04_pg14 trunk_15269 491de70050f5 5 hours ago 6.15GB fwd_4.0_ubuntu_22.04_pg14 latest 491de70050f5 5 hours ago 6.15GB fwd_4.0_ubuntu_22.04_pg14 trunk_15269 491de70050f5 5 hours ago 6.15GB goldencode/fwd_4.0_ubuntu_22.04 latest e6510028646e 5 hours ago 5.34GB goldencode/fwd_4.0_ubuntu_22.04 trunk_15269 e6510028646e 5 hours ago 5.34GB fwd_4.0_ubuntu_22.04 latest e6510028646e 5 hours ago 5.34GB fwd_4.0_ubuntu_22.04 trunk_15269 e6510028646e 5 hours ago 5.34GB goldencode/fwd_4.0_ubuntu_22.04_pg14_jdk17 latest 086675f32c3f 5 hours ago 6.19GB goldencode/fwd_4.0_ubuntu_22.04_pg14_jdk17 trunk_15269 086675f32c3f 5 hours ago 6.19GB fwd_4.0_ubuntu_22.04_pg14_jdk17 latest 086675f32c3f 5 hours ago 6.19GB fwd_4.0_ubuntu_22.04_pg14_jdk17 trunk_15269 086675f32c3f 5 hours ago 6.19GB goldencode/fwd_4.0_ubuntu_22.04_jdk17 latest 0fdc08910d4b 5 hours ago 5.38GB goldencode/fwd_4.0_ubuntu_22.04_jdk17 trunk_15269 0fdc08910d4b 5 hours ago 5.38GB fwd_4.0_ubuntu_22.04_jdk17 latest 0fdc08910d4b 5 hours ago 5.38GB fwd_4.0_ubuntu_22.04_jdk17 trunk_15269 0fdc08910d4b 5 hours ago 5.38GB goldencode/base_ubuntu_22.04_pg14_jdk17 latest cdd7b21370e5 7 hours ago 2.64GB base_ubuntu_22.04_pg14_jdk17 latest cdd7b21370e5 7 hours ago 2.64GB base_ubuntu_22.04_pg14 latest 1c6de0a3e351 7 hours ago 2.64GB goldencode/base_ubuntu_22.04_pg14 latest 1c6de0a3e351 7 hours ago 2.64GB goldencode/base_ubuntu_22.04_jdk17 latest 62dcb4cb6465 7 hours ago 1.83GB base_ubuntu_22.04_jdk17 latest 62dcb4cb6465 7 hours ago 1.83GB goldencode/base_ubuntu_22.04 latest 6e4177640a3c 7 hours ago 1.83GB base_ubuntu_22.04 latest 6e4177640a3c 7 hours ago 1.83GB
#194 Updated by Roger Borrello 22 days ago
I plan on updating the standard workstation build to have both Java's in the same manner as I have currently setup for Docker images. The script that is used in Docker (switch-java.sh
which relies upon the JDK_VERSION
environment variable will also be used to control which is the default java on the workstation.
Right now the standard Java is 8, so if JDK_VERSION
isn't set, that is what becomes the default Java. I can switch this at any time where we decide to leave Java 8 behind.
If there are any objections, we can discuss.