search

TheCoder4eu / BootsFacesWeb

BootsFaces : the next gen JSF Framework Web Docs
Apache License 2.0
36 stars 32 forks source link

Replace @ManagedBean with @Named #2

Open agoncal opened 9 years ago

agoncal commented 9 years ago

In your JSF example, you use the JSF @ManagedBean and @RequestScoped annotations. Both have been pruned in Java EE 7 and should be deprecated in next version. Instead you should use the CDI @Named and the CDI @RequestScoped.

TheCoder4eu commented 9 years ago

Hi Antonio, thank you very much for pointing this out, I'll change it ASAP!

stephanrauh commented 9 years ago

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 @deprecated in the JSF 2.2 source code, so Eclipse won't tell me about it. BTW, BootsFaces is also targeted at JSF 2.0 and 2.1, both of which don't support CDI. As a consequence, the dependency tree of our showcase project doesn't include the javax.inject.jar.

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 Stephan

stephanrauh commented 9 years ago

Funny thing is my new PollDemoBean accidentially uses the CDI annotations. So much for "I've thought about it thoroughly" :).

agoncal commented 9 years ago

Yes, Spring uses @Named and @Inject. Unfortunately it doesn't support the CDI @RequestScoped. Java EE being built more and more on CDI, and Spring that doesn't support it... I think that, unfortunately, both programming model will start to shift and you will have to choose one or the other :o(

stephanrauh commented 9 years ago

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).

TheCoder4eu commented 9 years ago

The classes using @ManagedBean are:

src/java/org/primefaces/showcase/view/input/CalendarView.java:@ManagedBean src/java/net/bootsfaces/demo/BarcodeBean.java:@ManagedBean src/java/net/bootsfaces/demo/LoremIpsumBean.java:@ManagedBean src/java/net/bootsfaces/demo/SettingsBean.java:@ManagedBean src/java/net/bootsfaces/demo/InformBean.java:@ManagedBean src/java/net/bootsfaces/demo/TestBean.java:@ManagedBean(name = "testBean") src/java/net/bootsfaces/demo/ClockBean.java:@ManagedBean src/java/net/bootsfaces/demo/ItemBean.java:@ManagedBean src/java/net/bootsfaces/demo/SemaphoreBean.java:@ManagedBean src/java/net/bootsfaces/demo/DateBean.java:@ManagedBean(name = "dateBean") src/java/net/bootsfaces/demo/CarBean.java:@ManagedBean src/java/net/bootsfaces/issues/issue78/SoccerTeamBean.java:@ManagedBean

The classes using @RequestScoped are:

src/java/net/bootsfaces/demo/LoremIpsumBean.java:@RequestScoped src/java/net/bootsfaces/demo/SettingsBean.java:@RequestScoped src/java/net/bootsfaces/demo/InformBean.java:@RequestScoped src/java/net/bootsfaces/demo/TestBean.java:@RequestScoped src/java/net/bootsfaces/demo/ClockBean.java:@RequestScoped src/java/net/bootsfaces/demo/ItemBean.java:@RequestScoped src/java/net/bootsfaces/demo/DateBean.java:@RequestScoped

TheCoder4eu commented 9 years ago

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...

agoncal commented 9 years ago

"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)

zhedar commented 8 years ago

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. The only part of CDI, which requires JSF 2.2 and therefore Java EE 7 is CDI's missing support of JSF's ViewScoped.

If we like to keep supporting JSF 2.0 in this showcase, we might just use OmniFaces' ViewScoped implementation, which offers CDI ViewScoped support in both JSF 2.0 and 2.1. We have a dependency to OmniFaces anyway, so might as well use that.

stephanrauh commented 8 years ago

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.

zhedar commented 8 years ago

I misinterpreted BootsFaces is targeted at Java EE 6/7 and requires a Java 1.6 or later VM. in the requirements then, my bad. I just know, that PrimeFaces requires the jee6-spec and therefore it would be something, that most libraries do.

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.

stephanrauh commented 8 years ago

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!

ggam commented 7 years ago

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/.

stephanrauh commented 7 years ago

@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 ViewScope is broken and won't be fixed.

chongma commented 7 years ago

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 @ManagedBean was going to be deprecated as Oracle is trying to standardise all the managed containers into one - hopefully eventually including Spring. It was a fairly painless conversion just required changing the annotations.

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.

ggam commented 7 years ago

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:

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 <notifications@github.c 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 https://github.com/TheCoder4eu/BootsFacesWeb/issues/2#issuecomment-292772975, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAucHoOZ-_Yf8aRNwj5iccPBq6g_krCks5ruJqVgaJpZM4EtGLI .

stephanrauh commented 7 years ago

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.

ggam commented 7 years ago

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 notifications@github.com 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 https://github.com/TheCoder4eu/BootsFacesWeb/issues/2#issuecomment-292814057, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAucHVkYXigzJipyNQC7CouRHGnbJdQks5ruUxegaJpZM4EtGLI .

stephanrauh commented 7 years ago

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.

ggam commented 7 years ago

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?

stephanrauh commented 7 years ago

Spring uses the SpringBeanFacesELResolver to map JSF annotations to Spring beans. So Spring and Spring Boot don't use CDI at all. The just use the same annotations. Most of the time, you won't notice the difference, but advanced JSF feature simply won't work. Such as the ViewScope.

stephanrauh commented 7 years ago

Recommending MyFaces might be an interesting option. I didn't try that myself yet, but the approach sounds promising.