FISH-6519 Don't Ever Delegate JSF Classes if using Bundled JSF #6425
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Port from Enterprise 5 to keep things in sync. This fix was primarily written for the case of attempting to use a JSF 2.2 implementation bundled with PrimeFaces while the server was using JSF 2.3, but the behaviour change is probably still applicable to Payara 6.
The
useBundledJsf
property can be defined in an application's deployment descriptor to specify that the JSF version bundled with the application should be used over what is provided by the server. This allows you to use something like MyFaces, a different version of Mojarra, or some other JSF implementation.PrimeFaces has a mechanism where it determines which version of JSF to activate (since it supports multiple versions) by doing a lookup on classes. In the case of PrimeFaces 11 it determines if an application is JSF 2.3 by attempting to look up the
javax.faces.component.UIImportConstants
class. Before this change, on Enterprise 5 if bundling an application with JSF 2.2 the PrimeFaces lookup on the JSF 2.3 class would still succeed because after theWebappClassLoader
had attempted (and failed) to find the class by looking in the bundled JSF implementation, it would then delegate the loading to its parent which would find it since JSF 2.3 is on the class path.This change makes it so that this delegation never happens - if it can't find it "locally", just give up and throw a CNFE.
Before: override any JSF classes with those that can be found in the bundled JSF implementation, but still attempt to provide JSF classes from the server's implementation if they can't be found in the bundled JSF implementation.
After: Only attempt to load JSF classes using the bundled implementation.
Note, that this only applies to WARs. You cannot have a JSF implementation added as a library to an EAR and have a WAR also within the EAR use that implementation. You would have to have the bundled JSF within the WAR within the EAR.
Original skeleton for reproducer app taken from https://github.com/StevenHachel/glassfish-test-jsf22
Important Info
Blockers
None
Testing
New tests
New sample under payara-samples.
New tests to demonstrate the application deploying successfully, and the use (or disuse) of a bundled JSF implementation.
Testing Performed
Ran new arquillian tests.
Testing Environment
Windows 11
Documentation
payara/Payara-Documentation#324
Notes for Reviewers
Unsure if I should also be cancelling delegation lookup for JSF resources (e.g.
jakarta/faces/LogStrings.properties
)...