0
votes

As JSF 2.3, @ManagedBean and other javax.faces.bean.* annotations are deprecated and replaced with JavaEE 6 CDI.

I successfully made a sample JSF project and deployed it to WebLogic using server implementations 'glassfish.jsf.jar' and with no implementation of JSF nor CDI in the WEB-INF/lib.

But I am afraid to be stuck with Server implementation that may be out of date in sometimes + my application behave differently during work in different application servers so I think it would be better if I have control over JSF implementation.

I spent the last 4 days for searching for a way to use a custom JSF implementation (Mojarra or MyFaces) using new CDI annotations or any other DI framework but with no luck.

I got that I must use JavaEE server implementation of JSF and CDI if I want to get rid of @ManagedAnnotations.

My question: is there a way to include my preferred implementation of JSF and CDI in my WAR that will be deployed to different application servers like WebLogic and WildFly.

Note: I found an old question from 2013 with No as an answer but I want to know is this answer still valid

Edit 02/11/2018: I successfully install a project with embedded JSF (Mojarra) and CDI (Weld) without any problem on Tomcat Server. I think it's because Tomcat is Servlet Container so there are no conflicts.

I think my problem because of the conflict between my embedded CDI and Server implementation version of Weld. I can not find a solution to make my application is as blackbox.

I used this weblogic.xml false

    <prefer-application-packages>
        <package-name>!javax.servlet.*</package-name>   
    </prefer-application-packages>

    <prefer-application-resources>
        <resource-name>!javax.servlet.*</resource-name>
    </prefer-application-resources>
1
I know WildFly allows on-the-fly swapping of JSF implementations. That might solve part of your trouble. However, both servers are locked into CDI implementations (actually it should be Weld in both) because a very specific server-side implementations are required to internally handle EJB support, interceptors, hooking into server lifecycles etc. I cannot imagine a server easily replacing CDI implementation to be honest. (almost) All EE technologies integrate with CDI in some way and at best you need vendor specific API/SPI for server to handle that. - Siliarus
@Siliarus Me too 'can not imagine a server easily replacing CDI implementation' but I asked to be sure before I make my decision. I can not understand the benefit from making the glue between CDI and JSF like this as it makes upgrade not easy if current server implementation has an issue. Weblogic does not provide a version from a year now. - Karim Ahmed
I would say just go with WildFly, that one is usually pretty up to date and easy to upgrade to new verisons. - Siliarus
@Siliarus The problem that we have two customers. one of them using WebLogic with no intent of change, therefore, the application will run on different implementations and/or version of JSF and CDI. I think it will be preferred to use JSF2.2 & Spring to avoid any future problems, What do you think? - Karim Ahmed
I am not familiar with Spring to judge that. Although do your customers really need most up to date implementation versions? Specifications do not change all that often after all... - Siliarus

1 Answers

0
votes

The other answer is sort of still valid. But there are sort of other (better) options

1 Also provide the full java-ee container as part of your app.

2 Require a minimal version of specific app servers

3 Tell customers they need at least specific versions of certain libraries