Re: Test and what's next?

Guillermo González de Agüero


I have a rough idea, not sure how well could it work or if it would even work:

On cases where there are just some methods, create a class that delegates to the deprecated module. For example:

public ActionSource {
    public MethodBinding getAction() {
        return LegacyHelper.callLegacy(ActionSource.class, "getAction", MethodBinding.class, null, this);
Parameters are: class, method to be invoked, return class, method parameters and instance to call on.

That method would somehow find the legacy version and call it, only if "mojarra-legacy.jar" classes are present. An UnsupportedOperationException would be thrown otherwise.

For cases when a class/method is used just to maintain BC, I think a "com.sun.jsf.enable_legacy_mode" context-param may be added to disable them. A propietary param would allow it to be done outside of an active JSR. The default value for this param would be false, while the legacy module would enable it with a web-fragment.xml or a ServletContainerInitializer. could state that @JsfConfig.version() >= 2.4 defaults to disabled legacy mode, allowing you to explicitly enable it.

Calls to deprecated classes could be encapsulated in a way like: invokeIfRunningOnLegacyMode(() -> new ResourceResolver().resolve(...));

The main benefit there is for users reading the code, probably trying to find out a bug or learning JSF internals. It is self explanatory that those calls are only for the legacy mode and that you can safely ignore them if you are running on the "modern" mode.

What do you think?


Guillermo González de Agüero.

On Sat, May 13, 2017 at 7:22 PM, Arjan Tijms <arjan.tijms@...> wrote:
On Sat, May 13, 2017 at 10:05 am, Guillermo González de Agüero wrote:
Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL?

There often are indeed, see for example this one:

getAction returns a MethodBinding, which is the deprecated pre-UEL type that everyone desperately wants to get rid off.

It has been replaced by:

Which in this case is in another interface. There are also cases (in abstract classes mostly) where the deprecated and replacement are in the same class.

Do you have a whole list of "legacy/deprecated" JSF features?

There's an initial list in the JSF spec document itself. At least those things would be a prime candidate to be actually removed, but as said that's not always easy because of Java EE's backward compatibility rules.

In some cases the deprecated methods just sit there and nothing would normally call them. In other cases, unfortunately, they are still called and chained to their replacements, again for backwards compatibility. Those show up in the stack traces and are really not so nice to have around. One example is the ResourceResolver and the ResourceHandler. The resolver is deprecated, but it's still called. See

Kind regards,

Arjan Tijms


Join to automatically receive all group messages.