Can't deploy applications from Admin Console from a local packaged file or directory

[OndroMih]

When

• in Admin Console
• trying to deploy an application that resides on the filesystem local to the GlassFish server, either as a package file or directory
• deployment fails with a message in Admin Console: GUI internal error: Archive Path is NULL

Environment Details

• GlassFish Version (and build number): 7.0.3 (branch: master, commit: 8e18070, timestamp: 2023-03-29T19:58:00Z)
• JDK version: Zulu 17 (doesn't matter)
• OS: Ubuntu (doesn't matter)
• Database: N/A

---

Problem Description

When

• in Admin Console
• trying to deploy an application that resides on the filesystem local to the GlassFish server, either as a package file or directory
• deployment fails with a message in Admin Console: GUI internal error: Archive Path is NULL

Deployment works when a packaged file is uploaded (the default option).
Deployment works using asadmin command for uploaded file and local directory or file.

The expected behavior works in GlassFish 6.2.5.

Steps to reproduce

Easy to reproduce - just try the above with any simple WAR application (e.g. generated with https://start.jakarta.ee/ for Jakarta EE 10. It should deploy using the upload option when OK button is pressed. But currently it fails for the local package or directory (if you unpack the WAR), with the message "GUI internal error: Archive Path is NULL" as on the following pictures:

Impact of Issue

//: # Bad user experience and feeling that simple things don't work with GlassFish

Type: bug
Component: Admin Console
Priority: high

[OndroMih]

On the first sight, it looks similar to: #22739.

But when I debugged it, it's just similar. The real issue is that Admin Console is trying to upload a file even if a local option is selected. The value of uploadRdBtn is not correctly set to "serverSide" in fileComponent.jsf but remains "client" when read in the command in uploadButtons.inc.

This is because ELResolvers clash. When the page is loaded, fileComponent.jsf calls setPageSessionAttribute(key="uploadRdBtn", value="client"); to set a page attribute uploadRdBtn to client as the default value. The EL reference #{uploadRdBtn} is evaluated from this attribute, using the PageSessionResolver in jsf-templating.

When the button OK is pressed, the value "serverSide" is sent in the multipart form data, is part of the request map, and thus evaluated by the ScopedAttributeELResolver in Mojarra. However, PageSessionResolver is used to evaluate #{uploadRdBtn} before the ScopedAttributeELResolver, and, since the value was set into the pageSession, the value of "client" is still retrieved. If ScopedAttributeELResolver is called before PageSessionResolver or if there's no uploadRdBtn attribute in page session, deployment works as expected.

[OndroMih]

More observations:

• in GF 7.0.3, jsf-templating 4.0, PageSessionResolver resolves directly from the page session map stored in the view root.
• in GF 6.2.5, jsf-templating 3.0, PageSessionResolver resolves first using the legacy resolver and then from the page session map. This legacy resolver delegates to ScopedAttributeELResolver so the variable is resolved from the view before it's resolved by the PageSessoinResolver from the page session map.

In jsf-templating 3.0, PageSessionResolver implements VariableResolver and accepts a VariableResolver in constructor, which is filled by ApplicationConfigProcessor in Mojarra with a legacy variable resolver, which I think is a JSP resolver. PageSessionResolver delegates first to this legacy resolver, which in turn calls the ScopedAttributeELResolver. Thus ScopedAttributeELResolver takes precedence and returns the correct value.

In eclipse-ee4j/glassfish-jsftemplating#82, this delegation was removed and PageSessionResolver resolves without delegating to ScopedAttributeELResolver. Since PageSessionResolver is earlier in the chain, it takes precedence before ScopedAttributeELResolver and returns the value in the page session map instead of the value in the view.

This PR in jsf-templateing eclipse-ee4j/glassfish-jsftemplating#90 should fix it - it stores the page session data directly to view, so it's equivalent with the view scope. PageSessionResolver still takes precedence but returns the correct data from the view instead stale data from the custom page session map.

[Megnatis]

not fixed! please please fix this issue! @dmatej

[OndroMih]

Hi, @Megnatis. It works for me on version 7.0.4. Can you provide more details? Which GlassFish version you use, and what you did?