0

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>
Karim Ahmed
  • 93
  • 1
  • 8
  • 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 Nov 05 '18 at 12:59
  • @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 Nov 06 '18 at 06:32
  • I would say just go with WildFly, that one is usually pretty up to date and easy to upgrade to new verisons. – Siliarus Nov 06 '18 at 07:51
  • @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 Nov 06 '18 at 08:52
  • 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 Nov 07 '18 at 12:00

1 Answers1

0

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

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
  • thank you. I believe your answer is right but I will wait for another couple of days. For option 1: I don't know how to do it so could you provide me with a link to an example. Option 2 & 3: My problem if I face a bug in the current our version of Weblogic12c 12.2.1.0 implementation in our customer site or in latest version 12.2.1.3 then we will have to go with workarounds if available or accept the drawback. Also upgrade is not easy as our customer has many old applications deployed next to ours. So I think I'll use JSF 2.2 with Spring till I figure out a solution – Karim Ahmed Nov 06 '18 at 06:18
  • Whats the benefit of using Spring here? MyFaces 2.3 still works without CDI, no idea if Mojarra 2.3 works without CDI. However, in JSF 3.x, CDI will be a required dependency. If you have to support many versions of JavaEE and JavaEE application servers, it would be the best to base your application on JSF 2.0 and CDI 1.0. This is supported since JavaEE6 and will likely even work with JavaEE9, if you don't use @ManagedBeans.... – tandraschko Nov 12 '18 at 18:20
  • 1
    Mojarra 2.3 still working without CDI but with a warning that @ManagedBean is deprecated. I meant to use spring as replacement of CDI but I believe now if we 'll going to use JSF, we should consider using JEE full stack for future project upgrade compatibility or use embedded JSF 2.2 with no intent to upgrade it with Spring. – Karim Ahmed Nov 26 '18 at 07:11