Custom ELResolver ordering after javax.el to jakarta.el migration

Direct answer

No. The servlet/Jakarta Faces container does not guarantee a universal custom-before-implicit or implicit-before-custom ELResolver order across the javax.el to jakarta.el package rename. A null base does not automatically throw PropertyNotFoundException; the EL chain is consulted and a resolver wins only when it sets propertyResolved=true on the ELContext. There is no standard automatic invalidation of custom ELResolver cached state when the authentication or security context changes.

Confirmed facts vs. likely explanation

Confirmed: javax.el to jakarta.el is primarily a package rename. The ELResolver API contract is unchanged, and the migration itself does not specify resolver ordering.

Confirmed: resolver order depends on the EL implementation and how the composite ELResolver is assembled, not on the package name.

Likely: in Jakarta Faces, resolvers registered through Application.addELResolver are often consulted before the implementation default resolver, so a null-base expression such as #{foo} may reach your custom resolver first. This is implementation-specific and should not be treated as a contract.

Likely: if your resolver caches values keyed by principal or security context, that cache can survive login, logout, session invalidation, or credential expiration because no standard EL event clears it.

Steps for this case

1. Register a logging ELResolver that prints base, property, and propertyResolved before and after calling super.getValue, specifically for base == null.
2. Evaluate #{foo} and #{implicitObject.property} in the target container and confirm whether your resolver runs before the implicit-object resolver.
3. Repeat the test after the javax.el-to-jakarta.el migration with identical faces-config or EL registrations. Any order change is container-specific, not caused by the package rename.
4. Move authentication and expired-credential checks out of the resolver and into a filter, controller, or per-call EL function. Do not cache authorization decisions inside the resolver or expression compilation.

Missing diagnostic

What is your target container and EL implementation, and do you register the resolver through JSF Application.addELResolver or directly through ELContext/CompositeELResolver? This detail changes whether a deterministic ordering recommendation is possible.