Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mojarra-dev] Starting Jakarta Faces 4.0

How would the "Continue re-basing on CDI" part affect projects, which currently use JSF without the CDI bean container?

Many projects want to use the Spring Framework as bean container for example.

There are existing integrations for both Spring WebFlow (https://docs.spring.io/spring-webflow/docs/2.5.1.RELEASE/reference/html/spring-faces.html) and Spring Boot (https://github.com/joinfaces/joinfaces)

Would these use-cases still be possible with Faces 4.0?

Am 2020-10-28 18:55, schrieb arjan tijms:

Hi,
 
With the release of Jakarta Faces 3.0, and some early work starting for Mojarra 4.0, I think it's a good moment to start the discussion again on what we like to see in Jakarta Faces 4.0.
 
As some of you may remember, we discussed this almost two years ago after JSF 2.3 was released, but then the entire javax -> jakarta migration came in between.
 
The proposals carried over from that discussion are:
 
Removing deprecated things:
* Removing JSP support as a VDL (deprecated since 2.0)
* Removing the native managed beans (deprecated since 2.3)
* Removing references to the native EL (deprecated since 1.2)
* Default "Fakes Faces 2.2"-mode (defaulting to the current version instead)
 
Continue re-basing on CDI:
* CDI events 
* Internal artefacts as CDI beans
* Additional artefacts injectable
 
Modularization
  * Separate API modules for
    * Flows
    * Navigation Rules
    * Contracts
 
Features
  * Extensionless views by default
  * New lifecycle for REST/REST-like actions (for cases where view action with empty page is used now)
   * Simplified API for setting FacesMessages
   * First class support for creating views in Java
   * Stateless views as global option
   * Annotations for various things such as components (replaces/is alternative for bulky taglib registrations)
   
API enhancements:
  * StateHelper - Allow a Supplier as defaultValue
  * PhaseListener - default methods
  * Renderer -  generic/parameterized
  * Remove duplicate SessionMap annotation
  * API to register custom behavior for a composite
 
New deprecations:
   * Full State Saving
 
If my memory serves me correctly, and from looking back in the archives (at mojarra-dev), we had the most consensus about removing JSP support, removing the native managed bean system, removing the native EL and removing the fake 2.2 compatibility mode.
 
I also feel that that API enhancements are not controversial and inline with the API polishing efforts that have been done through the years.
 
If there's any other things that should be on this list, please let me know :)
 
Kind regards,
Arjan Tijms
 
 
 

_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mojarra-dev



Back to the top