Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FISH-6519 Don't Ever Delegate JSF Classes if using Bundled JSF #6425

Merged
merged 3 commits into from
Oct 4, 2023

Conversation

Pandrex247
Copy link
Member

@Pandrex247 Pandrex247 commented Oct 2, 2023

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 the WebappClassLoader 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)...

@Pandrex247
Copy link
Member Author

Jenkins test please

@luiseufrasio luiseufrasio self-requested a review October 3, 2023 19:27
Copy link
Contributor

@luiseufrasio luiseufrasio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Pandrex247 Pandrex247 merged commit 20b47fc into payara:master Oct 4, 2023
1 check passed
@Pandrex247 Pandrex247 deleted the FISH-6519-Community branch October 4, 2023 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants