FWD » Core Development » Runtime Infrastructure

Once #9625 is complete, we can drop support for Java 8 and Java 11. Among other things, this will mean that dependencies like Jetty which are currently stuck on a back level version (9.x) would move to the latest version.

Tomasz: Please estimate the size of the work needed to migrate to the latest Jetty and other dependencies.

Greg Shah wrote:

Tomasz: Please estimate the size of the work needed to migrate to the latest Jetty and other dependencies.

From the task context I presume its about migrating from Jetty 9.4.54 to version Jetty 12.0.x (including dependencies), which requires at least Java 17 runtime.

Yes, we need to also update other dependencies (for example, see the list in #9674). The Jetty issue is the biggest one.

I've started upgrading dependencies to get rid of old and vulnerable libraries and I've encountered a problem that may be a blocker - org.gwtproject:gwt-user:2.12.2 which is used to compile admin console requires jetty 9, due to API differences I don't think that would work with Jetty 12.0.x. Its needed for GWT compilation, not sure if its needed for runtime, checking by removing gwtCompile group from fwdAllCompile.

I've started work on porting services to Jetty 12 API. There are differences requiring attention, it will take me 2-3 days to finish.
In order to minimize changes I've stayed with AbstractHandler despite its deprecated, as moving to a different Handler would need more time. I've also stayed with synchronous API. I will try to switch to async processing some critical elements (like rest API) if there is spare time or in a separate ticket.

My work estimation is: finish porting services to Jetty 12 API this week and next week start testing, which would take another working week.

Greg, are there any specific tests to run for the following components exposed over HTTP or WebSockets ?:
- admin management and tenant management
- web authentication
- soap
- rest
- web driver
- reports
- POJO websockets

Constantin: Please comment on this plan. Do we need to shift to the asynch approach?

Tomasz Domin wrote:

In order to minimize changes I've stayed with AbstractHandler despite its deprecated, as moving to a different Handler would need more time. I've also stayed with synchronous API. I will try to switch to async processing some critical elements (like rest API) if there is spare time or in a separate ticket.

Please send some documentation what you mean about the async processing, how that works in Jetty 12. I'm not familiar with it.

Greg, are there any specific tests to run for the following components exposed over HTTP or WebSockets ?:
- admin management and tenant management
- web authentication

These need to be tested manually - see Session_Management_API and Multi-Tenancy

- soap
- rest

I'll provide a standalone project for this, including web handler.

- web driver

This is just the GUI/ChUI web clients. There is also the embedded mode which should be checked. All are supported in Hotel GUI or ChUI.

- reports

This is FWD analytics.

- POJO websockets

What do you mean here?

We have on pipeline the webspeed #6506 and #7080 work. Webspeed is more advanced than #7080.

Constantin Asofiei wrote:

Tomasz Domin wrote:

In order to minimize changes I've stayed with AbstractHandler despite its deprecated, as moving to a different Handler would need more time. I've also stayed with synchronous API. I will try to switch to async processing some critical elements (like rest API) if there is spare time or in a separate ticket.

Please send some documentation what you mean about the async processing, how that works in Jetty 12. I'm not familiar with it.

See : https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/Request.Handler.html#handle(org.eclipse.jetty.server.Request,org.eclipse.jetty.server.Response,org.eclipse.jetty.util.Callback)

The idea is not to block Jetty request processing logic with long lasting business logic operations - usually IO ops or external calls. In Jetty 12 once request is processed control is returned to server and business logic is to be handled by a separate thread allowing Jetty server request processing resources to be used more effectively. After business logic is done it returns control back to Jetty by calling callback provided. In addition Jetty provides support for some async IO operations with Content.Source, Content.Sink and Content.Chunk.
Its also possible to not to use async processing by simply calling callback at the end of handle, as it is done now in most (if not all) current FWD handlers.

- POJO websockets

What do you mean here?

I mean PojoWebSocketHandler.

We have on pipeline the webspeed #6506 and #7080 work. Webspeed is more advanced than #7080.

Those would require additional porting to Jetty 12, as I presume they are build on Jetty 9 API.

Tomasz Domin wrote:

See : https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/Request.Handler.html#handle(org.eclipse.jetty.server.Request,org.eclipse.jetty.server.Response,org.eclipse.jetty.util.Callback)

Current implementation of the rest/soap/web handlers in FWD requires direct access to HttpServletResponse, HttpServletRequest and target - is it still possible to get these from the version 12 handlers? Because otherwise it will require some major rework for them.

Otherwise, as long as 'async' still means that the request (on the caller) is 'sync' (the caller receives the response only when the request is complete), then I'm OK.

- POJO websockets

What do you mean here?

I mean PojoWebSocketHandler.

OK, this is part of the web spawner mechanism - can be tested easily.

We have on pipeline the webspeed #6506 and #7080 work. Webspeed is more advanced than #7080.

Those would require additional porting to Jetty 12, as I presume they are build on Jetty 9 API.

Yes, that work is on Jetty 9.

Constantin Asofiei wrote:

Tomasz Domin wrote:

See : https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/Request.Handler.html#handle(org.eclipse.jetty.server.Request,org.eclipse.jetty.server.Response,org.eclipse.jetty.util.Callback)

Current implementation of the rest/soap/web handlers in FWD requires direct access to HttpServletResponse, HttpServletRequest and target - is it still possible to get these from the version 12 handlers? Because otherwise it will require some major rework for them.

There is no access to ServletAPI in Handler anymore and I am doing the rework here :) mainly using https://jetty.org/docs/jetty/12/programming-guide/migration/11-to-12.html

Hynek
I have problems porting SpreadsheetWebApp from Jetty 9 to Jetty 12, as some kind of internal API was used (protected variables ?).
I can see a goal, but I am now sure if I understand it :) Is it described in a task maybe ?

Tomasz Domin wrote:

Hynek
I have problems porting SpreadsheetWebApp from Jetty 9 to Jetty 12, as some kind of internal API was used (protected variables ?).
I can see a goal, but I am now sure if I understand it :) Is it described in a task maybe ?

Yes, there are multiple cases where a non-public field/method is referenced in SheetControllerImpl. These solve some limitations of the Keikai's API classes. These will need to be replaced with MethodHandles I suppose.

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek
I have problems porting SpreadsheetWebApp from Jetty 9 to Jetty 12, as some kind of internal API was used (protected variables ?).
I can see a goal, but I am now sure if I understand it :) Is it described in a task maybe ?

Yes, there are multiple cases where a non-public field/method is referenced in SheetControllerImpl. These solve some limitations of the Keikai's API classes. These will need to be replaced with MethodHandles I suppose.

I guess so as well. Is there a related task I can dig some more information about those cases ?

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek
I have problems porting SpreadsheetWebApp from Jetty 9 to Jetty 12, as some kind of internal API was used (protected variables ?).
I can see a goal, but I am now sure if I understand it :) Is it described in a task maybe ?

Yes, there are multiple cases where a non-public field/method is referenced in SheetControllerImpl. These solve some limitations of the Keikai's API classes. These will need to be replaced with MethodHandles I suppose.

I guess so as well. Is there a related task I can dig some more information about those cases ?

I don't think these were added as separate tasks. They were added with the general implementation of Keikai support. You may check bzr blame to get to the actual issues, but I don't think you will find anything useful. I don't think you need to dick deeper anyway. Replacing the four or so occurrences and checking they still work should be trivial. I can take it.

Tomasz Domin wrote:

E.g. FWD API is making use of javax.http.* classes in SsoAuthenticator, so it relies on lower layer being servlets or old Jetty. For Jetty 12 javax.servlets classes are not in use anymore and old API is not used anymore there.

I've kept old SsoAuthenticator assuming javax.servlet.http.Cookie can be used as part of FWD SSO API by implementing conversion from/to org.eclipse.jetty.http.HttpCookie to/from javax.servlet.http.Cookie, so no changes to application will be required (hoteGUI compiles succesfully).

Regarding Jetty upgrade to version 12 there are three main types of Jetty services to upgrade:
- Jetty HTTP Handlers (SessionHandler, TenantHandler,EmbeddedWebHandler/VirtualDesktopWebHandler/WebDriverHandler, LegacyServiceHandler/RestHandler/SoapHandler, , WebAuthHandler, WebServiceHandler, ReportWebServer/DojoToolkitHandler, AuthHandler, DocumentOutputHandler,OpenResourceHandler, UploadHandler, HtmlResourceHandler, WebResourceHandler)
- Java EE Webapps (SpreadsheetWebApp)
- Jetty Websockets Handlers (ReportProtocol, GuiWebSocket, StorageMessagingWebSocket)

There are also a few types of web servers: ReportWebServer, EmbeddedWebServer, ManagedWebServer.

I've updated all of them to Jetty 12 API and Jetty 12 EE8 API replacing code and trying to make native Jetty 12 async/non-blocking) processing more synchronized (blocking) as it was before in order to leave application logic unchanged.
Now I need to test them one by one and make required corrections to make them work as before. I will report my progress for each of the services.

Greg
What about support for modules #9626 ? I guess this can be added here as well ? Or is it a next step ?

Tomasz Domin wrote:

Once I am done with initial testing I will ask for support regarding integration testing for specific cases and apps.

There is one more to be tested - support for customer WebApplication with "GenericWebServer.initializeWebApp"

Tomasz, do you have any pending changes not checked in? I need to do some Spreadsheet performance tests for #9828 with more recent Java.

Tomasz Domin wrote:

Greg
What about support for modules #9626 ? I guess this can be added here as well ? Or is it a next step ?

Not now. Modules can be a next step. We need to get the dependencies updated ASAP due to customer deadlines, the rest can wait.

Hynek Cihlar wrote:

Tomasz, do you have any pending changes not checked in? I need to do some Spreadsheet performance tests for #9828 with more recent Java.

Do you mean you need to test it Java 17 ? Just use trunk version and Java 17.

If you need Jetty updated to version 12 - spreadsheet has not been tested with 9687a branch yet, I just did initial migration. You may take it over and complete development if you wish, as Spreadsheet is the only FWD web service based on EE8 it needs to be looked over. Note code is not cleaned nor documented yet as 9687a consist mainly of daily working commits.

Tomasz Domin wrote:

Tomasz Domin wrote:
I've updated reporting server for a new Jetty12 WebSockets semantics. It seems to be working to the same extent as in hotel_gui, as when starting report.sh I am getting the same error when running hotel_gui with trunk:

[...]

It was my mistake. After running ant report_server for hotel_gui report server works correctly.

Do you anticipate any need for the customer to run conversion with this branch (assuming they have already run conversion on whatever trunk revision this branch is based on)?

Greg Shah wrote:

Do you anticipate any need for the customer to run conversion with this branch (assuming they have already run conversion on whatever trunk revision this branch is based on)?

There are no conversion changes and FWD business logic is also unchanged so there will be no need for additional conversion.
I am thinking about cases where there are is some converted code with a direct java call calls to FWD APIs , but its even hard for me to imagine such a case.

Hynek Cihlar wrote:

I don't think these were added as separate tasks. They were added with the general implementation of Keikai support. You may check bzr blame to get to the actual issues, but I don't think you will find anything useful. I don't think you need to dick deeper anyway. Replacing the four or so occurrences and checking they still work should be trivial. I can take it.

Hynek
I've upgraded sheet webapp/project for Jetty 12, it now deploys and starts fine with 9687a/15778. If you could help me with restoring Keikai support in SpreadsheetWebApp I'd appreciate it, please confirm if you would :), as I will work on something else and will come back to this if you dont fix it.

Tomasz Domin wrote:

Hynek Cihlar wrote:

I don't think these were added as separate tasks. They were added with the general implementation of Keikai support. You may check bzr blame to get to the actual issues, but I don't think you will find anything useful. I don't think you need to dick deeper anyway. Replacing the four or so occurrences and checking they still work should be trivial. I can take it.

Hynek
I've upgraded sheet webapp/project for Jetty 12, it now deploys and starts fine with 9687a/15778. If you could help me with restoring Keikai support in SpreadsheetWebApp I'd appreciate it, please confirm if you would :), as I will work on something else and will come back to this if you dont fix it.

Will do.

Status report:

Websockets - works fine for gui client and analytics/reporting, to be checked for spreadsheet app and chui client (for spreadsheet its implemented as a EE8 servlet).

• EmbeddedWebServer - works fine
• ReportWebServer - works fine
• ManagedWebServer - not tested yet - do we need it ? ACME support was removed when support for Java 17 was brought to FWD

• ReportWebServer - works fine with Analytics/Reporting
• DojoToolkitHandler - works
• EmbeddedWebHandler - works
• VirtualDesktopWebHandler - works
• WebDriverHandler - works for /gui,I need to test /chui in app other then hotel_gui
• HtmlResourceHandler - works, as GUI works
• WebResourceHandler - works
• WebAuthHandler - works as part of admin GUI
• AuthHandler - works (as embedded server works)
• SpreadsheetWebApp - App initially ported, Hynek is working on Handler

• SessionHandler - testing
• TenantHandler - testing
• LegacyServiceHandler/RestHandler/SoapHandler - testing
• WebServiceHandler - not tested, I guess I need some special code.
• DocumentOutputHandler - not tested, part of GUI app
• OpenResourceHandler - not tested, part of GUI app
• UploadHandler - not tested, part of GUI app

Status report 9687a/15782:

• StandardServer - works
• EmbeddedWebServer - works : Embedded and VirtualDesktop mode works, Websockets work
• ReportWebServer - works fine with Analytics/Reporting, Websockets work
• ManagedWebServer - not tested, do we need it ? ACME integration has been removed some time ago.

• AdminHandlerBase -> works, tested /login, used by SessionHandler,SessionHandler, part of StandardServer
• SessionHandler -> works, tested /login, not fully configured in hotel_gui app, part of StandardServer
• TenantHandler -> works, tested Handler, requires further configuration, part of StandardServer
• LegacyServiceHandler not used directly
  • WebServiceHandler -> not tested (requires additional configuration), part of StandardServer
  • LegacyWebServiceHandler not used directly
    • RestHandler -> works, tested with web_apis test, part of StandardServer
    • SoapHandler -> works, tested with web_apis test, part of StandardServer
• WebAuthHandler -> works, protects of TenantHandler,SessionHandler,AdminHandlerBase, part of StandardServer
• WebDriverHandler not used directly
  • EmbeddedWebHandler -> works, part of StandardServer
  • VirtualDesktopWebHandler -> works, part of StandardServer
• AuthHandler -> works, part of EmbeddedWebServer
• DocumentOutputHandler -> works, part of EmbeddedWebServer
• UploadHandler -> not tested, part of EmbeddedWebServer
• AbstractModulesHandler not used directly
  • DojoToolkitHandler -> works, part of EmbeddedWebServer and ReportWebServer
  • WebResourceHandler -> works, part of EmbeddedWebServer and ReportWebServer
• HtmlResourceHandler not used directly
  • OpenResourceHandler -> not tested, part of EmbeddedWebServer
  • TestKeysApplicationHandler -> not tested, part of EmbeddedWebServer
  • WebPageHandler not used directly
    • ChuiWebPageHandler -> not tested
    • GuiWebPageHandler -> works, part of EmbeddedWebServer

EE8 WebApps:

• AdminApp -> works, part of StandardServer
  • adminServerExtension -> not tested
• SpreadsheetApp -> does not work, Hynek is working on it, part of StandardServer
• GenericWebApp -> not tested, part of StandardServer - I need a example of customer application

Tomasz, do you have a list of library versions which have changed (or added/removed)? Compare the build/lib folder with trunk and 9687a.

Constantin Asofiei wrote:

Tomasz, do you have a list of library versions which have changed (or added/removed)? Compare the build/lib folder with trunk and 9687a.

See below. I also did a small upgrade of dependencies to reduce vulnerabilities. I am checking if I could update more dependencies.

tjd/17.0.14:~/projects/p2j_trunk$ diff --expand-tabs -y ~/trunk_build_lib.txt ~/9687a_build_lib.txt | grep -e "|" -e "<" -e ">" 
apache-mime4j-core-0.8.11.jar                                   |  apache-mime4j-core-0.8.12.jar
apache-mime4j-dom-0.8.9.jar                                     <
apache-mime4j-examples-0.8.9.jar                                <
apache-mime4j-mbox-iterator-0.8.9.jar                           <
apache-mime4j-storage-0.8.9.jar                                 <
asm-9.6.jar                                                     |  asm-9.7.1.jar
asm-commons-9.6.jar                                             |  asm-commons-9.7.1.jar
asm-tree-9.6.jar                                                |  asm-tree-9.7.1.jar
aspectjrt-1.9.7.jar                                             |  aspectjrt-1.9.21.jar
aspectjtools-1.9.7.jar                                          |  aspectjtools-1.9.21.jar
aspectjweaver-1.9.7.jar                                         |  aspectjweaver-1.9.21.jar
commons-io-2.15.1.jar                                           |  commons-io-2.17.0.jar
gwt-user-2.11.0.jar                                             |  gwt-user-2.12.2.jar
http2-client-9.4.54.v20240208.jar                               <
http2-common-9.4.54.v20240208.jar                               <
http2-hpack-9.4.54.v20240208.jar                                <
http2-server-9.4.54.v20240208.jar                               <
                                                                >  jakarta.annotation-api-1.3.5.jar
                                                                >  jakarta.jws-api-2.1.0.jar
                                                                >  jakarta.transaction-api-1.3.3.jar
                                                                >  jakarta.xml.soap-api-1.4.2.jar
                                                                >  jakarta.xml.ws-api-2.3.3.jar
javax.annotation-api-1.3.2.jar                                  <
javax.websocket-api-1.0.jar                                     <
javax.websocket-client-api-1.0.jar                              <
javax-websocket-client-impl-9.4.54.v20240208.jar                <
javax-websocket-server-impl-9.4.54.v20240208.jar                <
jetty-alpn-client-9.4.54.v20240208.jar                          |  jetty-alpn-client-12.0.18.jar
jetty-annotations-9.4.54.v20240208.jar                          |  jetty-client-12.0.18.jar
jetty-client-9.4.54.v20240208.jar                               |  jetty-ee-12.0.18.jar
jetty-continuation-9.4.54.v20240208.jar                         |  jetty-ee8-annotations-12.0.18.jar
jetty-deploy-9.4.54.v20240208.jar                               |  jetty-ee8-nested-12.0.18.jar
jetty-http-9.4.54.v20240208.jar                                 |  jetty-ee8-plus-12.0.18.jar
jetty-io-9.4.54.v20240208.jar                                   |  jetty-ee8-security-12.0.18.jar
jetty-jmx-9.4.54.v20240208.jar                                  |  jetty-ee8-servlet-12.0.18.jar
jetty-jndi-9.4.54.v20240208.jar                                 |  jetty-ee8-webapp-12.0.18.jar
jetty-plus-9.4.54.v20240208.jar                                 |  jetty-ee8-websocket-jetty-api-12.0.18.jar
jetty-quickstart-9.4.54.v20240208.jar                           |  jetty-ee8-websocket-jetty-common-12.0.18.jar
jetty-rewrite-9.4.54.v20240208.jar                              |  jetty-ee8-websocket-jetty-server-12.0.18.jar
jetty-security-9.4.54.v20240208.jar                             |  jetty-ee8-websocket-servlet-12.0.18.jar
jetty-server-9.4.54.v20240208.jar                               |  jetty-http-12.0.18.jar
jetty-servlet-9.4.54.v20240208.jar                              |  jetty-io-12.0.18.jar
jetty-servlets-9.4.54.v20240208.jar                             |  jetty-jndi-12.0.18.jar
jetty-util-9.4.54.v20240208.jar                                 |  jetty-plus-12.0.18.jar
jetty-util-ajax-9.4.54.v20240208.jar                            |  jetty-security-12.0.18.jar
jetty-webapp-9.4.54.v20240208.jar                               |  jetty-server-12.0.18.jar
jetty-xml-9.4.54.v20240208.jar                                  |  jetty-servlet-api-4.0.6.jar
                                                                >  jetty-session-12.0.18.jar
                                                                >  jetty-util-12.0.18.jar
                                                                >  jetty-websocket-core-common-12.0.18.jar
                                                                >  jetty-websocket-core-server-12.0.18.jar
                                                                >  jetty-websocket-jetty-api-12.0.18.jar
                                                                >  jetty-websocket-jetty-common-12.0.18.jar
                                                                >  jetty-websocket-jetty-server-12.0.18.jar
                                                                >  jetty-xml-12.0.18.jar
slf4j-api-2.0.13.jar                                            |  slf4j-api-2.0.16.jar
stax-api-1.0.1.jar                                              <
websocket-api-9.4.54.v20240208.jar                              <
websocket-client-9.4.54.v20240208.jar                           <
websocket-common-9.4.54.v20240208.jar                           <
websocket-server-9.4.54.v20240208.jar                           <
websocket-servlet-9.4.54.v20240208.jar                          <
xml-apis-1.4.01.jar                                             <

Please run ./gradlew dependencies and look into the dependency tree; for these two which are removed, they look to have dependencies on other jars:

stax-api-1.0.1.jar
xml-apis-1.4.01.jar

For StAX, we rely on it for legacy SAX handle (reading XML files).

Constantin Asofiei wrote:

Please run ./gradlew dependencies and look into the dependency tree; for these two which are removed, they look to have dependencies on other jars:
[...]

For StAX, we rely on it for legacy SAX handle (reading XML files).

Those are already provided by Java 11+, and they are not used in Java 17 FWD since #6692.

I also did a small upgrade of dependencies to reduce vulnerabilities. I am checking if I could update more dependencies.

Please do ensure that all vulnerabilities identified in #9674 are addressed.

Greg Shah wrote:

I also did a small upgrade of dependencies to reduce vulnerabilities. I am checking if I could update more dependencies.

Please do ensure that all vulnerabilities identified in #9674 are addressed.

Actually there is only one vulnerability listed there.

In addition there is a requirement for Jakarta EE 9. I've migrated FWD to EE 8, if customer needs Jakarta EE 9 additional libraries would be needed as dependencies, as we do not attach all Jetty Libraries to FWD, only the ones that are needed. And I am not sure if I can switch to FWD to EE9, I can try.

There is also list of dependencies as Excel Sheet that need attention. How should I pay attention to the listed items :) ?
Should I upgrade all items marked in orange ?
There one thing I don't understand regarding that list - org.bouncycastle packages are in orange despite FWD is using a newer version.
Considering a fact that a wider application level testing is on its way I am in a process of upgrading fwd dependencies to the latest possible versions, lets see what items stay on that list anyway.

Should I upgrade all items marked in orange ?

Yes, these are all considered a problem.

There one thing I don't understand regarding that list - org.bouncycastle packages are in orange despite FWD is using a newer version.

Post the question in #9674 and discuss it with the customer.

Greg Shah wrote:

Should I upgrade all items marked in orange ?

Yes, these are all considered a problem.

There one thing I don't understand regarding that list - org.bouncycastle packages are in orange despite FWD is using a newer version.

Post the question in #9674 and discuss it with the customer.

Greg
Posted, waiting for an answer. In meantime - should I upgrade all FWD dependencies to latest working versions as I did in #6692 ?
The customer probably does not require that.

should I upgrade all FWD dependencies to latest working versions as I did in #6692 ?

Yes, unless you have a reason that something should not be updated, let's move to the latest code.

I've updated dependencies to what I think are latest supported versions and did initial testing of 9687a/15783 - hotel_gui and report server work correctly (I've upgraded janusgraph to version 1.1).

And there are more updated dependencies. Note some of them are are explicitly updated in build.gradle, some of them are updated as a consequence of updating other dependencies.
Most of dependencies are now newer then the customer's versions.
Pushed up to revision 9687a/15783.

diff --expand-tabs -y ~/trunk_j17_15830_build_lib.txt ~/9687a_15783_build_lib.txt | grep -e "|" -e "<" -e ">" 
apache-mime4j-core-0.8.11.jar                                   |  apache-mime4j-core-0.8.12.jar
apache-mime4j-dom-0.8.9.jar                                     <
apache-mime4j-examples-0.8.9.jar                                <
apache-mime4j-mbox-iterator-0.8.9.jar                           <
apache-mime4j-storage-0.8.9.jar                                 <
args4j-2.33.jar                                                 |  args4j-2.37.jar
asm-9.6.jar                                                     |  asm-9.8.jar
asm-commons-9.6.jar                                             |  asm-commons-9.7.1.jar
asm-tree-9.6.jar                                                |  asm-tree-9.7.1.jar
aspectjrt-1.9.21.jar                                            |  aspectjrt-1.9.23.jar
aspectjtools-1.9.21.jar                                         |  aspectjtools-1.9.23.jar
aspectjweaver-1.9.21.jar                                        |  aspectjweaver-1.9.23.jar
axiom-api-1.4.0.jar                                             |  axiom-api-2.0.0.jar
axiom-impl-1.4.0.jar                                            |  axiom-impl-2.0.0.jar
batik-anim-1.17.jar                                             |  batik-anim-1.18.jar
batik-awt-util-1.17.jar                                         |  batik-awt-util-1.18.jar
batik-bridge-1.17.jar                                           |  batik-bridge-1.18.jar
batik-codec-1.17.jar                                            |  batik-codec-1.18.jar
batik-constants-1.17.jar                                        |  batik-constants-1.18.jar
batik-css-1.17.jar                                              |  batik-css-1.18.jar
batik-dom-1.17.jar                                              |  batik-dom-1.18.jar
batik-ext-1.17.jar                                              |  batik-ext-1.18.jar
batik-extension-1.17.jar                                        |  batik-extension-1.18.jar
batik-gui-util-1.17.jar                                         |  batik-gui-util-1.18.jar
batik-gvt-1.17.jar                                              |  batik-gvt-1.18.jar
batik-i18n-1.17.jar                                             |  batik-i18n-1.18.jar
batik-parser-1.17.jar                                           |  batik-parser-1.18.jar
batik-script-1.17.jar                                           |  batik-script-1.18.jar
batik-shared-resources-1.17.jar                                 |  batik-shared-resources-1.18.jar
batik-svg-dom-1.17.jar                                          |  batik-svg-dom-1.18.jar
batik-svggen-1.17.jar                                           |  batik-svggen-1.18.jar
batik-swing-1.17.jar                                            |  batik-swing-1.18.jar
batik-transcoder-1.17.jar                                       |  batik-transcoder-1.18.jar
batik-util-1.17.jar                                             |  batik-util-1.18.jar
batik-xml-1.17.jar                                              |  batik-xml-1.18.jar
bcel-6.8.1.jar                                                  |  bcel-6.10.0.jar
bcmail-jdk18on-1.78.1.jar                                       |  bcmail-jdk18on-1.80.jar
bcpg-jdk18on-1.78.1.jar                                         |  bcpg-jdk18on-1.80.jar
bcpkix-jdk18on-1.78.1.jar                                       |  bcpkix-jdk18on-1.80.jar
bcprov-jdk18on-1.78.1.jar                                       |  bcprov-jdk18on-1.80.jar
bctls-jdk18on-1.78.1.jar                                        |  bctls-jdk18on-1.80.jar
bcutil-jdk18on-1.78.1.jar                                       |  bcutil-jdk18on-1.80.jar
c3p0-0.9.5.5.jar                                                |  c3p0-0.10.2.jar
checker-qual-3.42.0.jar                                         |  checker-qual-3.48.3.jar
common-2.2.3.jar                                                |  common-2.4.0.jar
commons-codec-1.16.1.jar                                        |  commons-codec-1.18.0.jar
commons-configuration2-2.9.0.jar                                |  commons-configuration2-2.10.1.jar
commons-csv-1.10.0.jar                                          |  commons-csv-1.13.0.jar
commons-io-2.15.1.jar                                           |  commons-io-2.18.0.jar
commons-lang3-3.14.0.jar                                        |  commons-lang3-3.17.0.jar
commons-text-1.11.0.jar                                         |  commons-text-1.13.0.jar
error_prone_annotations-2.26.1.jar                              |  error_prone_annotations-2.36.0.jar
failureaccess-1.0.2.jar                                         |  failureaccess-1.0.3.jar
gremlin-core-3.7.0.jar                                          |  gremlin-core-3.7.3.jar
gremlin-driver-3.7.0.jar                                        |  gremlin-driver-3.7.3.jar
gremlin-groovy-3.7.0.jar                                        |  gremlin-groovy-3.7.3.jar
gremlin-language-3.7.0.jar                                      |  gremlin-language-3.7.3.jar
gremlin-shaded-3.7.0.jar                                        |  gremlin-shaded-3.7.3.jar
gremlin-util-3.7.0.jar                                          |  gremlin-util-3.7.3.jar
groovy-4.0.9.jar                                                |  groovy-4.0.23.jar
groovy-console-4.0.9.jar                                        |  groovy-console-4.0.23.jar
groovy-groovysh-4.0.9.jar                                       |  groovy-groovysh-4.0.23.jar
groovy-json-4.0.9.jar                                           |  groovy-json-4.0.23.jar
groovy-jsr223-4.0.9.jar                                         |  groovy-jsr223-4.0.23.jar
groovy-swing-4.0.9.jar                                          |  groovy-swing-4.0.23.jar
groovy-templates-4.0.9.jar                                      |  groovy-templates-4.0.23.jar
groovy-xml-4.0.9.jar                                            |  groovy-xml-4.0.23.jar
guava-33.1.0-jre.jar                                            |  guava-33.4.6-jre.jar
guava-gwt-33.1.0-jre.jar                                        |  guava-gwt-33.4.6-jre.jar
gwt-user-2.11.0.jar                                             |  gwt-user-2.12.2.jar
HikariCP-java7-2.4.13.jar                                       <
http2-client-9.4.54.v20240208.jar                               <
http2-common-9.4.54.v20240208.jar                               <
http2-hpack-9.4.54.v20240208.jar                                <
http2-server-9.4.54.v20240208.jar                               <
ivy-2.5.1.jar                                                   |  ivy-2.5.2.jar
jackson-annotations-2.16.1.jar                                  |  j2objc-annotations-3.0.0.jar
jackson-annotations-2.16.1-sources.jar                          |  jackson-annotations-2.18.3.jar
jackson-core-2.17.0.jar                                         |  jackson-annotations-2.18.3-sources.jar
jackson-databind-2.16.1.jar                                     |  jackson-core-2.18.3.jar
jackson-dataformat-xml-2.15.3.jar                               |  jackson-databind-2.18.3.jar
jackson-jaxrs-base-2.16.1.jar                                   |  jackson-dataformat-xml-2.17.1.jar
jackson-jaxrs-json-provider-2.16.1.jar                          |  jackson-jaxrs-base-2.18.3.jar
jackson-module-jaxb-annotations-2.16.1.jar                      |  jackson-jaxrs-json-provider-2.18.3.jar
                                                                >  jackson-module-jaxb-annotations-2.18.3.jar
jakarta.activation-api-1.2.2.jar                                |  jakarta.activation-api-2.1.3.jar
                                                                >  jakarta.annotation-api-1.3.5.jar
jakarta.xml.bind-api-2.3.3.jar                                  |  jakarta.transaction-api-1.3.3.jar
                                                                >  jakarta.xml.bind-api-4.0.2.jar
janusgraph-berkeleyje-1.0.0.jar                                 |  janusgraph-berkeleyje-1.1.0.jar
janusgraph-core-1.0.0.jar                                       |  janusgraph-core-1.1.0.jar
janusgraph-driver-1.0.0.jar                                     |  janusgraph-driver-1.1.0.jar
janusgraph-lucene-1.0.0.jar                                     |  janusgraph-lucene-1.1.0.jar
jasperreports-6.21.0.jar                                        |  jasperreports-6.21.4.jar
javaparser-core-3.25.0.jar                                      |  javaparser-core-3.26.2.jar
javax.annotation-api-1.3.2.jar                                  <
javax.websocket-api-1.0.jar                                     <
javax.websocket-client-api-1.0.jar                              <
javax-websocket-client-impl-9.4.54.v20240208.jar                <
javax-websocket-server-impl-9.4.54.v20240208.jar                <
jcl-over-slf4j-2.0.13.jar                                       |  jcl-over-slf4j-2.0.17.jar
jctools-core-4.0.1.jar                                          |  jctools-core-4.0.5.jar
jetty-alpn-client-9.4.54.v20240208.jar                          |  jetty-alpn-client-12.0.18.jar
jetty-annotations-9.4.54.v20240208.jar                          |  jetty-client-12.0.18.jar
jetty-client-9.4.54.v20240208.jar                               |  jetty-ee-12.0.18.jar
jetty-continuation-9.4.54.v20240208.jar                         |  jetty-ee8-annotations-12.0.18.jar
jetty-deploy-9.4.54.v20240208.jar                               |  jetty-ee8-nested-12.0.18.jar
jetty-http-9.4.54.v20240208.jar                                 |  jetty-ee8-plus-12.0.18.jar
jetty-io-9.4.54.v20240208.jar                                   |  jetty-ee8-security-12.0.18.jar
jetty-jmx-9.4.54.v20240208.jar                                  |  jetty-ee8-servlet-12.0.18.jar
jetty-jndi-9.4.54.v20240208.jar                                 |  jetty-ee8-webapp-12.0.18.jar
jetty-plus-9.4.54.v20240208.jar                                 |  jetty-ee8-websocket-jetty-api-12.0.18.jar
jetty-quickstart-9.4.54.v20240208.jar                           |  jetty-ee8-websocket-jetty-common-12.0.18.jar
jetty-rewrite-9.4.54.v20240208.jar                              |  jetty-ee8-websocket-jetty-server-12.0.18.jar
jetty-security-9.4.54.v20240208.jar                             |  jetty-ee8-websocket-servlet-12.0.18.jar
jetty-server-9.4.54.v20240208.jar                               |  jetty-http-12.0.18.jar
jetty-servlet-9.4.54.v20240208.jar                              |  jetty-io-12.0.18.jar
jetty-servlets-9.4.54.v20240208.jar                             |  jetty-jndi-12.0.18.jar
jetty-util-9.4.54.v20240208.jar                                 |  jetty-plus-12.0.18.jar
jetty-util-ajax-9.4.54.v20240208.jar                            |  jetty-security-12.0.18.jar
jetty-webapp-9.4.54.v20240208.jar                               |  jetty-server-12.0.18.jar
jetty-xml-9.4.54.v20240208.jar                                  |  jetty-servlet-api-4.0.6.jar
                                                                >  jetty-session-12.0.18.jar
                                                                >  jetty-util-12.0.18.jar
                                                                >  jetty-websocket-core-common-12.0.18.jar
                                                                >  jetty-websocket-core-server-12.0.18.jar
                                                                >  jetty-websocket-jetty-api-12.0.18.jar
                                                                >  jetty-websocket-jetty-common-12.0.18.jar
                                                                >  jetty-websocket-jetty-server-12.0.18.jar
                                                                >  jetty-xml-12.0.18.jar
jna-5.12.1.jar                                                  <
jna-platform-5.12.1.jar                                         <
jsoup-1.17.2.jar                                                |  jsoup-1.19.1.jar
                                                                >  jspecify-1.0.0.jar
junit-jupiter-api-5.10.2.jar                                    |  junit-jupiter-api-5.12.1.jar
junit-platform-commons-1.10.2.jar                               |  junit-platform-commons-1.12.1.jar
junit-platform-console-1.10.2.jar                               |  junit-platform-console-1.12.1.jar
junit-platform-engine-1.10.2.jar                                |  junit-platform-engine-1.12.1.jar
junit-platform-launcher-1.10.2.jar                              |  junit-platform-launcher-1.12.1.jar
junit-platform-reporting-1.10.2.jar                             |  junit-platform-reporting-1.12.1.jar
junit-platform-suite-api-1.10.2.jar                             |  junit-platform-suite-api-1.12.1.jar
junit-platform-suite-commons-1.10.2.jar                         |  junit-platform-suite-commons-1.12.1.jar
junit-platform-suite-engine-1.10.2.jar                          |  junit-platform-suite-engine-1.12.1.jar
juniversalchardet-2.4.0.jar                                     |  juniversalchardet-2.5.0.jar
log4j-api-2.21.1.jar                                            |  log4j-api-2.24.3.jar
lucene-analyzers-common-8.11.2.jar                              |  lucene-analyzers-common-8.11.3.jar
lucene-backward-codecs-8.11.2.jar                               |  lucene-backward-codecs-8.11.3.jar
lucene-core-8.11.2.jar                                          |  lucene-core-8.11.3.jar
lucene-queries-8.11.2.jar                                       |  lucene-queries-8.11.3.jar
lucene-queryparser-8.11.2.jar                                   |  lucene-queryparser-8.11.3.jar
lucene-sandbox-8.11.2.jar                                       |  lucene-sandbox-8.11.3.jar
lucene-spatial3d-8.11.2.jar                                     |  lucene-spatial3d-8.11.3.jar
lucene-spatial-extras-8.11.2.jar                                |  lucene-spatial-extras-8.11.3.jar
mariadb-java-client-3.1.2.jar                                   |  mariadb-java-client-3.5.3.jar
mchange-commons-java-0.2.19.jar                                 |  mchange-commons-java-0.3.1.jar
metrics-core-4.2.21.jar                                         |  metrics-core-4.2.27.jar
metrics-jmx-4.2.21.jar                                          |  metrics-jmx-4.2.27.jar
openpdf-1.3.30.jaspersoft.3.jar                                 |  openpdf-1.3.32.jar
poi-5.2.5.jar                                                   |  poi-5.4.0.jar
postgresql-42.7.3.jar                                           |  postgresql-42.7.5.jar
quartz-2.3.2.jar                                                |  quartz-2.5.0.jar
slf4j-api-2.0.13.jar                                            |  slf4j-api-2.0.17.jar
tika-core-2.9.2.jar                                             |  tika-core-2.9.3.jar
tika-parser-html-module-2.9.2.jar                               |  tika-parser-html-module-2.9.3.jar
tika-parser-text-module-2.9.2.jar                               |  tika-parser-text-module-2.9.3.jar
tinkergraph-gremlin-3.7.0.jar                                   |  tinkergraph-gremlin-3.7.3.jar
waffle-jna-3.2.0.jar                                            <
websocket-api-9.4.54.v20240208.jar                              <
websocket-client-9.4.54.v20240208.jar                           <
websocket-common-9.4.54.v20240208.jar                           <
websocket-server-9.4.54.v20240208.jar                           <
websocket-servlet-9.4.54.v20240208.jar                          <
woodstox-core-6.6.2.jar                                         |  woodstox-core-7.1.0.jar
xmlgraphics-commons-2.9.jar                                     |  xmlgraphics-commons-2.10.jar

Do we need following dependencies, first two are marked by the customer, but they are only APIs ?

javax.json    javax.json-api
javax.servlet    javax.servlet-api
jakarta.xml.ws  jakarta.xml.ws-api

Do we need following dependencies, first two are marked by the customer, but they are only APIs ?

You would know better than me. If you have found they are not needed by FWD, then delete them. They may have just been added in error in the past or perhaps some dependency needed them previously but is no longer there.

We will deliver it to the customer as a branch as soon as your testing is done. That customer does not use the spreadsheet widget so we can complete that work independently (but before this merges to trunk).

Greg Shah wrote:

We will deliver it to the customer as a branch as soon as your testing is done. That customer does not use the spreadsheet widget so we can complete that work independently (but before this merges to trunk).

But what about code review ?
Is this ok for this case to change task status to "review" despite knowing there is pending part (spreadsheet) ?

My testing will take some time as I need to setup applications and since I am doing that first time for the applications ETA is unknown at this time (except for regresion testing which will be done today I suppose).

• AuthFilter - status code was changed from 401 to 404
• TenantHandler - a return was removed on line 578 (before) 589 (now)
• in GenericWebServer.initializeWebApp , there are some hard-coded dependencies, which are exposed to the .war app launched inside the FWD server JVM - please check these.
• some files are missing history entries
• the javadoc params for some cases where callback parameter was added was not updated to include this
• we will need to test all functionalities which were updated (like file upload, ChUI/GUI web, SSO, etc)
• I need to put this in a project to get more insight, I'll get back with this today
• also, please rebase

Tomasz Domin wrote:

I wonder if maybe Galya should also look at the, as SSO may be impacted by changed.

In VirtualDesktopWebHandler.handle response.sendError was dropped in favor of setStatus. sendError sets the status, but also flushes the response writer, so the status can't be overwritten later on. Is it ok to use callback.succeeded(); for both failed and successful requests? Please, check if it sets a status in the implementation in jetty.

Constantin hates iterators, so you can easily change the for each to a standard for loop by moving the index declaration and incrementation in the for loop header.

      int index = 0;
      for(HttpCookie cookie:jettyCookies)
      {
         cookies[index ++] = convertHttpCookieToCookie(cookie);
      }

Galya B wrote:

Tomasz Domin wrote:

I wonder if maybe Galya should also look at the, as SSO may be impacted by changed.

In VirtualDesktopWebHandler.handle response.sendError was dropped in favor of setStatus. sendError sets the status, but also flushes the response writer, so the status can't be overwritten later on.

Good point, another question is: once callback.succeeded() is called, Tomasz, do you know if Jetty allows to do write/set anything else with the response?

Constantin hates iterators, so you can easily change the for each to a standard for loop by moving the index declaration and incrementation in the for loop header.

I don't hate them when they are needed (like for sets or maps or other collections), but if is possible for the code to be executed 10k-100k times (on the low end) in a short period of time, and you iterate an array, there will be 100k iterator instances created. We've spent a lot of time chasing and reducing the number of short-lived instances created in FWD, so lets keep an eye on this.

So yes, anything which involves legacy REST/SOAP/web and the like, please avoid iterators.

Thank you Constantin

Constantin Asofiei wrote:

Tomasz, this is for 9687a as of rev 15783

• AuthFilter - status code was changed from 401 to 404

Code 401 restored.

• TenantHandler - a return was removed on line 578 (before) 589 (now)

return restored

• in GenericWebServer.initializeWebApp , there are some hard-coded dependencies, which are exposed to the .war app launched inside the FWD server JVM - please check these.

I guess they are enough and I would not remove anything, as we are deploying customer application as an EE8 app, thus dependencies stay the same as for Jetty 9.
I will know more after testing specific customer application.
Saying that:
javax.servlet-api is to be removed as it is also provided by jetty-servlet-api
"websocket-" is to be removed as now websockets are provided now by jetty-websocket instead

• some files are missing history entries

Despite checking three times I missed history for WebHtmlBrowser.java and WebServiceAuth.java, now its included.

• the javadoc params for some cases where callback parameter was added was not updated to include this

LegacyServiceHandler.java, VirtualDesktopWebHandler.java, WebClientProtocol.java and ReportProtocol.java updated.
Just for the record - the first two are using a different Callback type then the other two.

• we will need to test all functionalities which were updated (like file upload, ChUI/GUI web, SSO, etc)

Most of them are already initially tested - see #9687
Testing will continue today.

• I need to put this in a project to get more insight, I'll get back with this today

Thanks again :)

• also, please rebase

Hynek is also working on this branch so I guess I cant rebase 9687a, in addition there may be some conflicts (in soap ?)
I will create a new development branch and rebase it.

Pushed up to revision 9687a/15784.

Tomasz Domin wrote:

Saying that:
javax.servlet-api is to be removed as it is also provided by jetty-servlet-api
"websocket-" is to be removed as now websockets are provided now by jetty-websocket instead

I think is better to be 'replaced' instead of removed... but we'll know more once we try to run the #8629 app. The point here is when you load a .war app, then we need to make available some jars from the FWD server ClassLoader to the launched .war webapp.

Galya B wrote:

Tomasz Domin wrote:

I wonder if maybe Galya should also look at the, as SSO may be impacted by changed.

In VirtualDesktopWebHandler.handle response.sendError was dropped in favor of setStatus. sendError sets the status, but also flushes the response writer, so the status can't be overwritten later on. Is it ok to use callback.succeeded(); for both failed and successful requests? Please, check if it sets a status in the implementation in jetty.

I wonder if I'd rather use something similar super.sendError in there to mimic servlet api Response.sendError behavior, shouldnt I ?

AFAIK (I may be wrong) callback.succeeded(); concludes request whatever the result of a correct processing is and leaves sending it out to IO threads, it is usually combined with returning true for handle call meaning that request has been serverd. We have failure for business logic here, but its ok from protocol standpoint as its part of a higher level protocol. Calling callback.failed() would mean we are notifying Jetty to handle erroneous situation in async environment for us.

Constantin hates iterators, so you can easily change the for each to a standard for loop by moving the index declaration and incrementation in the for loop header.
[...]

Jetty API has changed from using arrays to using Collections instead. I've checked and for each for each loop :) I am iterating over a collection.

Despite that I've noticed formatting problems with for loops and updated code stay inline with GCD code formatting.
Pushed up to revision 9687a/15785.

Tomasz Domin wrote:

Galya B wrote:

Tomasz Domin wrote:

I wonder if maybe Galya should also look at the, as SSO may be impacted by changed.

In VirtualDesktopWebHandler.handle response.sendError was dropped in favor of setStatus. sendError sets the status, but also flushes the response writer, so the status can't be overwritten later on. Is it ok to use callback.succeeded(); for both failed and successful requests? Please, check if it sets a status in the implementation in jetty.

I wonder if I'd rather use something similar super.sendError in there to mimic servlet api Response.sendError behavior, shouldnt I ?

That's the original behavior, so keep it as it was originally.

AFAIK (I may be wrong) callback.succeeded(); concludes request whatever the result of a correct processing is and leaves sending it out to IO threads, it is usually combined with returning true for handle call meaning that request has been serverd. We have failure for business logic here, but its ok from protocol standpoint as its part of a higher level protocol. Calling callback.failed() would mean we are notifying Jetty to handle erroneous situation in async environment for us.

As long as you don't see any http status being set in the implementation of that method, it is fine.

Constantin hates iterators, so you can easily change the for each to a standard for loop by moving the index declaration and incrementation in the for loop header.
[...]

Jetty API has changed from using arrays to using Collections instead. I've checked and for each for each loop :) I am iterating over a collection.

for each for collections also goes under the same category as arrays for creating iterator objects. I don't know why he missed this one.

As for the formatting according to the formatting standards the imports should be always importing the whole package with a wildcard, this should be configured in the IDE, some of the new imports are importing classes. If we had shared IDE configs this wouldn't be something to raise in code reviews. But the standards should either be existing and followed, or dismissed and abandoned altogether.

Constantin Asofiei wrote:

• also, please rebase

Rebased to trunk/15836, created and pushed 9687b/15854, no major problems with rebasing, just 6 conflicts easily resolved.

Code review of the SPREADSHEET changes in 9687a.

There are two dependency declarations of jetty-server in ext/sheet/graadle.build, also the exclusion of slf4j-api was removed.

The WebAppContext will require testing, the commented out lines were needed to allow handling multiple spreadsheet instances from a single web app.

Tomasz, 8976a was merged to trunk, this includes changes to the REST Admin handlers. Please rebase, as we need to fix them, too.

Ovidiu can help, also, at least with testing the Rest Admin APIs.

Hynek Cihlar wrote:

Code review of the SPREADSHEET changes in 9687a.

There are two dependency declarations of jetty-server in ext/sheet/graadle.build also, the exclusion of slf4j-api was removed.

Actually there were more exclusions, but why to exclude them if the scope is providedCompile ? They will not be attached to the target war.
To prove it I've compared trunk/build/lib/fwd_sheet.war/WEB-INF/lib to 9687a/build/lib/fwd_sheet.war/WEB-INF/lib and they are the same.

I have a question on upgrading org.bouncycastle, jsoup, com.fasterxml.jackson.core , jackson-databind, commons-codec, commons-lang, guava in a context of #9687-50 - Does it make sense to upgrade them to match FWD versions or they need to stay in those versions required by Keikai ?
They can stay as they are if its safer, as they are pare of a war file.

The WebAppContext will require testing, the commented out lines were needed to allow handling multiple spreadsheet instances from a single web app.

Hynek
I actually expected you will takeover spreadsheet webapp migration as you've made changes using Jetty 9 internals I do not understand.
I guess I was not clear enough.

Tomasz Domin wrote:

Hynek
I actually expected you will takeover spreadsheet webapp migration as you've made changes using Jetty 9 internals I do not understand.

Sure, in progress.

Galya B wrote:

Tomasz Domin wrote:

I wonder if I'd rather use something similar super.sendError in there to mimic servlet api Response.sendError behavior, shouldnt I ?

That's the original behavior, so keep it as it was originally.

Restored original functionality by calling WebDriverHandler.sendError, Pushed up to revision 9687a/15786 (will be merged to 9687b soon)

for each for collections also goes under the same category as arrays for creating iterator objects. I don't know why he missed this one.

I guess its because collections are not always backup up by arrays
I wonder if maybe some JVM version will provide an optimization to check underlying data structures and choose iterating over arrays instead using iterators for array backed up collections :) automatically.

As for the formatting according to the formatting standards the imports should be always importing the whole package with a wildcard, this should be configured in the IDE, some of the new imports are importing classes. If we had shared IDE configs this wouldn't be something to raise in code reviews. But the standards should either be existing and followed, or dismissed and abandoned altogether.

You are absolutely right, standards must be followed. Updated code to match importing classes GCD standard wherever it was possible.
Some cases could not be generalized due to more and more conflicts between class names. I guess number of conflicts will reduce once we start using Java modulatority.
Pushed up to revision 9687a/15787 (will be merged to 9687b soon)

Tomasz Domin wrote:

Galya B wrote:

As for the formatting according to the formatting standards the imports should be always importing the whole package with a wildcard, this should be configured in the IDE, some of the new imports are importing classes. If we had shared IDE configs this wouldn't be something to raise in code reviews. But the standards should either be existing and followed, or dismissed and abandoned altogether.

You are absolutely right, standards must be followed. Updated code to match importing classes GCD standard wherever it was possible.

Please see Developer_Tools_Configurations.
In the pages specific for Eclipse and for Idea there are also links to code style templates.

Constantin Asofiei wrote:

Tomasz, 8976a was merged to trunk, this includes changes to the REST Admin handlers. Please rebase, as we need to fix them, too.

Rebased to trunk/15837 - got so many conflicts I had to redo migration of Admin Handlers.
Pushed up 9687b revision 15856 . I also pushed fix for #9687-64 as 9687b/15857 and import formatting fixes as 9687b/15858.
Constatin, please review.

Ovidiu can help, also, at least with testing the Rest Admin APIs.

Ovidiu - do you have any testing tools/scripts/configuration/curl for testing API with 9687b ?

Hynek
Note that 9687a is a development branch and 9687b is a branch constantly re-based to current trunk, so if you are making changes please use 9687a so you code wont be overwritten.

Tomasz Domin wrote:

Hynek
Note that 9687a is a development branch and 9687b is a branch constantly re-based to current trunk, so if you are making changes please use 9687a so you code wont be overwritten.

Thanks for the heads up. Yes I'm using 9687a.

I've removed dependency on commons-httpclient which seems not to be in use since #6692 and migrated NoHostVerify option to Axis2 1.8.x - needs testing as it is setting custom http client SSLContext via ServiceClient property.
Pushed up 9687a/15788 and 9687b/15859

I've also removed dependency to com.lowagie:itext, as it seems no longer being in use by jasper-reports:
Pushed up 9687a/15789 and 9687b/15860

Changes awaiting review:
9687b/15854 or 9687a/15784 - refs #9687-61
9687b/15855 or 9687a/15785 - refs #9687-63
9687b/15856 - refs #9687-72
9687b/15857 or 9687a/15786 - refs #9687-70
9687b/15858 or 9687a/15787 - refs #9687-70
9687b/15859 or 9687a/15788 - refs #9687-75
9687b/15860 or 9687a/15789 - refs #9687-75

I see common code like this:

            Writer responseWriter = new OutputStreamWriter(Content.Sink.asOutputStream(response),StandardCharsets.UTF_8);
            responseWriter.write(printDomains(domains[0], errorSink));
            responseWriter.flush();

There is also code like this throughout FWD:

response.sendError(HttpServletResponse.SC_NOT_FOUND);

The javadoc for HttpServletResponse.sendError states:

Sends an error response to the client using the specified status code and clears the buffer. The server will preserve cookies and may clear or update any headers needed to serve the error page as a valid response. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page

If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to.

Now we are just setting the status and callback.succeeded(). This doesn't seem right, as sendError flushes and should no longer be able to change to the response.

Constantin Asofiei wrote:

I see common code like this:
[...]
Please add a worker method.

Thank you. I've added a worker method BaseAdminRestHandler.writeResponseMessage
Pushed 9687b/15861.

There is also code like this throughout FWD:
[...]

The javadoc for HttpServletResponse.sendError states:
[...]

Now we are just setting the status and callback.succeeded(). This doesn't seem right, as sendError flushes and should no longer be able to change to the response.

I've checked FWD trunk and there is only one call to HttpServletResponse.sendError in VirtualDesktopWebHandler and its already reported by Galya in #9687-59 and fixed in 9687a/15786 and 9687b/15857. There is already a helper method WebDriverHandler.sendError to handle such cases.

Rebased to trunk/15842.
Resolved minor conflicts.
Pushed up 9687b/15866.

Tomasz, with 9687a I'm getting HTTP ERROR 400 Invalid SNI.

For development (where I don't care about certificate validity) this is very inconvenient. I can work around this by simple code changes turning SNI off. Do we want to change the validation behavior when upgrading Jetty?

Hynek Cihlar wrote:

Tomasz, with 9687a I'm getting HTTP ERROR 400 Invalid SNI.

For development (where I don't care about certificate validity) this is very inconvenient. I can work around this by simple code changes turning SNI off. Do we want to change the validation behavior when upgrading Jetty?

What is scenario you are getting this ? I didnt get that error for migrated jetty apps.
I guess we should not modify old behavior, but maybe default behavior changed between Jetty 9 and Jetty 12

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz, with 9687a I'm getting HTTP ERROR 400 Invalid SNI.

For development (where I don't care about certificate validity) this is very inconvenient. I can work around this by simple code changes turning SNI off. Do we want to change the validation behavior when upgrading Jetty?

What is scenario you are getting this ? I didnt get that error for migrated jetty apps.

I'm using localhost to access FWD, the certificate I'm using (the default in the testcases project) has different common name.

I guess we should not modify old behavior, but maybe default behavior changed between Jetty 9 and Jetty 12

I would think so.

See httpConfig.addCustomizer(new SecureRequestCustomizer()); in GenericWebServer. SecureRequestCustomizer() enables SNI check. Interestingly the same code existed for Jetty 9.

Hynek Cihlar wrote:

I would think so.

See httpConfig.addCustomizer(new SecureRequestCustomizer()); in GenericWebServer. SecureRequestCustomizer() enables SNI check. Interestingly the same code existed for Jetty 9.

Maybe SSL stack started to provide more information now, SNI check only works if SNI data is available. I wonder which case in SecureRequestCustomizer.checkSni is hit by your case.

Ovidiu Maxiniuc wrote:

Let me know if you need additional help.

Thank you, it worked.
I've found related issue - in case /admin API is enabled it is not possible to get /gui or /embedded without authorization. Need to check it.

Tomasz Domin wrote:

I've found related issue - in case /admin API is enabled it is not possible to get /gui or /embedded without authorization. Need to check it.

Thank you for reporting this. I investigated the issue as it was also reported by a customer. I think they are related. The fix I wrote is simple, but I need to test it first. If you can go around these, please ignore them momentarily.

Ovidiu Maxiniuc wrote:

Tomasz Domin wrote:

I've found related issue - in case /admin API is enabled it is not possible to get /gui or /embedded without authorization. Need to check it.

Thank you for reporting this. I investigated the issue as it was also reported by a customer. I think they are related. The fix I wrote is simple, but I need to test it first. If you can go around these, please ignore them momentarily.

Ok, I'll wait to resolve the issue in trunk first.

In order to make regression tests compile I had to make following change to build.gradle.
I am not sure why - probably due to conflict between ECJ versions, so I am not committing this change.
ecj is also a dependency of jasper-reports
Hynek - I've noticed you've excluded ecj from gwt-dev dependencies at some point of time. Did you have problems with admin app compilation for a customer ?

=== modified file 'build.gradle'
--- old/build.gradle    2025-04-04 11:37:25 +0000
+++ new/build.gradle    2025-04-09 10:39:19 +0000
@@ -454,6 +454,8 @@
         // classpath FWD server fails to start complaining that en_US_P2J
         // collation cannot be find
         c.exclude group: 'com.ibm.icu', module: 'icu4j'
+        // remove eclipse compiler from gwt classpath
+        c.exclude group: 'org.eclipse.jdt', module: 'ecj'
     }

     fwdAllTest {extendsFrom fwdAllRuntime}

Tomasz Domin wrote:

In order to make regression tests compile I had to make following change to build.gradle.
I am not sure why - probably due to conflict between ECJ versions, so I am not committing this change.
ecj is also a dependency of jasper-reports
Hynek - I've noticed you've excluded ecj from gwt-dev dependencies at some point of time. Did you have problems with admin app compilation for a customer ?

Sorry, I don't recall what was the reason. What compilation issues do you get?

Hynek Cihlar wrote:

Tomasz Domin wrote:

In order to make regression tests compile I had to make following change to build.gradle.
I am not sure why - probably due to conflict between ECJ versions, so I am not committing this change.
ecj is also a dependency of jasper-reports
Hynek - I've noticed you've excluded ecj from gwt-dev dependencies at some point of time. Did you have problems with admin app compilation for a customer ?

Sorry, I don't recall what was the reason. What compilation issues do you get?

I get it when compiling regression test app admin module:

     [java] Compiling module XXXAdmin
     [java] [ERROR] An internal compiler exception occurred
     [java] com.google.gwt.dev.jjs.InternalCompilerException: Error constructing Java AST
     [java]     at com.google.gwt.dev.jjs.impl.GwtAstBuilder.translateException(GwtAstBuilder.java:4192)
     [java]     at com.google.gwt.dev.jjs.impl.GwtAstBuilder.getInternalCompilerException(GwtAstBuilder.java:4631)
     [java]     at com.google.gwt.dev.jjs.impl.GwtAstBuilder.createMembers(GwtAstBuilder.java:4326)
...
     [java]     at com.google.gwt.dev.Compiler.main(Compiler.java:113)
     [java] Caused by: java.lang.NoSuchMethodError: 'boolean org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.isRecord()'
     [java]     at com.google.gwt.dev.jjs.impl.GwtAstBuilder.createMembers(GwtAstBuilder.java:4291)
     [java]     ... 22 more
     [java]    [ERROR] at SpinbuttonRole.java(29): public interface SpinbuttonRole extends InputRole, RangeRole
     [java]       org.eclipse.jdt.internal.compiler.ast.TypeDeclaration

Tomasz Domin wrote:

Sorry, I don't recall what was the reason. What compilation issues do you get?

I get it when compiling regression test app admin module:

Yes, it looks like wrong version of the compiler is used.

Tomasz Domin wrote:

I've found related issue - in case /admin API is enabled it is not possible to get /gui or /embedded without authorization. Need to check it.
[...]
Ok, I'll wait to resolve the issue in trunk first.

I created branch 9884a and committed the fix as revision 15849. If you need it, you can extract the patch and apply to your project. Hopefully, it will fix the issue, too.

Tomasz, some new issues.

Navigating to the root path gives a page with 404 error and list of contexts (admin and _sheet). I think we should prevent the listing.

And a more serious one. When spawning the client fails (during the JS load progress dialog) the page is redirected back to the /gui path, but with additional query parameters usr and psw with shown entered user and password. That is the user name and password become visible in the browsers address box.

Tomasz Domin wrote:

In order to make regression tests compile I had to make following change to build.gradle.
I am not sure why - probably due to conflict between ECJ versions, so I am not committing this change.
ecj is also a dependency of jasper-reports
Hynek - I've noticed you've excluded ecj from gwt-dev dependencies at some point of time. Did you have problems with admin app compilation for a customer ?

[...]

The issue is caused by a conflict between ecj provided by jetty or jasper-reports and internal ecj version needed by gwt-dev package. In case external ecj jars are on classpath before gwt-dev jar they cause gwt compiler to fail when building admin application.

I've added following change to build.gradle. Note I've also excluded htmlunit as it brings in several not necessary jetty 9 libraries back into project, after that change I guess only needed jetty 9 jars stay for gwtCompile target.
With the change no further changes to app build scripts are need for tested apps (hotel and regression test app):

=== modified file 'build.gradle'
--- old/build.gradle    2025-04-04 11:37:25 +0000
+++ new/build.gradle    2025-04-10 11:10:27 +0000
@@ -455,6 +455,14 @@
         // collation cannot be find
         c.exclude group: 'com.ibm.icu', module: 'icu4j'
     }
+    [gwtCompile].each { c ->
+        // exclude ecj from transitive dependencies as gwt-dev requires
+        // its own built-in version and any other version causes
+        // conflict
+        c.exclude group: 'org.eclipse.jdt', module: 'ecj'
+        // exclude htmlunit as it is not used and it brings in legacy Jetty jars
+        c.exclude group: 'net.sourceforge.htmlunit', module: 'htmlunit'
+    }

     fwdAllTest {extendsFrom fwdAllRuntime}
 }

Pushed up to revision 9687a/15790 and 9687b/15867

Hynek Cihlar wrote:

Tomasz, some new issues.

I am on it.

What has to be fixed before we can provide this as an early release to a customer? That customer needs to make Jetty changes in their code so we need to get this to them ASAP. I had told them it would be available by EOD yesterday. Is it safe to push now?

Greg Shah wrote:

What has to be fixed before we can provide this as an early release to a customer? That customer needs to make Jetty changes in their code so we need to get this to them ASAP. I had told them it would be available by EOD yesterday. Is it safe to push now?

I think customer may start making Jetty changesin their code with the current version of 9687b branch assuming its an early release.
Its safe from application migration point of view as there will be no further major branch specific changes of dependencies and only fixes of bugs and rebases to trunk will be provided.

Tomasz: When you get the chance, please update JVM Requirements to add Java 11 and Java 17. Later, when we remove 8 and 11, then this will need to be edited again.

Hynek Cihlar wrote:

Tomasz, some new issues.

Navigating to the root path gives a page with 404 error and list of contexts (admin and _sheet). I think we should prevent the listing.

This issue is probably related with #9687-84. admin context is intercepting too much and directory listing is served by /admin DefaultContext. The issue no longer occurs when /admin context is disabled. Needs retesting once 9884a is merged to trunk and into 9687b (EDIT: it was just merged to will test it soon).

And a more serious one. When spawning the client fails (during the JS load progress dialog) the page is redirected back to the /gui path, but with additional query parameters usr and psw with shown entered user and password. That is the user name and password become visible in the browsers address box.

Found the issue and fixed that. I missed a fact that URI encoded parameters need to be passed on, but that does not apply to embedded parameters like usr/psw.
Pushed up to revision 9687a/15791 and 9687b/15868

Ovidiu Maxiniuc wrote:

Tomasz Domin wrote:

I've found related issue - in case /admin API is enabled it is not possible to get /gui or /embedded without authorization. Need to check it.

Thank you for reporting this. I investigated the issue as it was also reported by a customer. I think they are related. The fix I wrote is simple, but I need to test it first. If you can go around these, please ignore them momentarily.

Ovidiu
Did you try using admin app after the change ?
Now its possible to access embedded and virtual desktop, but admin app is still not accessible if rest API is enabled admin-rest/enabled=true.

Rebased 9687b to trunk/15850.
Migrated Ovidiu's changes, but still have issue as described in #9687-98
I guess the root cause is that both rest-admin and Administration console are using the same context path: /admin,

Pushed 9687b/15876

Hynek Cihlar wrote:

Tomasz, some new issues.

Navigating to the root path gives a page with 404 error and list of contexts (admin and _sheet). I think we should prevent the listing.

That issue is caused by adding DefaultHandler in sequence to Administration Console application. I've solved the issue by disabling directory listing and fav icon serving for that DefaultHandler, but Hynek - do we even need DefaultHandler there, maybe its better to remove it ?

=== modified file 'src/com/goldencode/p2j/main/StandardServer.java'
--- old/src/com/goldencode/p2j/main/StandardServer.java    2025-03-30 11:47:26 +0000
+++ new/src/com/goldencode/p2j/main/StandardServer.java    2025-04-11 13:15:37 +0000
@@ -1843,7 +1843,7 @@

                   org.eclipse.jetty.server.Handler.Sequence list = new org.eclipse.jetty.server.Handler.Sequence();
                   list.addHandler(webApp);
-                  list.addHandler(new DefaultHandler());
+                  list.addHandler(new DefaultHandler(false, false));

                   handlers[--num] = list;
                }

Pushed 9687a/15792 and 9687b/15877

Tomasz Domin wrote:

That issue is caused by adding DefaultHandler in sequence to Administration Console application. I've solved the issue by disabling directory listing and fav icon serving for that DefaultHandler, but Hynek - do we even need DefaultHandler there, maybe its better to remove it ?

If Jetty returns correct status even without DefaultHandler (like 404) then we don't need it.

Tomasz Domin wrote:

Ovidiu, did you try using admin app after the change ?
Now its possible to access embedded and virtual desktop, but admin app is still not accessible if rest API is enabled admin-rest/enabled=true.

I see your point now. Currently, the AdminRestHandler.java 'seized' the whole tree of /admin forcing the authentication using /admin/login and /admin/logout before allowing other access to context subtree. The revision 15850 addresses other issues, but this is still outstanding.

Momentarily, I do not know how to properly fix the issue. In #7080 we discussed about moving the whole admin interface to use REST APIs, meaning that there will be (at least) a BaseAdminRestHandler implementation for providing responses to admin client requests using REST. So now we have a transition period.

A solution would be to collect from the submodules (classes which extend BaseAdminRestHandler) the context paths they will process and do the authorisation check only for them and simply return if there is no context path which prefixes the current request. The submodules do not expose that in any way, they rely on ACLs for authorisation so that when they are requested to handle a request, they are on safe ground. Would that be a good solution?

I may be completely wrong, but in Jetty, if you have multiple handlers for a path, aren't all of them called, in order (of registration?) and execute only while not baseRequest.isHandled()?

IMO, there may be something wrong with a baseRequest.setHandled() which (falsely) sets the request as handled.

Also, something which looks wrong now:

      else if (!target.startsWith(contextPath))
      {
         return; // not my business
      }

If the handlers are 'context handlers', then this should never be needed.

Yes, that was my problem also.

Initially, I did not write code like

      if (!target.startsWith(CONTEXT_PREFIX))
      {
         return;
      }

My isolated tests were not able to reveal anything. With a customer application, there might (I did not notice them) have been some warnings reported, but the integrity of the application was not affected so the first commit was without the above check. Maybe I do something wrong?

The problem now is that the AdminRestHandler will attempt to do the authentication / authorisation for all context starting with CONTEXT_PREFIX (that is /admin). The adminapp is also sharing the /admin prefix but not as a submodule of AdminRestHandler, therefore not needed and not wanting its authentication / authorisation because it has its own.

Hynek Cihlar wrote:

Tomasz Domin wrote:

That issue is caused by adding DefaultHandler in sequence to Administration Console application. I've solved the issue by disabling directory listing and fav icon serving for that DefaultHandler, but Hynek - do we even need DefaultHandler there, maybe its better to remove it ?

If Jetty returns correct status even without DefaultHandler (like 404) then we don't need it.

Yes, it does. Or it may stay the way I have changed it now in #9687-99
But:

Hynek Cihlar wrote:

Navigating to the root path gives a page with 404 error and list of contexts (admin and _sheet). I think we should prevent the listing.

I did one more test - the issue also exists with trunk when /admin is enabled.

Ovidiu Maxiniuc wrote:

Yes, that was my problem also.

The problem now is that the AdminRestHandler will attempt to do the authentication / authorisation for all context starting with CONTEXT_PREFIX (that is /admin). The adminapp is also sharing the /admin prefix but not as a submodule of AdminRestHandler, therefore not needed and not wanting its authentication / authorisation because it has its own.

Can we move adminapp somewhere else, to some different context by defalt ? Moving AdminRestHandler would have more impact on existing integrations.

Constantin Asofiei wrote:

Ovidiu, please see attached patch - test all REST-admin requests, and admin handler. It should work.
The point is: the REST-admin handlers need to be ContextHandler - this allows them to 'process only what they need'.

• One issue I see is that the implemented methods are doHandle() instead of handle(). I guess this was caused by working with 9687a branch. I will switch to handle() to do the test with current trunk. For same reason I think the tests for handled targets should be "/admin/login" and "/admin/logout" instead of "/login" and "/logout";
• The second issue is the final condition before returning in initialize(). Since the container res always contains the AdminRestHandler, the correct condition is:
  

  res.getHandlers().length <= 1 ? null : res;

Ovidiu Maxiniuc wrote:

Constantin Asofiei wrote:

• One issue I see is that the implemented methods are doHandle() instead of handle(). I guess this was caused by working with 9687a branch.

This is because of ContextHandler - the changes are on top of trunk, not 9687 (sorry, I should have posted this at #7080)

I will switch to handle() to do the test with current trunk. For same reason I think the tests for handled targets should be "/admin/login" and "/admin/logout" instead of "/login" and "/logout";

No, doHandle is required; and the entire point of the ContextHandler is that the target does not contain the context path prefix.

• The second issue is the final condition before returning in initialize(). Since the container res always contains the AdminRestHandler, the correct condition is:

I agree.

Lets continue at #7080

Cleaned up duplicate API libs as described in #9674-28
Pushed up to revision 9687b/15878.

Is this ready for the customer to access or does it need more changes and/or testing?

Greg Shah wrote:

Is this ready for the customer to access or does it need more changes and/or testing?

I am rebasing now and testing. It will be ready EOBD.

Greg Shah wrote:

Is this ready for the customer to access or does it need more changes and/or testing?

I've rebased 9687b to trunk/15867, no conflicts encountered and did some testing (hotel_gui, admin APIs, regression).

Pushed up to revision 9687b/15895.
Greg - the updated branch is ready for the customer to access.

I've pushed 9687b revision 15895 to xfer.

Rebased to trunk/15915
There were conflict caused by changes and had to fix them, committed revision 15944
Pushed up to revision 9687b/15944.

Testing pending

Rebased 9687b to trunk/15972
There were only minor merge conflicts.

Pushed up to revision 9687b/16001.

• virtual desktop
• embedded
• tenants REST API
• sessions REST API

No new issues, except known ones like Administration console does not work when admin rest API is enabled (I guess that is to be fixed with #7080 merge)
Regression testing of 9687b/16001 in progress.

Tomasz Domin wrote:

Rebased 9687b to trunk/15972
There were only minor merge conflicts.

Pushed up to revision 9687b/16001.

Tested hotel_gui:

• virtual desktop
• embedded
• tenants REST API
• sessions REST API

No new issues, except known ones like Administration console does not work when admin rest API is enabled (I guess that is to be fixed with #7080 merge)
Regression testing of 9687b/16001 in progress.

9687b/16001 passed regression testing.
The updated branch can shared with customer.

Pushed up to revision 9687b/16007.

It appeared that 9687b branch migration to Jetty 12 was missing migration of LegacyServiceHandler derived classes. There were two choices: migrate then to Jetty 12 native handlers or to migrate them to HTTP servlets. In order to keep FWD compatibility all three: LegacyWebServiceHandler, RestHandler, SoapHandler have been migrated to Java EE8 Servlets workers.
Also server level compatibility features have been enabled: CookieCompliance.RFC2965 and @UriCompliance.LEGACY

Note that 16005 is a dirty commit just to store my first work on legacy services as Jetty 12 native Handler - I had to replace it with Java EE8 Servlets due to problems with supporting backward compatibility, especially with CGI_VARS. Now all CGI_VARS are supported as they were in Jetty 9.

I've tested changes with hotel_gui to check admin console, testcases and web_api projects.
There might be minor differences, but lets fix them as bug whenever they are reported.

Please review 9687b revisions 16005-16007 (bzr diff -r 16004). Please note there may be some classes rolled back to trunk version and revision 16005 is a first try of migration to Jetty native handlers I had to roll back.

Tomasz Domin wrote:

Pushed up to revision 9687b/16007.
Please review 9687b revisions 16005-16007 (bzr diff -r 16004). Please note there may be some classes rolled back to trunk version and revision 16005 is a first try of migration to Jetty native handlers I had to roll back.

Greg, Constantin, Hynek ?

• BasicAuth - can we de-duplicate the code in getAuthenticationDetails, authenticate and the other added methods? The code is mostly the same in all.
• RestHandler and others - can we add the 'rewritehandler' approach in a helper method?
• same with CurrentRequestFiter[EE10] and WebAuthFilter[EE10] classes - they have duplicated code, would be nice to have that as common code.
• is not clear how one would use WebAuthFilterEE10 and CurrentRequestFiterEE10. For example, GenericWebServer.initializeWebApp is hard-coded to WebAuthFilter.

Missing history entry in AuthFilter.java

In BasicAuth.getAuthenticationDetails new String(bytes) uses the default charset, I think an explicit one should be specified (utf-8?). Also the method exposes the auth info in the log:

String msg = "Authentication details invalid for " + request.getRequestURI() + 
                      " with " + AUTH_HEADER_NAME +": " + request.getHeader(AUTH_HEADER_NAME);
         log(msg, e);

SpreadsheetWebApp.java requires copyright year update.

I suppose doScope in SpreadsheetWebApp still doesn't work, correct?

WebAuthHander.handle and service should be de-duplicated.

In convertHttpCookieToCookie maxAge, secure, and httpOnly aren't copied to the resulting Cookie, is this OK?

In WebDriverHandler.getRequestParameters the exception block looses the original exception, it should be either logged ot passed to the rethrown exception.

sendPendingResponse expection -> sendPendingResponse exception

sendPendingResponse, the exception handler for InterruptedException should restore the thread interuption state. Similarly in PushMessagesWorker and WebClientProtocol.sendBinaryMessageSync.

In PushMessagesWorker LOG.log(Level.WARNING, "Send message failed!", Arrays.toString(sendMessageExceptions.toArray())); will loose the callstack info.

In WebHtmlBrowser MimeTypes.getDefaultMimeByExtension was changed to handler.getMimeTypes().getMimeByExtension. I'm not sure this is a good equivalent, I would expect the use of MimeTypes.DEFAULTS.

I don't see any changes in Agent.java and AppServerManager.java, except for history entry.

Constantin Asofiei wrote:

Thank you

Tomasz, this is for 15996 to 16007:

• BasicAuth - can we de-duplicate the code in getAuthenticationDetails, authenticate and the other added methods? The code is mostly the same in all.

I knew you would report it, but I left the code on purpose, there is not much to extract (1-2 common lines) due to way exception is catched and reported, which I wanted to left intact. I've deduplicated only getAuthenticationDetails function having 5 lines in commons.

• RestHandler and others - can we add the 'rewritehandler' approach in a helper method?

Oh come on, its only 3 duplicated lines :)

Added LegacyServiceHandler.addRewriteHandler(Handler wrappedHandler)

• same with CurrentRequestFiter[EE10] and WebAuthFilter[EE10] classes - they have duplicated code, would be nice to have that as common code.

It just looks duplicated :) as both are using servlet related objects, but please note first is based on javax.servlet and EE10 version is on jakarta.servlet so code it just looks common, it would not if I had removed imports.
There is no common come both in CurrentRequestFilter and WebAuthFilter

• is not clear how one would use WebAuthFilterEE10 and CurrentRequestFiterEE10. For example, GenericWebServer.initializeWebApp is hard-coded to WebAuthFilter.

Its not clean for me either, I've implemented it on customer request, dont have a use case for it as I dont know a full flow. I guess its not for use with GenericWebServer.initializeWebApp at all.

Hynek Cihlar wrote:

Missing history entry in AuthFilter.java

In BasicAuth.getAuthenticationDetails new String(bytes) uses the default charset, I think an explicit one should be specified (utf-8?). Also the method exposes the auth info in the log:
[...]

No, it seems that for Authentication header default is US-ASCII, we'd need to support UTF-8 if we had support for charset in the header at all.
Nevertheless I havent changed that.

SpreadsheetWebApp.java requires copyright year update.

Done.

I suppose doScope in SpreadsheetWebApp still doesn't work, correct?

I guess not, I didnt work on it waiting for your feedback.

WebAuthHander.handle and service should be de-duplicated.

There is almost nothing (maybe 2 lines ?) to deduplicate as they operate on different input object types and call different submethods.
I've updated service to use a correct HTTP status code API.

In convertHttpCookieToCookie maxAge, secure, and httpOnly aren't copied to the resulting Cookie, is this OK?

Right, added missing copying.

In WebDriverHandler.getRequestParameters the exception block looses the original exception, it should be either logged ot passed to the rethrown exception.

I've added throws declaration to getRequestParameters and removed surrounding try, as the exception is caught in the upper layer anyway.

sendPendingResponse expection -> sendPendingResponse exception

fixed

Tomorrow the rest.

Tomasz Domin wrote:

Hynek Cihlar wrote:

I suppose doScope in SpreadsheetWebApp still doesn't work, correct?

I guess not, I didnt work on it waiting for your feedback.

OK. I have spent some time on this already, but haven't come up with a good solution yet.

WebAuthHander.handle and service should be de-duplicated.

There is almost nothing (maybe 2 lines ?) to deduplicate as they operate on different input object types and call different submethods.

They have an identical structure and execution flow. This begs for some kind of request and response adapter classes to hide the differences of the Jetty and Servlet types, also given the amount of changes needed to split these in the code. Anyway, not a deal breaker.

Hynek Cihlar wrote:

sendPendingResponse, the exception handler for InterruptedException should restore the thread interuption state. Similarly in PushMessagesWorker and WebClientProtocol.sendBinaryMessageSync.

Fixed all three to restore the thread interuption state. Not sure if its checked anywhere actually later on ;)

In PushMessagesWorker LOG.log(Level.WARNING, "Send message failed!", Arrays.toString(sendMessageExceptions.toArray())); will loose the callstack info.

I've fixed Throwable processing in all three: ReportProtocol.sendPendingResponse and PushMessagesWorker

In WebHtmlBrowser MimeTypes.getDefaultMimeByExtension was changed to handler.getMimeTypes().getMimeByExtension. I'm not sure this is a good equivalent, I would expect the use of MimeTypes.DEFAULTS.

Handler's MIME types are inherited from server's MIME types, which are by default initialized to MimeTypes.DEFAULTS and allowed for modification later on.
So its more like customizable version of MimeTypes.DEFAULTS.

I don't see any changes in Agent.java and AppServerManager.java, except for history entry.

That must have stayed when migrating back from Handler to HTTPSession and back,
Fixed.

9687b Pushed up to revision 16008.
Now retesting.

I plan to push this to xfer as soon as:

• Hynek confirms that the changes pass review.
• Tomasz confirms that the base functioning passes his testing.

Tomasz Domin wrote:

Handler's MIME types are inherited from server's MIME types, which are by default initialized to MimeTypes.DEFAULTS and allowed for modification later on.
So its more like customizable version of MimeTypes.DEFAULTS.

OK.

Code review 9687b revision 16008. The changes look OK, I have no more concerns.

Note I've updated Jetty 12 to version 12.0.22 as it came out in meantime and build is still based on trunk revision 15972

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • tenants REST API
  • sessions REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)
  • authorization - Cookie and ad-hoc

All works fine (or as trunk/15972).

I guess we can push 9687b revision 16008 to the customer.

Regarding disabling SNI check mentioned in #9674-88
I'd need to modify SecureRequestCustomizer initialization to follow standalone Jetty mimics like this (when running jetty server standalone jetty.ssl.sniHostCheck properly should disable SNI check):

=== modified file 'src/com/goldencode/p2j/web/GenericWebServer.java'
--- old/src/com/goldencode/p2j/web/GenericWebServer.java    2025-07-24 12:06:47 +0000
+++ new/src/com/goldencode/p2j/web/GenericWebServer.java    2025-07-31 07:50:42 +0000
@@ -953,7 +953,8 @@
                                                      HttpConfiguration httpConfig)
    {
       String protocol = HttpVersion.HTTP_1_1.asString();
-      httpConfig.addCustomizer(new SecureRequestCustomizer());
+      boolean sniHostCheck = Boolean.valueOf(System.getProperty("jetty.ssl.sniHostCheck", "true"));
+      httpConfig.addCustomizer(new SecureRequestCustomizer(sniHostCheck));
       Scheduler scheduler = new ScheduledExecutorScheduler(
             String.format("Connector-Scheduler-%x", SCHEDULER_ID.incrementAndGet()), true);
       // for GWT development comment out SslConnectionFactory,

Or I could define configuration/directory entry.

I am not sure if I should do it at all if an alternative and proper solution exists.

Why is it an issue now when it wasn't before?

Whatever we do, the solution is not to have a Jetty property file or to set a system property. We will either disable it always or have our own directory based configuration to enable or disable.

Greg Shah wrote:

Why is it an issue now when it wasn't before?

The default behavior changed in the new version of Jetty. Jetty 9 was not as strict regarding SNI.

Perhaps we should disable it by default and provide a configuration option to enable it.

Greg Shah wrote:

Perhaps we should disable it by default and provide a configuration option to enable it.

Yes, this sounds like more seamless migration path for the end users.

Hynek Cihlar wrote:

Greg Shah wrote:

Why is it an issue now when it wasn't before?

The default behavior changed in the new version of Jetty. Jetty 9 was not as strict regarding SNI.

I am not sure about that as SecureRequestCustomizer SSLConnector configuration for Jetty 12 and 9687b is the same as in Jetty 9 and trunk: sniHostCheck is true, sniRequired is false, stsMaxAgeSeconds is -1.

Note that due to SNI only working if SNI data is present in SSL layer, so it also depends on how client application work. By default as sniRequired is false if no SNI is present it is allowed to connect.

I wonder if SNI check is related with SSL configuration. Customer has custom SSL configuration like this (cant find description in documentation):

      <node class="container" name="standard">
        <node class="container" name="xxxWebApp">
          <node class="string" name="keyStore">
            <node-attribute name="value" value="xxx-private-key.store"/>
          </node>
          <node class="string" name="storePassword">
            <node-attribute name="value" value="XXX"/>
          </node>
          <node class="string" name="entryPassword">
            <node-attribute name="value" value="XXX"/>
          </node>

I guess when removed a standard keys would be in use, so SNI check does not fail.

Tomasz Domin wrote:

Hynek Cihlar wrote:
I guess when removed a standard keys would be in use, so SNI check does not fail.

Nope, It cant be removed as it is created by getWebAppConnectors. Checking other options.

Hynek Cihlar wrote:

Greg Shah wrote:

Why is it an issue now when it wasn't before?

The default behavior changed in the new version of Jetty. Jetty 9 was not as strict regarding SNI.

Well, Hynek is right, but I had to go into Jetty sources.

For Jetty 12 if we have SniHostCheck it implies SniRequired, in case no X509 is found it fails.
I am not sure if this is not a bug.

Jetty 12 code:

        if (isSniRequired() || isSniHostCheck())
        {
            String sniHost = retrieveSni(request, session);

            X509 x509 = getX509(session);
            if (x509 == null)
                throw new BadMessageException(400, "Invalid SNI");

For Jetty 9 it denies access only if SNI does not match, if there is no X509 it allows to continue.
Jetty 9 code:

        if (_sniHostCheck || _sniRequired)
        {
            X509 x509 = (X509)sslSession.getValue(SniX509ExtendedKeyManager.SNI_X509);
            if (LOG.isDebugEnabled())
                LOG.debug("Host {} with SNI {}", request.getServerName(), x509);

            if (x509 == null)
            {
                if (_sniRequired)
                    throw new BadMessageException(400, "SNI required");
            }
            else if (_sniHostCheck && !x509.matches(request.getServerName()))
            {
                throw new BadMessageException(400, "Host does not match SNI");
            }

Not sure if that is the case, as what would imply that customer's http client does not send SNI information at all.
Nevertheless - the issue is probably caused by a different implementation of SniCheck in Jetty 12 compared to Jetty 9.

I've created task branch 9687c which includes branch 9687a and all changes from 9687b squished to simplify rebasing.

Rebased task branch 9687c to trunk/16060.
Unfortunately that revision includes changes in AdminRest application I had to rewrite in Jetty 12 due to context clash between adminapp console app and AdminRest API both mapped to the same context /admin: AdminRest app grabs specific URL-s passing all other URLs to adminapp console app.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • tenants REST API
  • sessions REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

Pushed up 9687c/16083. All works fine as trunk/16060 but in Jetty 12.

Ovidiu - I'd like you to review 9687c revisions 16080-16083 as those are mainly related to AdminRest app. And maybe we can avoid rewriting web app code in future :)

I will continue rebasing 9687c after #9625-95

Tomasz Domin wrote:

Ovidiu - I'd like you to review 9687c revisions 16080-16083 as those are mainly related to AdminRest app. And maybe we can avoid rewriting web app code in future :)

I do not think it will be necessary, at least not with 9687c changes. I am a really stranger to Jetty 12 API, but the existing classes with their logic code was preserved. The only changes are in initialisation and the class hierarchy was altered: the Handler.Abstract is used instead of ContextHandler and Handler.Sequence is used instead of HandlerCollection.

I do not know why AdminRestHandler was 'reparented' to Handler.Abstract and then wrapped in ContextHandler. In fact the same happened to all classes derived from BaseAdminRestHandler. Since they are no longer ContextHandler they must be wrapped in ContextHandler and common code (like setAllowNullPathInContext()) is now distributed to all of these classes. Is that caused by some constraints in the new Handler.Sequence class?

And some formatting issues I spot in WebAuthHandler.java: the @param, @throw and @return tags are not separated by an empty line in the javadoc of both the new method but also in some of the existing ones. We should bring this to standard.

Ovidiu Maxiniuc wrote:

Tomasz Domin wrote:

Ovidiu - I'd like you to review 9687c revisions 16080-16083 as those are mainly related to AdminRest app. And maybe we can avoid rewriting web app code in future :)

I do not think it will be necessary, at least not with 9687c changes. I am a really stranger to Jetty 12 API, but the existing classes with their logic code was preserved. The only changes are in initialisation and the class hierarchy was altered: the Handler.Abstract is used instead of ContextHandler and Handler.Sequence is used instead of HandlerCollection.

Handler.Sequence is a successor of HandlerCollection in Jetty 12.
HandlerCollection is a generic Handler template - regarding ContextHandler see below

I do not know why AdminRestHandler was 'reparented' to Handler.Abstract and then wrapped in ContextHandler. In fact the same happened to all classes derived from BaseAdminRestHandler. Since they are no longer ContextHandler they must be wrapped in ContextHandler and common code (like setAllowNullPathInContext()) is now distributed to all of these classes. Is that caused by some constraints in the new Handler.Sequence class?

ContextHandler does not support doHandle anymore, client handlers must be set with setHandler instead, so I need to create a chain ContextHandler->RestHandler for each of handlers.
Is that possible in Jetty 9 too ?

And some formatting issues I spot in WebAuthHandler.java: the @param, @throw and @return tags are not separated by an empty line in the javadoc of both the new method but also in some of the existing ones. We should bring this to standard.

Javadoc fixed, thank you.

• WebServer
• GenericWebServer.getWebAppConnectors
• GenericWebServer.initializeWebApp

Note the change does not affect EmbeddedWebServer needed for web FWD clients.

In order to enable SNIHostCheck following option needs to be added in server/default/xxxWebApp for WebApp connectors or server/default for WebServer

          <node class="boolean" name="sniCheckEnabled">
            <node-attribute name="value" value="true"/>
          </node>

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

Pushed up 9687b revision 16009.

Hynek - please review 9687b revision 16009.
And can you please hint me how to replicate SNI Error so I could verify the workaround really works, as until now I couldn't replicate the issue.
I will merge 9687b revision 16009 into 9687c after the review.

Tomasz Domin wrote:

Note the change does not affect EmbeddedWebServer needed for web FWD clients.

I'm not sure this was already discussed, but why not also enable the change for EmbeddedWebServer?

Hynek Cihlar wrote:

Tomasz Domin wrote:

Note the change does not affect EmbeddedWebServer needed for web FWD clients.

I'm not sure this was already discussed, but why not also enable the change for EmbeddedWebServer?

It wasnt discussed. I guess EmbeddedWebServer does not have configuration.
But its also not fully true what I've written. EmbeddedWebServerImpl uses GenericWebServer globalstatic HttpConfiguration, so if there is any GenericWebServer like WebServer started before EmbeddedWebServerImpl the EmbeddedWebServerImpl will share its SNIHostCheck configuration.

I was wondering if I should make new instances of HttpConfiguration each GenericWebServer but for now I left it intact.

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz Domin wrote:

Note the change does not affect EmbeddedWebServer needed for web FWD clients.

I'm not sure this was already discussed, but why not also enable the change for EmbeddedWebServer?

It wasnt discussed. I guess EmbeddedWebServer does not have configuration.
But its also not fully true what I've written. EmbeddedWebServerImpl uses GenericWebServer globalstatic HttpConfiguration, so if there is any GenericWebServer like WebServer started before EmbeddedWebServerImpl the EmbeddedWebServerImpl will share its SNIHostCheck configuration.

Oh, that is not true as EmbeddedWebServer is part of a client. I'll try to create config parameters to control SNIHostCheck in GUI/ChUI client.

Tomasz Domin wrote:

Oh, that is not true as EmbeddedWebServer is part of a client. I'll try to create config parameters to control SNIHostCheck in GUI/ChUI client.

I am still working on passing parameters from directory to WebClient.
I guess EmbeddedWebServer SNIHostCheck configuration is not needed for the customer waiting for the change at the moment, is it ?

Tomasz Domin wrote:

Tomasz Domin wrote:

Oh, that is not true as EmbeddedWebServer is part of a client. I'll try to create config parameters to control SNIHostCheck in GUI/ChUI client.

I am still working on passing parameters from directory to WebClient.
I guess EmbeddedWebServer SNIHostCheck configuration is not needed for the customer waiting for the change at the moment, is it ?

That is true. Is the current code otherwise safe for that customer?

Hynek: Are you OK with the changes?

Tomasz Domin wrote:

Tomasz Domin wrote:

Oh, that is not true as EmbeddedWebServer is part of a client. I'll try to create config parameters to control SNIHostCheck in GUI/ChUI client.

I am still working on passing parameters from directory to WebClient.
I guess EmbeddedWebServer SNIHostCheck configuration is not needed for the customer waiting for the change at the moment, is it ?

In meantime I've implemented SNIHostCheck as webClient configuration option, which is false by default.
I've tested VirtualDeskop, Embedded and ChUI web clients and option is being set/reset correctly according to directory configuration.
Pushed up 9687b to revision 16010.

Please review 9687b revision 16009 (pending) and revision 16010 (new commit).

Hynek Cihlar wrote:

Code review 9687b revisions 16009 and 16010.

In WebServer, when the http config already has a valid secure-request customizer the sni host check value read from the directory is ignored. To make the logic more resilient I think it should not be assumed the customizer won't be present and also handle the case when it is present. Similar in EmbeddedWebServerImpl and GenericWebServer.

I think it is not needed due to way each of them is initialized (EmbeddedWebServerImpl is initialized in client process, there is only one once initialized WebServer, GenericWebServer.getWebAppConnectors is for exposing FWD configured ServerConnectors to 3rd party apps).
Nevertheless I've implemented updating old SecureRequestCustomizer if it is already bound to HttpConfiguration.

The secure-request customizer assignment logic should be deduplicated in a common method.

In general I am against deduplicating 3-liners (which could be 1-liners), but this time you are right, I've created static utility function configureSniHostCheck in WebServer which actually helped implementing updating existing configuration.

Retesting now.

Tomasz Domin wrote:

Tomasz Domin wrote:

Retesting now.

Pushed up 9687b to revision 16011 post review fixes.

Please review.

Code review. The changes look good.

Greg Shah wrote:

What testing is needed before we make this available to a customer?

I can run regression tests, but I dont think they are relevant to the changes.
We need to rebase according to customer request. Please see below.

Hynek Cihlar wrote:

Code review. The changes look good.

Thank you.

In meantime on customer's request I've rebased branch 9687c to trunk revision 16089.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

I'm applying just reviewed 9687b revisions 16009-16011 on top of 9687c.

The question is which branch to make available to customer afterwards ?
9687b (based on trunk 15972) or 9687c (squashed 9687b + based to trunk 16089) - I'd prefer the latter ?
Technically I can push override 9687c to 9687b, but there will be a difference in number of commits due to squashing.

I don't want to squash changes in every rebase. We did that once to deal with some conflicting changes in trunk. Let's not make it a common practice.

I will push 9687c to xfer.

Greg Shah wrote:

What testing is needed before we make this available to a customer?

Also: Hynek, I think we need your help with the spreadsheet changes.

Yes, those are not finished yet. I will resume work on that.

In meantime on customer's request I've rebased branch 9687c to trunk revision 16089.

9687c seems to be based on trunk 16060, not trunk 16089. Something is quite wrong with this mutant branch.

Greg Shah wrote:

In meantime on customer's request I've rebased branch 9687c to trunk revision 16089.

9687c seems to be based on trunk 16060, not trunk 16089. Something is quite wrong with this mutant branch.

I didn't push it until I tested it. Please check now, just Pushed up 9687c to revision 16114.
In meantime I've also merged 9687b revisions 16009-16011 on top of 9687c and retested it with a standard web app tests as above.
I guess its safe to push it to customer.

OK, the pushed branch looks OK now. I've pushed it to xfer.

Rebased 9687c to trunk revision 16110.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

Pushed up branch 9687c to revision 16135.

I'm going to push this to xfer.

Greg Shah wrote:

I'm going to push this to xfer.

Please do.

I've pushed 9687c revision 16135 to xfer.

Please rebase 9687c from trunk 16111. There was another regression in incremental conversion from the 5586a changes, see #10400.

Greg Shah wrote:

Please rebase 9687c from trunk 16111. There was another regression in incremental conversion from the 5586a changes, see #10400.

Rebased 9687c onto trunk revision 16111. The change is minor so I only tested with Hotel GUI app.

Pushed up 9687c to revision 16136.

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

Hynek Cihlar wrote:

due to an unexpected exception during server start with 9687c.

See #9625-97.

Hynek Cihlar wrote:

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

You can check into 9687c if you worked with that branch. Just let me know when you did that before I do another rebase and bzr push with overwrite.

Tomasz Domin wrote:

There is one new small change in the branch compared to trunk which is related with MultiPart uploading in Jetty 12 in file UploadHandler. I dont think we have a regression test for that.

DEF BUTTON b1.
DEF FRAME f b1.

WEB-FILE-UPLOAD REGISTER b1 IN FRAME f CHOOSE, MOUSE-SELECT-CLICK UPLOAD.

ON WEB-UPLOAD-COMPLETE OF b1 IN FRAME f DO:
   IF NOT SESSION:WEB-UPLOAD-ERROR THEN
      MESSAGE "A file was uploaded:" SESSION:WEB-UPLOAD-FILES.
end.

ENABLE ALL WITH FRAME f.
WAIT-FOR CLOSE OF THIS-PROCEDURE.

See WEB-FILE-UPLOAD_Statement.

Hynek Cihlar wrote:

Tomasz Domin wrote:

There is one new small change in the branch compared to trunk which is related with MultiPart uploading in Jetty 12 in file UploadHandler. I dont think we have a regression test for that.

[...]

See WEB-FILE-UPLOAD_Statement.

Thank you, I'll also try to test the feature in the context of #10173

Tomasz Domin wrote:

Well, MultiPart uploading seems not working, I guess it was like that since the 9687a, working on that.

That was not exactly like that. File upload works only for the first file. Uploading the same file from the same form for the second time causes application freeze.
In the detailed Jetty 12 logs the second request just hung.

Having look at details the first request is:

POST /upload/direct/8 HTTP/1.1

The second request is:

POST /upload/direct/8 undefined

But I've also find a difference in HTTP response to first request:

HTTP/1.1 200 OK
Server: Jetty(12.0.22)
Date: Mon, 22 Sep 2025 20:28:53 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked

I should be:

HTTP/1.1 200 OK
Date: Mon, 22 Sep 2025 20:18:36 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 86
Server: Jetty(9.4.57.v20241219)

It seems like the answer to request is send back in incorrect mode, as Jetty 12 uses Transfer-Encoding: chunked by default for content of unknown size and it seems dojo-toolkit does not support it.

Please check whether the upload handler sets the content length. If not, set it.

Hynek Cihlar wrote:

Please check whether the upload handler sets the content length. If not, set it.

It couldn't as content was sent as an async stream. I had to buffer it in memory before sending it back.
Now it works correctly - for single and multiple files uploaded.

Pushed up to revision 9687c/16199.
Please review UploadHandler.java handle method.

Code review 9687c.

Please write the response directly to a ByteArrayOutputStream and avoid the intermediate string:

ByteArrayOutputStream baos = new ByteArrayOutputStream();
try (JsonWriter jw = Json.createWriter(baos)) {
    jw.write(aBlder.build());
}

I think it would be safer to also output content-length and not rely on the particular behavior of the used container. At least I didn't see any documentation about the write method also adding content-length.

Hynek Cihlar wrote:

Code review 9687c.

Please write the response directly to a ByteArrayOutputStream and avoid the intermediate string:
[...]

Done, I did wrapping to String on purpose to make sure the correct encoding is used, but after reviewing javax.json package documentation its ok to use ByteArrayOutputStream as default encoding is UTF-8

I think it would be safer to also output content-length and not rely on the particular behavior of the used container. At least I didn't see any documentation about the write method also adding content-length.

Usually I'd opt against, as if there is a calculated field it is usually better to let it calculate by the framework. But in this case there is only one correct place the output is written so I've added explicit content-length header.

Pushed up to revision 16200.
Please review.

Code review 9687c. The changes look good. Just please add the history entry.

Hynek Cihlar wrote:

Code review 9687c. The changes look good. Just please add the history entry.

With all due respect that is not needed. There is already a proper history entry in the branch +** 007 TJD 20250314 Migration to Jetty 12
The change is still related to Jetty 12 migration and it brings nothing new.

Tomasz Domin wrote:

Hynek Cihlar wrote:

Code review 9687c. The changes look good. Just please add the history entry.

With all due respect that is not needed. There is already a proper history entry in the branch +** 007 TJD 20250314 Migration to Jetty 12
The change is still related to Jetty 12 migration and it brings nothing new.

Right, makes sense.

I've pushed 9687c rev 16200 to xfer.

Hynek Cihlar wrote:

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

Hynek
Have you merged the changes to support SPREADSHEET widget ?

Tomasz Domin wrote:

Hynek Cihlar wrote:

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

Hynek
Have you merged the changes to support SPREADSHEET widget ?

Not yet. I will do it during today. I will need to rebase the changes and finish testing in the customer app.

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek Cihlar wrote:

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

Hynek
Have you merged the changes to support SPREADSHEET widget ?

Not yet. I will do it during today. I will need to rebase the changes and finish testing in the customer app.

I ran into an unexpected error:

25/09/26 15:49:59.927+0200 | WARNING | org.eclipse.jetty.ee8.nested.HttpChannel | ThreadName:qtp1447232813-80 | handleException /_sheet/zkwm java.io.IOException: java.util.ServiceConfigurationError: javax.websocket.server.ServerEndpointConfig$Configurator: Provider org.eclipse.jetty.ee8.websocket.javax.server.config.ContainerDefaultConfigurator not found

This happens during web socket request from the ZK JS library, which Keikai uses. This error is strange, (1) web socket communication from ext/sheet/fwd.js works OK, (2) I had this already working with 9687c.

Hynek Cihlar wrote:

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek Cihlar wrote:

I finished the Keikai changes for Jetty 12. I tested them with isolated test cases and they passed. I haven't tested the large GUI app where SPREADSHEET widget is used due to an unexpected exception during server start with 9687c.

Where can I check in the changes?

Hynek
Have you merged the changes to support SPREADSHEET widget ?

Not yet. I will do it during today. I will need to rebase the changes and finish testing in the customer app.

I ran into an unexpected error:
[...]

This happens during web socket request from the ZK JS library, which Keikai uses. This error is strange, (1) web socket communication from ext/sheet/fwd.js works OK, (2) I had this already working with 9687c.

There is no such file in EE8:

tjd/1.8.0_462:~/projects/jetty.project$ find . -name ContainerDefaultConfigurator.java
./jetty-ee10/jetty-ee10-websocket/jetty-ee10-websocket-jakarta-server/src/main/java/org/eclipse/jetty/ee10/websocket/jakarta/server/config/ContainerDefaultConfigurator.java
./jetty-ee9/jetty-ee9-websocket/jetty-ee9-websocket-jakarta-server/src/main/java/org/eclipse/jetty/ee9/websocket/jakarta/server/config/ContainerDefaultConfigurator.java

It seems that it may be reported by websocket code shared by all EE api implementations.

Rebased 9687c to trunk revision 16184.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

The patch from #10628 is not merged, it is assumed it will come with trunk on another rebase - just note it is needed to make embedded GUI work properly.

Pushed up branch 9687c to revision 16211.

The changes needed to make Spreadsheet backend compatible with Jetty 12 are checked in to 9687c. Tomasz, please review.

Tomasz, why do we need CurrentRequestFilterEE10 and WebAuthFilterEE10? The implementations duplicate CurrentRequestFilter and WebAuthFilter.

Hynek Cihlar wrote:

Tomasz, why do we need CurrentRequestFilterEE10 and WebAuthFilterEE10? The implementations duplicate CurrentRequestFilter and WebAuthFilter.

Hynek - They dont. They bring the same functionality but for Servlet 6.0/Jakarta EE 10 versions of CurrentRequestFilter and WebAuthFilter. Note API difference javax.servlet vs jakarta.servlet.

Hynek Cihlar wrote:

The changes needed to make Spreadsheet backend compatible with Jetty 12 are checked in to 9687c. Tomasz, please review.

Code review: I am ok with the code changes - the are only changes in spreadsheet app and EE8 websocket API dependencies were added to the main project.

Can you briefly tell us why an additional servlet was needed ?

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz, why do we need CurrentRequestFilterEE10 and WebAuthFilterEE10? The implementations duplicate CurrentRequestFilter and WebAuthFilter.

Hynek - They dont. They bring the same functionality but for Servlet 6.0/Jakarta EE 10 versions of CurrentRequestFilter and WebAuthFilter. Note API difference javax.servlet vs jakarta.servlet.

Why do we need Jakarta 10 support? What is the idea?

The current implementation duplicates the business logic, which may increase the complexity and fragility of future maintenance. If Jakarta EE 10 support is indeed required, it would be worthwhile to consider refactoring the shared logic into a common class. This would allow us to maintain alignment between the two implementations while minimizing duplication.

Tomasz Domin wrote:

Hynek Cihlar wrote:

The changes needed to make Spreadsheet backend compatible with Jetty 12 are checked in to 9687c. Tomasz, please review.

Code review: I am ok with the code changes - the are only changes in spreadsheet app and EE8 websocket API dependencies were added to the main project.

Can you briefly tell us why an additional servlet was needed ?

BootstrapServlet replaces the old Jetty 9 hack where we extended WebAppContext to route based on a context id in the path. That approach reimplemented Jetty internals and was brittle. With Jetty 12’s changes, repeating it would again tie us to private APIs and risk breakage.

The servlet gives us a portable, standard front controller: it extracts the dynamic context id, initializes the required backend context, and then dispatches. For HTTP it forwards to the right resource, for WebSocket it ensures the context is ready before the upgrade.

The dynamic context id exists so a single web app can host multiple isolated instances simultaneously (i.e. multiple iframes), each with its own context and state, without deploying multiple apps.

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz, why do we need CurrentRequestFilterEE10 and WebAuthFilterEE10? The implementations duplicate CurrentRequestFilter and WebAuthFilter.

Hynek - They dont. They bring the same functionality but for Servlet 6.0/Jakarta EE 10 versions of CurrentRequestFilter and WebAuthFilter. Note API difference javax.servlet vs jakarta.servlet.

Why do we need Jakarta 10 support? What is the idea?

We dont. Our customers do.
See: Jetty_12

Tomasz Domin wrote:

We dont. Our customers do.
See: Jetty_12

I see. Still, they should be deduplicated.

Tomasz Domin wrote:

I've committed changes #10616-57, it is need to handle special case when SOAP services are places in a root context (which actually is incorrect).
Pushed up to revision 16213, Hynek please review the revision.

Code review. The changes look good.

Tomasz Domin wrote:

There is a bit unexpected (I didnt presume its possible to map Soap handler to root of the server) consequence of migrating SoapHandler from Jetty Handler to servlets described in #10616-59, but the solution needs to be different.
Due to nature of ServletContextHandler (which is part of SoapHandler) which processes everything it gets (even despite disabling default servlet) I had to put a filter in front of it in order to make sure only URLs configured with WSDL files are handled, as when ServletContextHandler is mapped to root it processes everything if it not processed by previous Handlers.
The full processing chain for SoapHandler is:

• RewriteHandler - normalize URL
• SoapServiceFilterHandler - check it URI is SOAP URI
• ServletContextHandler - handle request

Committed revision 16214.

REST or WEB services also allow for customizing basepath, I guess I'd need the filter also for them, or is it not allowed to map them to root server directory ?

Or is that an invalid configuration ?
If it is needed I'd need to implement the same changes for them (or generalize the changes) before the review.

Hynek - please review revision 16214

Tomasz Domin wrote:

Hynek - please review revision 16214

Code review 9687c.

Please fix the added javadoc of SoapServiceFilterHandler.handle to comply with GCD's code standards.

SoapHandler instance:instances => SoapHandler instance : instances/

incances should be checked for null.

startsWith may match unintended paths. For example if basePath is /ws it would also match /wsapi. Also, Jetty uses longest path matching, so /ws/animals/cats/ and /ws/animals/ may be defined as two distinct contexts.

The solution for the potential context conflict isn't well structured IMHO. It is hidden inside of SoapHandler but should be resolved a layer above in or around StandardServer.

Instead of a filter, did you consider distinct context handlers? I.e. to have a context handler for every service, SOAP, WEB, REST? This is more inline with the Jetty's architecture. With distinct contexts there would be no need for an additional routing logic. Also it would bring Jety's (more performant?) context matching, isolation (own class loader, attributes, init params, lifecycle), EE8 vs EE10, possibility for distinct handler chains, distinct stats and request logs.

Hynek Cihlar wrote:

Instead of a filter, did you consider distinct context handlers? I.e. to have a context handler for every service, SOAP, WEB, REST? This is more inline with the Jetty's architecture. With distinct contexts there would be no need for an additional routing logic. Also it would bring Jety's (more performant?) context matching, isolation (own class loader, attributes, init params, lifecycle), EE8 vs EE10, possibility for distinct handler chains, distinct stats and request logs.

EDIT: We already have context handlers for the individual soap mappings, so this is likely out of question. AFAIK there are no benefits in scoping context handlers in Jetty.

Hynek Cihlar wrote:

Code review 9687c.

Thank you

Please fix the added javadoc of SoapServiceFilterHandler.handle to comply with GCD's code standards

I've updated handle javadoc copied from Jetty sources and formatted it to meet GCD's code standards (as using inheritDoc is forbidden)

SoapHandler instance:instances => SoapHandler instance : instances/
incances should be checked for null.

They dont have to - if instances is null it means wrong call flow as initialize must be called first in any case. And bad flow cannot be result of misconfiguration, only bad coding :)
Nevertheless I am detecting the situation and I've added a warning message.

startsWith may match unintended paths. For example if basePath is /ws it would also match /wsapi. Also, Jetty uses longest path matching, so /ws/animals/cats/ and /ws/animals/ may be defined as two distinct contexts.

The given example is correct, except it is oversimplified. The URL will have several levels (like /ws/wsa/wsa1) - so not only SOAP service basepath is used as a selection criteria, but full SOAP service URL (SOAP service instance basepath).
Note Jetty does not use longest path matching for Handlers, it uses it for Servlets, so only when request enters given ServletContext. Currently in order to enter ServletContext it first has to pass SOAP service URL filtering. If it passes the matching is simple everything (/ or /*) goes to SOAP processing, so longest URL after request enters SOAPHandler does not really matter.

The solution for the potential context conflict isn't well structured IMHO. It is hidden inside of SoapHandler but should be resolved a layer above in or around StandardServer.

I dont agree, StandardServer should not know anything about activated handlers - that's why their initialization is unified with initialize method (for almost all cases).
The solution could be generalization on LegacyServiceHandler the same way as RewriteHandler is configured, but I'd prefer to leave it for another task, as I think mapping WebServiceHandler or RestHandler to web server root and expecting other services to work is invalid, as both are based on passing parameters via URL - not via message body like SOAP, so they take over entire Context's URL namespace - so in case of mapping to Servlet Root - they will take over all URLs.

Commited revision 16215 consising of two non-functional changes:
- javadoc correction
- instances null check

Pushed up to revision 16215.

Tomasz Domin wrote:

Hynek Cihlar wrote:

The solution for the potential context conflict isn't well structured IMHO. It is hidden inside of SoapHandler but should be resolved a layer above in or around StandardServer.

I dont agree, StandardServer should not know anything about activated handlers - that's why their initialization is unified with initialize method (for almost all cases).
The solution could be generalization on LegacyServiceHandler the same way as RewriteHandler is configured, but I'd prefer to leave it for another task, as I think mapping WebServiceHandler or RestHandler to web server root and expecting other services to work is invalid, as both are based on passing parameters via URL - not via message body like SOAP, so they take over entire Context's URL namespace - so in case of mapping to Servlet Root - they will take over all URLs.

I agree that StandardServer should not be aware of activated handlers. However, the handlers themselves also shouldn’t be responsible for routing logic at the root path level. That responsibility should belong to a higher layer coordinating the overall mapping strategy.

A similar problem will appear with other service types as well. Introducing multiple overlapping filters or per handler routing logic is not desirable and will become fragile to maintain.

As I see it, this needs a more general solution at a higher level, ensuring consistent routing and namespace isolation between service types rather than resolving it ad hoc inside individual handlers.

Btw, if the paths are not normalized, they should be normalized before calling servletPath.startsWith(basePath).

Constantin, also please review the changes (9687c bzr diff -r 16212).

Hynek Cihlar wrote:

I agree that StandardServer should not be aware of activated handlers. However, the handlers themselves also shouldn’t be responsible for routing logic at the root path level. That responsibility should belong to a higher layer coordinating the overall mapping strategy.

A similar problem will appear with other service types as well. Introducing multiple overlapping filters or per handler routing logic is not desirable and will become fragile to maintain.

The problem is already there as we have overlapping URLs for Admin console and ADMIN rest API, which cause a lot of problems.

As I see it, this needs a more general solution at a higher level, ensuring consistent routing and namespace isolation between service types rather than resolving it ad hoc inside individual handlers.

That would need to be an additional layer between FWD and Jetty Handlers, also taking care of servlets.

Btw, if the paths are not normalized, they should be normalized before calling servletPath.startsWith(basePath).

AFAIK paths for SOAP Handler are normalized by RewriteHandler which is the first step of URL processing.
Its not normalized on global level.

I've just checked and the current trunk introduces a feature that may require a bit more work before merging - revision 16188 introduces additional web socket that needs to be migrated to Jetty 12.

Tomasz, beside the requestUri.startsWith(instance.getBasePath()) check mentioned by Hynek, I think we are OK.

Constantin Asofiei wrote:

Tomasz, beside the requestUri.startsWith(instance.getBasePath()) check mentioned by Hynek, I think we are OK.

Thank you

1. RewriteHandler - normalize URL
2. SoapServiceFilterHandler - check it URI is SOAP URI -> requestUri.startsWith
3. ServletContextHandler - handle SOAP request

Do you mean doing URIUtil.normalizePath(String) on requestUri ?

I mean the basepath - if that is /ws and the request URI is /wsa, then it will match. I think basepath needs to be sure it ends with a trailing '/'.

Constantin Asofiei wrote:

I mean the basepath - if that is /ws and the request URI is /wsa, then it will match. I think basepath needs to be sure it ends with a trailing '/'.

Well, I tried to do that and my testing scenarios stopped working.

We have in WSDL file:

      <soap:address location="/wsa/wsafwd"/>

The request URI in SOAPUI tests I have is /ws/wsa/wsafwd/, which is incorrect, but nevertheless it does not match.
There is a risk that customers are doing the same mapping for their applications, so

So I will refrain from doing the normalization, unless confirmed it would be safe for customers :)

Rebased 9687c to trunk revision 16246.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

• removed org.apache.velocity - (which supposed to be admin console dependency, but console works fine)
• removed com.lowagie:itext and com.itextpdf:itextpdf - it was already removed in the branch but some rebase restored it - seems a leftover from old reporting
• updated to postgresql-42.7.8.jar
• updated to commons-beanutils-1.11.0.jar
• updated to commons-lang3-3.18.0.jar
• updated to junit-platform-reporting-1.14.0.jar
• not changed bootstrap-3.4.1

The main problem I had while rebasing was new code related to SOAP client mode introduced by trunk/16191. It seems it relies on commons-http which I presumed was not used by axis 1.8 anymore.

Constantin - can you please review my changes to WebServiceImpl.java and LowLevelSocketImpl.java ? I've removed commons-http some time ago, but haven't tested changes since. How can I test it works correctly ?
All other changes are only result of rebases.

Pushed up branch 9687c to revision 16279.

Tomasz Domin wrote:

Constantin - can you please review my changes to WebServiceImpl.java and LowLevelSocketImpl.java ? I've removed commons-http some time ago, but haven't tested changes since.

I've looked at the changes and I think they should work. Decoupling this from the global 'https' registered protocol (on FWD client) is good.

How can I test it works correctly ?

There are some examples in old testcases uast/web_services/wsdl_test*.p programs, but the http://www.webservicex.net/CovertPressure.asmx?WSDL service is no longer available... you can try getting a testcase which connects to the FWD SOAP service, and after that use -nohostverify at CONNECT.

Constantin Asofiei wrote:

There are some examples in old testcases uast/web_services/wsdl_test*.p programs, but the http://www.webservicex.net/CovertPressure.asmx?WSDL service is no longer available... you can try getting a testcase which connects to the FWD SOAP service, and after that use -nohostverify at CONNECT.

Ok, I did as you said, but there were some issues.
First - existing code requires providing SSL keys for authentication, there was no option to disable certificate check for generic SSL connection - I've added that (as well as for connections with ssl authentication) for both connect and invoke operations. I've found bugs related with cases where number of procedure parameters is different than number of actual SOAP call parameters and when processing empty result. There was also an issue with migrating to axiom 2.0 in this branch - that requires including an additional dependency: axiom-legacy-attachments.

Rebased to trunk/16250

Rebased 9687c to trunk revision 16246.

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

9687c pushed up to revision 16284.

Constanin - please review.

The simple app which connects from FWD to FWD over SOAP is working fine now (when nohostverify is removed certificate error is printed):

def var h as handle.
def var l as log.
def var hp as handle.
def var chi as char.
def var cho as char.
def var result as char.

create server h.

/*
l = h:connect("-WSDL https://localhost:9443/ws/wsa/wsafwd/wsdl?targetURI=urn:tempuri-org  -Service fwdService -Port fwdObj").
*/
l = h:connect("-WSDL https://localhost:9443/ws/wsa/wsafwd/wsdl?targetURI=urn:tempuri-org  -Service fwdService -Port fwdObj -nohostverify").

if l <> yes then do: message "could not connect". pause. quit. end.

run fwdObj set hp on server h.

if not valid-handle(hp) then do: message "could not run port". pause. quit. end.

chi = 'test123'.

run pipe_char in hp(input chi, output result, output cho).

if cho <> 'test123'
then message "response is incorrect".

message cho.
message result.

Tomasz, I need to try your example when connecting from OpenEdge to the FWD server. The changes look good, I just need to make sure the connect string is valid in 4GL and if not, test the valid string.

Constantin Asofiei wrote:

Tomasz, I need to try your example when connecting from OpenEdge to the FWD server. The changes look good, I just need to make sure the connect string is valid in 4GL and if not, test the valid string.

Unfortunately I cant do it myself as there is no way of tunneling my local machine ports to remote desktop with Remmina.
I was thinking about pushing prebuilt project, but since transfer rates I am achieving are like 2 kb/s it does not make sense :)

• first CONNECT shows this in OpenEdge:
  

  Secure Socket Layer (SSL) failure. error code -55:  CONNECT HostName: (192.168.100.27) does not match Certificate: (localhost) (9318)
  Connection failure for host 192.168.100.27 port 9443 transport HTTPS. (9407)
  Error loading WSDL document  https://192.168.100.27:9443/ws/wsa/wsafwd/wsdl?targetURI=urn:tempuri-org : Fatal Error: connect operation failed (WinSock reported error=0) (11748)
  

• second CONNECT works, it gets the right response in OpenEdge

What errors is FWD showing for the first CONNECT case?

Constantin Asofiei wrote:

I've ran the test with the FWD server and:

• first CONNECT shows this in OpenEdge:
  [...]
• second CONNECT works, it gets the right response in OpenEdge

What errors is FWD showing for the first CONNECT case?

Only the last one:
Error loading WSDL document WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.:org.xml.sax.SAXParseException: Content is not allowed in trailing section.. (11748)

Tomasz Domin wrote:

Only the last one:
Error loading WSDL document WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.:org.xml.sax.SAXParseException: Content is not allowed in trailing section.. (11748)

Thanks, that's good enough.

Constantin Asofiei wrote:

Tomasz Domin wrote:

Only the last one:
Error loading WSDL document WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.:org.xml.sax.SAXParseException: Content is not allowed in trailing section.. (11748)

Thanks, that's good enough.

Constantin - does it conclude the review :) ?

In addition I've checked with trunk/16264 - it seems nohostverify does not work at all, I got for both examples the same error:

Error loading WSDL document 
https://localhost:9443/ws/wsa/wsafwd/wsdl?targetURI=urn:tempuri-org :  PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target. (11748)

Tomasz Domin wrote:

Constantin Asofiei wrote:

Tomasz Domin wrote:

Only the last one:
Error loading WSDL document WSDLException: faultCode=PARSER_ERROR: Problem parsing '- WSDL Document -'.:org.xml.sax.SAXParseException: Content is not allowed in trailing section.. (11748)

Thanks, that's good enough.

Constantin - does it conclude the review :) ?

Yes.

In addition I've checked with trunk/16264 - it seems nohostverify does not work at all, I got for both examples the same error:
[...]

Well, I think you've fixed it in 9687c? I haven't run the test program in FWD.

Constantin/Hynek: What other testing do we need?

I've asked for retesting apps in #10616-91

Good, thanks.

While waiting for answer from Hynek/Constantin I am wondering if there are branches that modify Jetty 9 related handlers. They'd need to be migrated after 9687c is merged to trunk.

Greg Shah wrote:

Constantin/Hynek: What other testing do we need?

• Multi session app server (MultiSessionAppserver)
• HTML-BROWSER widget
• FWD Admin
• Browse PDF export (OpenResourceHandler and DocumentOutputHandler)
• WEB-FILE-UPLOAD Statement
• And of course the lovely SPREADSHEET widget, but this was tested recently by myself.

Hynek Cihlar wrote:

Greg Shah wrote:

Constantin/Hynek: What other testing do we need?

Here is the unsorted list of features, beside what has been mentioned:

• Multi session app server (MultiSessionAppserver)

Isnt this setup by the customer requesting this change.

• HTML-BROWSER widget

Works, I've tested it with testcases/ui/htmlbrowser/htmlbrowser_simple.p, it loads the data, also allow browsing external site.

• FWD Admin

Do you mean admin console ? I've tested it together with hotel_gui

• Browse PDF export (OpenResourceHandler and DocumentOutputHandler)

Not sure if its related but I've tested it with hotel_gui PDF/HTML/XLS export - worked fine.

• WEB-FILE-UPLOAD Statement

I've spent testing it some time ago, retested today, uploaded files go to /tmp folder so it works fine.

• And of course the lovely SPREADSHEET widget, but this was tested recently by myself.

And its still on you ;)

• Multi session app server (MultiSessionAppserver)

Isnt this setup by the customer requesting this change.

No, we need to run basic tests in this mode. That customer doesn't use this mode yet.

Greg Shah wrote:

• Multi session app server (MultiSessionAppserver)

Isnt this setup by the customer requesting this change.

No, we need to run basic tests in this mode. That customer doesn't use this mode yet.

Are these Appserver_Tests and testcases/pasoe_test ?

Greg Shah wrote:

• Multi session app server (MultiSessionAppserver)

Isnt this setup by the customer requesting this change.

No, we need to run basic tests in this mode. That customer doesn't use this mode yet.

I am not sure if this is what was requested - I've switched web_apis_20250602 from classic appserver to multisession <node class="multisession" name="app_server">, updated its configuration and executed SOAP/REST/WebHandler tests.
There are few tests more failing compared to classic appserver environment, but its the same result as for current trunk (the same tests fail for trunk in multisession mode):

The difference is only for SOAP tests:
- pipe_date fails in pipe_date_empty and pipe_date_unknown
- pipe_datetime fails in pipe_datetime_empty and pipe_datetime_unknown
- pipe_int64 fails in pipe_int64_empty and pipe_int64_unknown
- pipe_integer fails in pipe_integer_empty and pipe_integer_unknown
- pipe_logical fails in pipe_logical_empty and pipe_ilogical_unknown

The difference is just for the error messages being reported. That is OK.

Greg, as web_apis work, then 9687c passes the multisession mode in FWD.

Are we just needing the spreadsheet to be tested before we can merge?

Tomasz: Is there any documentation needed for migration?

Greg Shah wrote:

Are we just needing the spreadsheet to be tested before we can merge?

And the fact Java 8/11 will not be supported anymore in trunk.

Tomasz: Is there any documentation needed for migration?

I think the only documentation is related with addiding EE10 classes and handlers. AFAIR There is no change in FWD configuration nor features.

Tomasz Domin wrote:

I think the only documentation is related with addiding EE10 classes and handlers. AFAIR There is no change in FWD configuration nor features.

I forgot I have already documented that Jetty_12

I am starting testing spreadheet widget now, it shouldn't take long.

SPREADSHEET tests passed with 9687c.

And the fact Java 8/11 will not be supported anymore in trunk.

We'll do a final check on customers early next week and then should be able to merge to trunk.

Greg
What about merging 9687c ? I guess we do have green light from the customer(s), dont we ?.

I've found an issue with one of customer application used for regression testing - as velocity has been removed as result of #10655 I've discovered previously undetected problem with compilation of administration console.
The solution is to download org.apache.velocity:velocity:1.7 and put velocity-1.7.jar to customer_libs.
If that is the only application requiring that jar I'd add push missing library to xfer.

I've found an issue with one of customer application used for regression testing - as velocity has been removed as result of #10655 I've discovered previously undetected problem with compilation of administration console.

Is this a customer-specific issue or is it an issue with building the FWD parts of the admin console?

The solution is to download org.apache.velocity:velocity:1.7 and put velocity-1.7.jar to customer_libs.
If that is the only application requiring that jar I'd add push missing library to xfer.

If it is a FWD problem, then we need the library as a dependency rather than as a customer lib.

Greg Shah wrote:

I've found an issue with one of customer application used for regression testing - as velocity has been removed as result of #10655 I've discovered previously undetected problem with compilation of administration console.

Is this a customer-specific issue or is it an issue with building the FWD parts of the admin console?

It seems its runtime only problem for single customer (as for now).
Removal of org.apache.velocity:velocity:1.7 from FWD runtime was on request of other customer due do being outdated and risky from security standpoint.

The solution is to download org.apache.velocity:velocity:1.7 and put velocity-1.7.jar to customer_libs.
If that is the only application requiring that jar I'd add push missing library to xfer.

If it is a FWD problem, then we need the library as a dependency rather than as a customer lib.

Greg - its hard to judge if its FWD problem. It was included in FWD distribution, now it is not.
org.apache.velocity:velocity:1.7 is a transitive dependency - there is no list of mandatory transitive dependencies.
There lots of transitive dependencies we do not include in FWD build as there is no direct use case for FWD to use them, and FWD is dependent on a few large components like JasperReports or Jetty.

I guess the reasonable default should be that dependency not included explicitly in build.gradle is an optional dependency - in such case we could also care about proper dependency version.
Or maybe there is another policy on transitive dependencies ?

If it is a feature in FWD that requires transitive dependencies to work at runtime, then those dependencies should be explicitly listed.

Ideas on how to determine the customer code that triggers the problem?

Tomasz Domin wrote:

Greg Shah wrote:

I've found an issue with one of customer application used for regression testing - as velocity has been removed as result of #10655 I've discovered previously undetected problem with compilation of administration console.

Is this a customer-specific issue or is it an issue with building the FWD parts of the admin console?

It seems its runtime only problem for single customer (as for now).
Removal of org.apache.velocity:velocity:1.7 from FWD runtime was on request of other customer due do being outdated and risky from security standpoint.

The solution is to download org.apache.velocity:velocity:1.7 and put velocity-1.7.jar to customer_libs.
If that is the only application requiring that jar I'd add push missing library to xfer.

If it is a FWD problem, then we need the library as a dependency rather than as a customer lib.

Greg - its hard to judge if its FWD problem. It was included in FWD distribution, now it is not.
org.apache.velocity:velocity:1.7 is a transitive dependency - there is no list of mandatory transitive dependencies.
There lots of transitive dependencies we do not include in FWD build as there is no direct use case for FWD to use them, and FWD is dependent on a few large components like JasperReports or Jetty.

I guess the reasonable default should be that dependency not included explicitly in build.gradle is an optional dependency - in such case we could also care about proper dependency version.
Or maybe there is another policy on transitive dependencies ?

My observation shows that this library has so called "transitive dependencies". Please see #7143-1758.

// Define repositories where Gradle can find the dependency
repositories {
    mavenCentral()
}

// Custom task to download and copy the specific dependency
task downloadVelocity(type: Copy) {
    // 1. Define the specific dependency using a detached configuration
    def velocityConfiguration = configurations.detachedConfiguration(
        project.dependencies.create('org.apache.velocity:velocity:1.7')
    )

    // 2. Specify the source files from the resolved configuration
    from velocityConfiguration

    // 3. Define the target directory where the JAR file will be copied
    // This will create a 'velocityLib' folder in your project's build directory
    into layout.buildDirectory.dir('velocityLib')

    // Optional: Add a description for clarity when running 'gradle tasks'
    description = 'Downloads the Apache Velocity 1.7 JAR to the build/velocityLib directory.'
}

My point is that if there is a transitive dependency that is required at runtime because of a FWD feature being used, then we must include velocity in our required dependencies.

Tomasz Domin wrote:

Greg - its hard to judge if its FWD problem. It was included in FWD distribution, now it is not.
org.apache.velocity:velocity:1.7 is a transitive dependency - there is no list of mandatory transitive dependencies.

Please see Software_Dependencies, Velocity is mentioned on the page.

Hynek (Constantin ?)
I'd like to standardize configurations used by GenericWebServer.initializeWebApp and SpreadsheetWebApp to:

         new AnnotationConfiguration(),
         new EnvConfiguration(),
         new FragmentConfiguration(),
         new JettyWebXmlConfiguration(),
         new MetaInfConfiguration(),
         new PlusConfiguration(),
         new WebInfConfiguration(),
         new WebXmlConfiguration(),
         new WebAppConfiguration(),
         new JavaxWebSocketConfiguration(),
         new JettyWebSocketConfiguration()

fwd_server_20251205_165354_0.log:25/12/05 16:54:12.478+0100 | WARNING | org.zkoss.zk.ui.metainfo.DefinitionLoaders | ThreadName:main, ThreadId:00000002, User:standard | Component fragment ignored. Reason: unable to load org.zkoss.zkmax.zul.Fragment due to java.lang.NoClassDefFoundError: com/google/gson/Gson
fwd_server_20251205_165354_0.log:25/12/05 16:54:12.487+0100 | WARNING | org.zkoss.zk.ui.metainfo.DefinitionLoaders | ThreadName:main, ThreadId:00000002, User:standard | Component goldenlayout ignored. Reason: unable to load org.zkoss.zkmax.zul.GoldenLayout due to java.lang.NoClassDefFoundError: com/google/gson/Gson

When there is no JavaxWebSocketConfiguration I am getting additional errors related to WebSockets.

These are basically all standard Configuration-s without JndiConfiguration and JaasConfiguration.
BTW - why WebAppContext.setConfigurations(new Configuration[] is used instead of WebAppContext.addConfiguration(Configuration ..)
What do you think about that ?

The change will be a part of 10951a branch.

Tomasz Domin wrote:

Hynek (Constantin ?)
I'd like to standardize configurations used by GenericWebServer.initializeWebApp and SpreadsheetWebApp to:
[...]
The last two were missing for both WebApp classes.
Even when having them all I am getting error when running customer app:

I don't have an instant answer. Could you break when the exception is raised and see the callstack? That could give some more clues.

BTW - why WebAppContext.setConfigurations(new Configuration[] is used instead of WebAppContext.addConfiguration(Configuration ..)
What do you think about that ?

I suppose using setConfiguration() will make the configuration exactly as defined leaving out any default ones.

Hynek Cihlar wrote:

Tomasz Domin wrote:

Hynek (Constantin ?)
I'd like to standardize configurations used by GenericWebServer.initializeWebApp and SpreadsheetWebApp to:
[...]
The last two were missing for both WebApp classes.
Even when having them all I am getting error when running customer app:

I don't have an instant answer. Could you break when the exception is raised and see the callstack? That could give some more clues.

No, as its in keikai.

This is the error when I dont add JavaxWebSocketConfiguration to spreadheet, there is obviously org.eclipse.jetty.server.handler.ContextHandler on the class path.

java.util.ServiceConfigurationError: 
    at org.eclipse.jetty.util.ServiceLoaderSpliterator$ServiceProvider.get(ServiceLoaderSpliterator.java:101)
    at org.eclipse.jetty.ee8.annotations.AnnotationConfiguration.lambda$getNonExcludedInitializers$1(AnnotationConfiguration.java:739)
    at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)
    at org.eclipse.jetty.util.ServiceLoaderSpliterator.tryAdvance(ServiceLoaderSpliterator.java:46)
    at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:332)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
    at org.eclipse.jetty.ee8.annotations.AnnotationConfiguration.getNonExcludedInitializers(AnnotationConfiguration.java:748)
    at org.eclipse.jetty.ee8.annotations.AnnotationConfiguration.configure(AnnotationConfiguration.java:430)
    at org.eclipse.jetty.ee8.webapp.Configurations.configure(Configurations.java:422)
    at org.eclipse.jetty.ee8.webapp.WebAppContext.configure(WebAppContext.java:485)
    at org.eclipse.jetty.ee8.webapp.WebAppContext.startContext(WebAppContext.java:1162)
    at org.eclipse.jetty.ee8.nested.ContextHandler.doStartInContext(ContextHandler.java:626)
    at org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1457)
    at org.eclipse.jetty.ee8.nested.ContextHandler.doStart(ContextHandler.java:615)
    at org.eclipse.jetty.ee8.servlet.ServletContextHandler.doStart(ServletContextHandler.java:243)
    at org.eclipse.jetty.ee8.webapp.WebAppContext.doStart(WebAppContext.java:502)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
    at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
    at org.eclipse.jetty.server.handler.ContextHandler.lambda$doStart$0(ContextHandler.java:762)
    at org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1463)
    at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:762)
    at org.eclipse.jetty.ee8.nested.ContextHandler$CoreContextHandler.doStart(ContextHandler.java:2352)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
    at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
    at org.eclipse.jetty.server.Server.start(Server.java:643)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
    at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
    at org.eclipse.jetty.server.Server.doStart(Server.java:584)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
    at com.goldencode.p2j.web.GenericWebServer.startup(GenericWebServer.java:713)
    at com.goldencode.p2j.web.GenericWebServer.startup(GenericWebServer.java:659)
    at com.goldencode.p2j.main.WebServer.<init>(WebServer.java:235)
    at com.goldencode.p2j.main.WebServer.initialize(WebServer.java:318)
    at com.goldencode.p2j.main.StandardServer$16.initialize(StandardServer.java:1909)
    at com.goldencode.p2j.main.StandardServer.hookInitialize(StandardServer.java:2633)
    at com.goldencode.p2j.main.StandardServer.bootstrap(StandardServer.java:1310)
    at com.goldencode.p2j.main.ServerDriver.start(ServerDriver.java:529)
    at com.goldencode.p2j.main.CommonDriver.process(CommonDriver.java:522)
    at com.goldencode.p2j.main.ServerDriver.process(ServerDriver.java:1)
    at com.goldencode.p2j.main.ServerDriver.main(ServerDriver.java:965)
Caused by: java.util.ServiceConfigurationError: javax.servlet.ServletContainerInitializer: org.eclipse.jetty.ee8.websocket.javax.server.config.JavaxWebSocketServletContainerInitializer Unable to get public no-arg constructor
    at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
    at java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:679)
    at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1240)
    at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
    at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
    at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
    at org.eclipse.jetty.util.ServiceLoaderSpliterator.tryAdvance(ServiceLoaderSpliterator.java:37)
    ... 46 more
Caused by: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler
    at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3375)
    at java.base/java.lang.Class.getConstructor0(Class.java:3580)
    at java.base/java.lang.Class.getConstructor(Class.java:2273)
    at java.base/java.util.ServiceLoader$1.run(ServiceLoader.java:666)
    at java.base/java.util.ServiceLoader$1.run(ServiceLoader.java:663)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
    at java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:674)
    ... 51 more
Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler
    at org.eclipse.jetty.ee8.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:405)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
    ... 59 more

BTW - why WebAppContext.setConfigurations(new Configuration[] is used instead of WebAppContext.addConfiguration(Configuration ..)
What do you think about that ?

I suppose using setConfiguration() will make the configuration exactly as defined leaving out any default ones.

But why we need the configuration elements to be exactly like provided ? Why not using default WebApp configurations ?

Tomasz Domin wrote:

But why we need the configuration elements to be exactly like provided ? Why not using default WebApp configurations ?

Default Jetty configs are version-dependent and order-dependent. Explicit configuration fixes the ordering and guarantees the exact pipeline (annotations, fragments, websocket, etc.), making behavior reproducible across environments and easier to debug. It also prevents accidental additions from third-party jars on the classpath from altering the config chain without us noticing.

Hynek Cihlar wrote:

Tomasz Domin wrote:

But why we need the configuration elements to be exactly like provided ? Why not using default WebApp configurations ?

Default Jetty configs are version-dependent and order-dependent. Explicit configuration fixes the ordering and guarantees the exact pipeline (annotations, fragments, websocket, etc.), making behavior reproducible across environments and easier to debug. It also prevents accidental additions from third-party jars on the classpath from altering the config chain without us noticing.

I dont thing there is a version dependency - can you please explain ? Jetty is using configs provided with a given Jetty 12.

Regarding order If we are relying on Jetty configs - would that mean that apps deployed in FWD's Jetty would behave in different way then applications deployed on a plain jetty with its default configs ?
Is ordering any important for Jetty 12 ? Do we have tickets that customers reports which was caused by a non-standard configs order ?

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz Domin wrote:

But why we need the configuration elements to be exactly like provided ? Why not using default WebApp configurations ?

Default Jetty configs are version-dependent and order-dependent. Explicit configuration fixes the ordering and guarantees the exact pipeline (annotations, fragments, websocket, etc.), making behavior reproducible across environments and easier to debug. It also prevents accidental additions from third-party jars on the classpath from altering the config chain without us noticing.

I dont thing there is a version dependency - can you please explain ? Jetty is using configs provided with a given Jetty 12.

The default configuration isn't defined by any standard AFAIK. Is there a guarantee it won't change between Jetty versions?

Is ordering any important for Jetty 12 ?

I don't know. Can you prove the ordering is not important?

Hynek Cihlar wrote:

Tomasz Domin wrote:

I dont thing there is a version dependency - can you please explain ? Jetty is using configs provided with a given Jetty 12.

The default configuration isn't defined by any standard AFAIK. Is there a guarantee it won't change between Jetty versions?

The default configuration is defined by Servlet 4.0 specification which are mapped to Jetty features managed by configurations - which requires a proper order of configurations executions.
I did more investigation and I can confirm the order is important.
The default in Jetty 12 EE8 webapp order is as follows:

org.eclipse.jetty.ee8.webapp.WebInfConfiguration@4484a80e
org.eclipse.jetty.ee8.webapp.WebXmlConfiguration@3763ef0d
org.eclipse.jetty.ee8.webapp.MetaInfConfiguration@41732538
org.eclipse.jetty.ee8.webapp.FragmentConfiguration@5834b11
org.eclipse.jetty.ee8.plus.webapp.EnvConfiguration@64a64777
org.eclipse.jetty.ee8.plus.webapp.PlusConfiguration@4c95d769
org.eclipse.jetty.ee8.websocket.javax.server.config.JavaxWebSocketConfiguration@14176126
org.eclipse.jetty.ee8.websocket.server.config.JettyWebSocketConfiguration@b536b76
org.eclipse.jetty.ee8.annotations.AnnotationConfiguration@5d980894
org.eclipse.jetty.ee8.webapp.JaasConfiguration@3f54b2d1
org.eclipse.jetty.ee8.webapp.JndiConfiguration@1065ea4c
org.eclipse.jetty.ee8.webapp.WebAppConfiguration@fd2bed
org.eclipse.jetty.ee8.webapp.JettyWebXmlConfiguration@1dbc5fce

            new JettyWebSocketConfiguration(),
            new WebAppConfiguration(),
            new WebInfConfiguration(),
            new WebXmlConfiguration(),
            new MetaInfConfiguration(),
            new FragmentConfiguration(),
            new JettyWebXmlConfiguration(),
            new AnnotationConfiguration()

Anyway - I can understand that SpreadSheetWebApp as a specific app can require a different order compared to a generic webapp, but for a generic webapp we should align to standards, like Jetty 12 EE8 WebApp default configurations, as they depend on each other.

After playing a bit with the configurations order the above exception was gone. Unfortunately it still exists when SpreadSheetWebApp configuration is modified to be like a default Jetty configuration, and unfortunately I've lost it (I will report back if I find a proper
In meantime can you please check the exception in Keikai ? You can use current trunk.

I did some digging and velocity-1.7.jar is only needed on administration console compilation of a single customer (as for now). It is NOT needed at runtime.
I've tested customer administration console and without velocity-1.7.jar it works just fine. It seems that GWT compiler is using it to generate code from templates on compile time.

As it is old and has security issues I'd opt for keeping it removed and adding

Greg Shah wrote:

If it is a feature in FWD that requires transitive dependencies to work at runtime, then those dependencies should be explicitly listed.

Yes and no - it seems a build time dependency, so it should not be included at runtime - especially if its not secure.

Ideas on how to determine the customer code that triggers the problem?

Compilation of GWT administration console of one of customers

Sergey Ivanovskiy wrote:

Or maybe there is another policy on transitive dependencies ?

My observation shows that this library has so called "transitive dependencies". Please see #7143-1758.
[...]

Please see #7143-1758 is my comment, do you mean Please see #7143-1759 ? I dont have velocity jar in customer_libs on clean checkout. Otherwise I dont understand.

Use ./gradlew downloadVelocity

No no no, please dont do any special handling of this case.

Hynek Cihlar wrote:

Tomasz Domin wrote:

org.apache.velocity:velocity:1.7 is a transitive dependency - there is no list of mandatory transitive dependencies.

Please see Software_Dependencies, Velocity is mentioned on the page.

I dont think it should work this way - FWD is not a third party components repository - its distribution shall contain only necessary elements - especially those required for runtime.
It should be required dependencies that define the Software_Dependencies

I will try to move velocity-1.7.jar from build/lib to build/lib.gwt in FWD. That should make it available for GWT compiler and at the same it wont be used by FWD or any customer application runtime.

I will try to move velocity-1.7.jar from build/lib to build/lib.gwt in FWD. That should make it available for GWT compiler and at the same it wont be used by FWD or any customer application runtime.

A good idea.

• commit 16306/16307 #10951 fix -> Add missing WebSocket configurations to WebApp context
• commit 16308 #10950 fix -> Fix for ResourceHandler to handle null context path
• commit 16309 #9687-247 velocity fix -> Restored org.apache.velocity for GWT compiler only purposes

Hynek, Sergey - Please review

Tomasz, I don't see the changes in the branche. Please check if they are pushed.

Hynek Cihlar wrote:

Tomasz, I don't see the changes in the branche. Please check if they are pushed.

I am very sorry, I gave you wrong branch.
Please review branch 10951a.

Tomasz Domin wrote:

I have pushed all recent fixes to issues related to 9687c merging into trunk into branch 10951a:

• commit 16306/16307 #10951 fix -> Add missing WebSocket configurations to WebApp context
• commit 16308 #10950 fix -> Fix for ResourceHandler to handle null context path
• commit 16309 #9687-247 velocity fix -> Restored org.apache.velocity for GWT compiler only purposes

• hotel_gui
  • virtual desktop
  • embedded app
  • admin app
  • sessions/tenants REST API
• web_apis
  • fwdREST (including Webhandler)
  • fwd_classic (SOAP)

I am waiting for customer to confirm/reject #10950 fix

Tomasz Domin wrote:

I am waiting for customer to confirm/reject #10950 fix

Customer confirmed #10950 is fixed.
Please review branch 10951a.

Hynek, Constantin ?
Customer wants to have changes merged to trunk today, see #10950-27

Tomasz Domin wrote:

Hynek, Constantin ?
Customer wants to have changes merged to trunk today, see #10950-27

Branch 10951a has been reviewed in #10951-39
I've tested it in #9687-268, in addition I've tested it with customer application (customer who requested the change)

I will do the merging of 10951a to trunk in the next 15 minutes.

Alexandru Lungu wrote:

Branch 10951a was merged into trunk as rev. 16313 and archived.

Thank you, I was away for a moment.

Thank you, I was away for a moment.

No problem :)