Topics

Test and what's next?

Arjan Tijms
 

Hi everyone,


First of all a test to see if the new mailing lists work, and just an open question of what things if any all of you think should be interesting for a next spec release of JSF?


Kind regards,

Arjan Tijms

Βασίλης Στεργιούλης
 

Hi Arjan,

the list seems to work ok, thank you.

Vasilis Stergioulis

2017-05-11 12:55 GMT+03:00 Arjan Tijms <arjan.tijms@...>:

Hi everyone,


First of all a test to see if the new mailing lists work, and just an open question of what things if any all of you think should be interesting for a next spec release of JSF?


Kind regards,

Arjan Tijms

Dennis Kieselhorst
 

Hi Arjan,

I just had a look at the migrated issues: https://github.com/javaee/javaserverfaces-spec/issues

In my view we should flag the ones for the next version. Unfortunately it seems not possible to sort by priority as it's only a label or am I missing something?

Regards

Dennis

Arjan Tijms
 

We could indeed start to flag potential candidates for the next version already. The idea of this thread was to gauge interest a little, see what people already know what they'd like to see.

Continuing the CDI migration/alignment would be a big one for me. There's much more to be done there still.

GitHub issues indeed does not have priority sorting, other than sorting on thumbs up. Compared to JIRA GitHub issue is as bare bones an issue tracker can be.


Guillermo González de Agüero
 

Hi,

CDI alignment is also one of my favourites. The other one would be simpler component development. Composite components are a great (but poorly documented, IMHO) feature. But even then, they are only simple when you don't need to resort to Java code.

I know you Arjan had a prototype for a simplified model [1]. That would be indeed a good start.

Modern JavaScript frameworks are making ui components "fashionable" again, but JSF components are still too oriented to library authors, IMO.


Regards,

Guillermo González de Agüero



El sáb., 13 de mayo de 2017 13:01, Arjan Tijms <arjan.tijms@...> escribió:

We could indeed start to flag potential candidates for the next version already. The idea of this thread was to gauge interest a little, see what people already know what they'd like to see.

Continuing the CDI migration/alignment would be a big one for me. There's much more to be done there still.

GitHub issues indeed does not have priority sorting, other than sorting on thumbs up. Compared to JIRA GitHub issue is as bare bones an issue tracker can be.


Arjan Tijms
 

Hi,

On Sat, May 13, 2017 at 1:17 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
I know you Arjan had a prototype for a simplified model [1]. That would be indeed a good start.

That's the other thing I'd really like to work on. I so wanted to have this in 2.3, but there's always choices to be made.

As soon as the next spec cycle starts and pending spec lead and overal EG approval I hope to be able to work on that.

Kind regards,
Arjan Tijms

 


Modern JavaScript frameworks are making ui components "fashionable" again, but JSF components are still too oriented to library authors, IMO.


Regards,

Guillermo González de Agüero



El sáb., 13 de mayo de 2017 13:01, Arjan Tijms <arjan.tijms@...> escribió:

We could indeed start to flag potential candidates for the next version already. The idea of this thread was to gauge interest a little, see what people already know what they'd like to see.

Continuing the CDI migration/alignment would be a big one for me. There's much more to be done there still.

GitHub issues indeed does not have priority sorting, other than sorting on thumbs up. Compared to JIRA GitHub issue is as bare bones an issue tracker can be.


Neil Griffin
 

Rather than prune the Managed Bean Facility (MBF) entirely, If possible, I would rather see Mojarra and MyFaces extract their MBF implementations into a separate/companion jar. That would provide for a slimmer Faces impl for developers using CDI, yet still provide backwards compatibility for legacy apps.

Arjan Tijms
 

Pruning the native managed bean facility would take 2 major releases, and in Mojarra if I understood correctly it would never be truly removed. It's the RI, so after being pruned it's made optional, which means the RI still has to provide an example (reference) implementation for it.

MyFaces would be allowed to drop it totally then.

But yes, I like your idea of trying to extract the MBF into a separate jar. I think we can even do that already outside the spec cycle as an implementation detail.

Guillermo González de Agüero
 

Splitting it sounds good so people can create reduced runtimes.

Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

Regards

Guillermo González de Agüero

El sáb., 13 de mayo de 2017 17:47, Arjan Tijms <arjan.tijms@...> escribió:

Pruning the native managed bean facility would take 2 major releases, and in Mojarra if I understood correctly it would never be truly removed. It's the RI, so after being pruned it's made optional, which means the RI still has to provide an example (reference) implementation for it.

MyFaces would be allowed to drop it totally then.

But yes, I like your idea of trying to extract the MBF into a separate jar. I think we can even do that already outside the spec cycle as an implementation detail.

Arjan Tijms
 

On Sat, May 13, 2017 at 08:57 am, Guillermo González de Agüero wrote:
Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.

 

Guillermo González de Agüero
 

Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL? I imagine that would mean a lot of duplication, unless a new interface with the same purpose could be introduced, while deprecating the former one.

That could make it all even bigger, but I'm now thinking about cleaner stacktraces (using only new artifacts) more than in splitted modules.

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


Regards,

Guillermo González de Agüero

El sáb., 13 de mayo de 2017 18:02, Arjan Tijms <arjan.tijms@...> escribió:

On Sat, May 13, 2017 at 08:57 am, Guillermo González de Agüero wrote:
Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.

 

Arjan Tijms
 

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:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource.html#getAction--

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

It has been replaced by:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource2.html#getActionExpression--

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 http://arjan-tijms.omnifaces.org/p/jsf-22.html#809

Kind regards,

Arjan Tijms





 

Guillermo González de Agüero
 

Hi,

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.

JSF.next 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?


Regards,

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:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource.html#getAction--

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

It has been replaced by:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource2.html#getActionExpression--

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 http://arjan-tijms.omnifaces.org/p/jsf-22.html#809

Kind regards,

Arjan Tijms





 

Edward Burns
 

Hello Arjan and list.

Right now our total focus is completing and delivering Java EE 8 and
Java SE 9, and their new capabilities, and we hope to deliver them
this summer. I expect we will have more to say about our overall
Java strategy and plans at JavaOne following Java EE 8/Java SE 9
delivery.

In addition, I also plan to release Mojarra 2.3.1 with support for Servlet 4.0 push and integrate that into GlassFish 5.0.

Ed

Previous Topic Next Topic