Replace @ManagedBean with @Named #2
Comments
|
Hi Antonio, |
|
Bonsoir Antonio, first of all I'm glad you discovered our project! As for your suggestion: actually, I had thought quite a few minutes about which annotations to choose. You know, the old JSF annotations may have been deprecated in Java EE 7, but there's no Another consideration is Spring. Personally, I'm very fond of CDI, but I didn't want to drive the Spring developers away, so I decided to use the old annotations. But maybe you're right: these days Spring supports @nAmed and @Inject, too. Best regards |
|
Funny thing is my new PollDemoBean accidentially uses the CDI annotations. So much for "I've thought about it thoroughly" :). |
|
Yes, Spring uses |
|
Maybe we should think about a pull request enhancing the SpringBeanAwareELResolver. It's not difficult to add the view scope to Spring, let alone the CDI request scope (see ViewScope and faces-config.xml). |
|
The classes using src/java/org/primefaces/showcase/view/input/CalendarView.java:@ManagedBean The classes using src/java/net/bootsfaces/demo/LoremIpsumBean.java:@RequestScoped |
|
Btw, Antonio, I see you have made a presentation titled "To inject or not to inject: CDI is the question": |
|
"choosing the right annotation is not always straightforward in JEE". Yes, I agree. I'll think of something simple... maybe a matrice with service == annotation (eg. transaction == @transactional, injection == @Inject). Something to blog about ;o) |
|
I would like to resurrect this issue, because as of JSR 330 CDI is part of Java EE 6, which is the minmal version BootsFaces supports. So using CDI should be an option for everyone who uses JSF 2.0+, since it's part of the same JEE specification. If we like to keep supporting JSF 2.0 in this showcase, we might just use OmniFaces' ViewScoped implementation, which offers CDI |
|
BootsFaces supports Java 6, not JavaEE 6 :). Modern application servers have become very good, but there are still a couple of developers using a pure Tomcat or even Spring with JSF. |
|
I misinterpreted However shouldn't be those limitation only be applied to the project itself? I just thought CDI won't hurt the showcase. But I also somehow understand the decision to keep things minimal. |
|
Thing is, our official showcase runs on Wildfly, but I run the same sources on a local Tomcat. It's easy to define a profile for the dependency. But that's not enough. You need some boiler plate code to activate CDI on a Tomcat. I didn't find out yet how to move that into a Maven profile. Plus, I'm not sure if the result is worth the pain. This kind of things tends to get ugly. But if there's a simple solution, I'm game! |
|
Now that JSF 2.3 is out and the old annotations are effectively deprecated, I think it's time to do the change. Also, have in mind that some JSF features now require CDI in order to work (like the new [FacesDataModel](https://javaserverfaces.java.net/nonav/docs/2.3/javadocs/javax/faces/model/FacesDataModel.html which is implemented as a CDI extension). For plain Servlet containers, instructions will need to be added on how to enable CDI. For Spring users, maybe we should point to http://joinfaces.org/. |
|
@TheCoder4eu @zhedar @ggam @asterd @chongma Which target platforms do we want to support with BootsFaces 1.1.0?
BTW, we can't support Spring because JSF is incompatible with it. For instance, the |
|
I use TomEE 7.0.2 with OpenJDK 1.8.0 on CentOS. TomEE is a packaging of the various EE libraries into a Tomcat installation. People should be upgrading to the new stuff but it depends how much you want to support backwards compatibility. My projects are already converted to CDI as I was told by Apache team that Apache team also told me that Oracle plan to deprecate javax.* in Java 1.9.0 and they are not quite sure what that will mean yet as they were originally told to put all the Enterprise stuff in the javax package. |
|
As I see it, it's just a matter of what JDK and JSF versions we want to
support.
For the JDK, I doubt anyone using BootsFaces is still bound to a version
lower than 7. Since this is a relatively new library, and new projects are
already targetting JDK 8 from quite some time.
Btw, all Java EE 8 specs will need JDK8, and I think the soon to be
released Spring 5 will also need it. App servers like WildFly also require
it.
I'd still wait a little more until requiring Java 8, just in case there's
someone still using 7. But I would upgrade it to 7 now and prepare a bump
to JDK 8 in the next versions (perhaps 1.5.0). People using old versions of
Java are usually also have restrictions to upgrade libraries.
For the JSF version, I'm fine with supporting JSF 2.0/2.1 (Java EE 6) but
not duplicating efforts already covered by newer versions. For example: JSF
2.2 provided a standard fileUpload compondent. I wouldn't duplicate classes
just to provide something similar for JSF 2.1 users. If we are going to
provide that component, we could restrict that to JSF 2.2 (which was
released on 2013).
For the annotations problem, we should look at the chronology:
- JSF 1.2 (2006): only managed beans are supported.
- JSF 2.0/2.1 (2009): CDI beans come into play with Java EE 6. Missing
@ViewScoped CDI version (available trough Deltaspike). No real benefits
between one and the other, apart from consistency (on Java EE servers).
- JSF 2.2 (2013): @ViewScoped CDI implementation. New @FlowScoped only
available with CDI. No more work is done on JSF managed beans as CDI is the
new way.
- JSF 2.3 (2017): managed beans finally deprecated. New @FacesDataModel
implemented as a CDI extension. Lots of work on improving CDI ingegration.
So I think we can now safely asume that JSF requires CDI, in the same way
that JPA may internally require JDBC.
Where people use JSF (Java EE server, Microprofile implementation, plain
Tomcat, etc) is out of context for me. CDI is not only about Java EE and
can be used on nearly every environment.
So for now on 1.1 I'd go for JDK7 (and upgrade to JDK8 sooner than later)
and JSF 2.1+ taking CDI for granted.
El dom., 9 de abril de 2017 10:45, Stephan Rauh <[email protected] om>
escribió:
… @TheCoder4eu <https://github.com/TheCoder4eu> @zhedar
<https://github.com/zhedar> @ggam <https://github.com/ggam> @asterd
<https://github.com/asterd> @chongma <https://github.com/chongma> Which
target platforms do we want to support with BootsFaces 1.1.0?
- Java 7
- Java 8
- Tomcat and Jetty
- Java EE only
BTW, we can't support Spring because JSF is incompatible with it. For
instance, the ViewScope is broken and won't be fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACAucHoOZ-_Yf8aRNwj5iccPBq6g_krCks5ruJqVgaJpZM4EtGLI>
.
|
|
The problem with embracing the CDI annotations is that we exclude the Spring Boot community. That doesn't bother me too much because Oracle already expels them actively, but still, it might reduce the acceptance of BootsFaces. The reason why I'd love to switch to Java 8 is defender methods. We've got a lot of boiler-plate code copied over and over again. Maybe the default methods of Java 8 could alleviate the pain. |
|
Have you taken a look at JoinFaces? It's JSF for SpringBoot and even
mentions BootsFaces: https://github.com/joinfaces/joinfaces
I'd also like to upgrade to Java 8 but I don't think default method per se
will solve that problems. Code duplication is a problem, but I think we
should first review what we have and then make a plan for action.
El dom., 9 de abril de 2017 23:23, Stephan Rauh <[email protected]>
escribió:
… The problem with embracing the CDI annotations is that we exclude the
Spring Boot community. That doesn't bother me too much because Oracle
already expels them actively, but still, it might reduce the acceptance of
BootsFaces.
The reason why I'd love to switch to Java 8 is defender methods. We've got
a lot of boiler-plate code copied over and over again. Maybe the default
methods of Java 8 could alleviate the pain.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACAucHVkYXigzJipyNQC7CouRHGnbJdQks5ruUxegaJpZM4EtGLI>
.
|
|
Yes, I know JoinFaces. I'm even loosely in contact with the author. Thing is, JoinFaces can't solve this problem: https://www.beyondjava.net/blog/updating-to-mojarra-2-2-11-may-break-your-spring-boot-application/ In fact, Manfred Riem told me that the JSF team won't even try to maintain compatibility to Spring. That's the root of the problem: if Oracle is eager to break compatibility with Spring, we can't do anything about it. Maybe they'll change their mind, but I don't think so. The current strategy of aligning everything with CDI makes so much sense, compatibility to Spring is a minor issue in comparison. |
|
So how does JoinFaces work if CDI beans are broken? I haven't used Spring nor Spring Boot. Not calling ServletContainerInitializers seems like an odd decision since the spec mandates Servlet containers to call them. I can't blame Mojarra's team for using that. Anyway, people using JSF with Spring must be aware of the limitations. I think we can confidently change our annotations to the CDI ones and create a new page about Spring and JoinFaces in the integrations section, explaining how to use them both. From what I read on the issues, it seems to work with MyFaces. Since Spring users are usually not tied to specific servers, why not just pointint them to MyFaces? |
|
Spring uses the |
|
Recommending MyFaces might be an interesting option. I didn't try that myself yet, but the approach sounds promising. |
In your JSF example, you use the JSF
@ManagedBeanand@RequestScopedannotations. Both have been pruned in Java EE 7 and should be deprecated in next version. Instead you should use the CDI@Namedand the CDI@RequestScoped.The text was updated successfully, but these errors were encountered: