JSF: skip looking for managed/named beans on incompatible JSF versions - #9489
JSF: skip looking for managed/named beans on incompatible JSF versions#9489NicolaIsotta wants to merge 1 commit into
Conversation
|
Just a note: the current behavior doesn't actually cause errors or exceptions - the main purpose of the PR is performance |
|
@NicolaIsotta this looks like a small change and I suppose you tested it. If you want we could try merging this for NB 31 if you rebase it soon (till Wednesday) |
matthiasblaesing
left a comment
There was a problem hiding this comment.
@NicolaIsotta I'm wondering about the statements, that check for the JSF version. The current implementation is mixed in regard to beans to be not shown if the version can't be determined:
JsfELVariableResolverreturn beans based onui:paramif version can't be determinedWebBeansELVariableResolverdoes not return beans if version can't be determinedJSFBeanCachedoes not return beans if version can't be determined.
Would it make sense to unify this?!
|
Makes sense, I'll align the behaviors BTW: this is just a small performance improvement, I think it can safely wait NB32 |
- do not search CDI Named beans on JSF 2.1- (CDI support was introduced in 2.2) - do not search managed beans on Faces 4.0 or upper, since support was removed small code refactors/modernization
6a78c93 to
d3cd8be
Compare
|
Updated and rebased, ready to merge |
|
|
||
| // managed beans have been removed in Faces 4.0 | ||
| JsfVersion jsfVersion = JsfVersionUtils.forProject(project); | ||
| if (jsfVersion != null && jsfVersion.isAtLeast(JsfVersion.JSF_4_0)) { |
There was a problem hiding this comment.
Shouldn't this be:
| if (jsfVersion != null && jsfVersion.isAtLeast(JsfVersion.JSF_4_0)) { | |
| if (jsfVersion == null || jsfVersion.isAtLeast(JsfVersion.JSF_4_0)) { |
so that this is consitent? I see:
- JsfELVariableResolver:
jsfVersion == null-> no beans added - WebBeansELVariableResolver:
jsfSupport == null-> no beans returned
returning the empty list that is stored in beans seems to be in line with that.
small code refactors/modernization
^Add meaningful description above
Click to collapse/expand PR instructions
By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -
LLMs, Commit messages and PR description:
git log) that all commits have a valid name and email address for you in the Author field.Assisted-by: MODEL_NAME MODEL_VERSIONline appended to the commit message.Assisted-byline from above)If you're a first time contributor, see the Contributing guidelines for more information.
If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.
PR approval and merge checklist:
If this PR targets the delivery branch: don't merge. (full wiki article)