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
I understand your point but adding an abstraction here is a big overhead for the Faces team and i wouldn't recommend it.
The way to rely on CDI is the correct way IMO.
And like Arjan mentioned, there are very small CDI<>Spring bridges out there and hey, OWB is just ~0,5mb.

Virenfrei. www.avast.com

Am Sa., 31. Okt. 2020 um 16:32 Uhr schrieb Lars Grefer <eclipse@xxxxxxxxxxxxx>:

Exactly. The main integration point for Spring into JSF is a faces-config like this: https://github.com/joinfaces/joinfaces/blob/4.3.0/joinfaces-autoconfigure/src/main/resources/META-INF/faces-config.xml
The custom EL resolver then just resolves Spring beans instead of JSF Managed Beans or CDI ones.

If you add this class to the mix, Spring can even use the JSF view scope for its beans: https://github.com/joinfaces/joinfaces/blob/4.3.0/joinfaces-autoconfigure/src/main/java/org/joinfaces/autoconfigure/viewscope/ViewScope.java

The only things which don't work at the moment are those, which are hard-coded to use CDI.
The main example being the new WebSocket feature: https://github.com/joinfaces/joinfaces/issues/690

Would it be feasible to "hide" CDI behind some sort of abstraction layer, so one could still replace it?
The Spring-based implementation of such an abstraction layer could live in the JoinFaces project.

I understand that it is not in the scope of the core Faces team to actively support Spring (or other DI containers),
but it'd be great if the design would allow it for other projects to do so.

Am 2020-10-29 17:38, schrieb Thomas Andraschko:

Thats at least the current situation and we should really talk about it if we should move our artifact handling to CDI or leave it as it as (with factories).
Actually the current system is quite good and not related to managed beans.

Am Do., 29. Okt. 2020 um 17:33 Uhr schrieb Thomas Andraschko <andraschko.thomas@xxxxxxxxx>:
AFAIK in theory you could still use JSF with Spring Core after we removed the native Managed Beans. Spring just integrated its bean mechanism via a custom ELResolver, thats still possible.

Just not sure about Spring WebFlow and so on.

Am Do., 29. Okt. 2020 um 15:54 Uhr schrieb arjan tijms <arjan.tijms@xxxxxxxxx>:
Hi,

On Thu, Oct 29, 2020 at 1:13 AM Lars Grefer <eclipse@xxxxxxxxxxxxx> wrote:

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?

Faces has been dependent on things like CDI for over 10 years now, but has done so in small steps. Some might even say too small steps, but it is what it is. Things like the FlowScope and custom data-models were CDI based from the beginning, there never were non-CDI versions of those.
 
The way forward is to support Spring Beans in a very similar way as Spring frameworks support CDI beans, e.g. how Spring MVC and Spring Security are integrated into EE environments and using CDI. CDI, via its producers and portable extensions has first class support for building bridges to other containers / DI systems.
 
Some pointers to get you started:
 
 
If there are volunteers, we could perhaps even look into providing a distribution which would embed (shade) a CDI implementation like OWB together with a bridge. 
 
With the native managed bean system being removed, in terms of size and complexity this would not even be a major difference. It would essentially replace the internal native managed bean system code with an internal OWB managed bean system. I don't think the core Faces team has the resources for this, but a volunteer project, perhaps even sponsored if a company would be interested, can surely be taken into account.
 
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

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


_______________________________________________
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