If I deploy a #ManagedBean or CDI #Named JSF backing bean in one application EAR within a GlassFish domain and then deploy the same managed or named bean in a different application EAR within the same GlassFish domain, will this cause a collision or any problems?
For example, I have a LoginController class that is registered as a managed or named bean that I use for login to different applications. I also have some other common, horizontal utilities that are registered as managed or named beans that I would like to reuse across different applications deployed as different EARs that may or may not be deployed to the same GlassFish domain or server.
I have implemented this already and am wondering about the scope of managed or named beans relative to the GlassFish domains and across applications / EARs.
What is the best way to accomplish this within JEE and GlassFish?
Every application create it's own CDI context.
Which means applications does not use context of other application on your server.
Therefore you can use same names without any problems.
You can imagine the context as a big map with objects where each application has it's own map.
Related
This question already has answers here:
What components are MVC in JSF MVC framework?
(4 answers)
JSF Controller, Service and DAO
(2 answers)
Closed 5 years ago.
Good day
I am creating my first JSF based application. I am using:
Wildfly 11
PostgreSQL
Maven based project
IntelliJ Ultimate 2017.3
CentOS 7.4
Apache Shiro
Primefaces 6.1
The model portion of the application is the easy part as it is entities generated from the database using IntelliJ Ultimate's auto schema generation.
I am very confident using JPA and the #PersistanceContext to create an entity manager and use JPSQL.
The xhtml files using JSF tags and the EL language creates the front end and together with a #ViewScoped backing bean forms the view.
Where I am confused about is what should the controller portion consists of?
A problem I seem to frequently run into is getting null pointer exceptions and other errors related to backing bean methods when variables used in these methods have not been properly initialized, especially lists that have to be retrieved from the database using JPA where parameters used in the em queries still needs to be set in the form (but the forms fail to display due to uninitialized variables).
So, I have a questions, and would really appreciate enlightenment.
How do I prevent these null pointer exceptions?
If all the DB 'stuff' is moved to 'controller' beans, and the view backing beans only call the methods in the controller beans, will this eliminate my null pointer exceptions?
What must (according to best practices) a view backing bean contain?
What must (according to best practices) a controller bean contain and be responsible for?
Any advice would be most appreciated.
I read some post hear (specially BalusC post) and googled for the reason (not deep) but i couldn't find why shouldn't use entity bean as a managed bean. what's the reason? (I'm learning from "Pro JSF and HTML5" and in this book, entity bean is used as a managed bean.)
Separation of concerns.
Normally, enterprise applications are developed and deployed as EARs instead of WARs. A typical EAR project consists of an EJB subproject as "back-end" and a WAR subproject as "front-end". The EJB subproject contains all JPA entities and EJB services. The WAR subproject contains all JSF managed beans and views (and what not closely related to JSF such as converters, validators, phase listeners, etc).
A good EJB subproject may not have any dependency on JSF. This makes it reusable for different front-ends, such as Spring MVC, JAX-RS, Struts2, plain JSP/Servlet or even a desktop oriented Swing application. This also means that no one of your JPA entities and EJB services should have any javax.faces.* import/dependency in the class. Having for example a FacesContext at hands inside a JPA entity or EJB service is alarming as that doesn't necessarily exist in other front-ends.
The "Pro JSF and HTML5" concentrates on simple WAR projects. Therein that's "okay" in order to show the possibilities and/or to keep the examples "simple", but that's actually misleading to starters once they grow into developing enterprise applications, the more so if the book doesn't cover the design concern in detail.
See also:
JSF Service Layer
Packaging EJB in JavaEE 6 WAR vs EAR - related answer from my colleague Arjan.
What is the difference between
import javax.annotation.ManagedBean;
import javax.enterprise.context.SessionScoped;
and
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
?
javax.enterprise.context.SessionScoped(JSR 346) and all other annotations under the javax.enterprise.context.* package maintain the context of CDI. CDI provides an alternative, versatile and more powerful mechanism for dependency injection, bean and general resource management within the Java EE space. It's an alternative to JSF managed beans and it's set to even supersede the JSF bean management mechanism in the coming version of JSF.
Currently, JSF and CDI annotated beans are interchangeable within any given Java EE web application (given a handful of minor restrictions). CDI annotated beans however, extend far beyond the realm of the web tier, which is why the Java EE spec is evolving to make CDI the standard bean and DI mechanism.
While CDI might be an obvious choice for all Java EE development, JSF managed beans are portable across servlet containers (Tomcat) and application servers (Glassfish, JBoss, etc.). CDI beans can live within only full application servers. With some legwork however, Tomcat 7 can be wired to support CDI.
Specifically, javax.enterprise.context.SessionScoped is the parallel implementation of the JSF Session Scope within CDI.
javax.faces.bean.SessionScoped (JSR 314) and all other annotations under the javax.faces.bean.* package maintain the JSF-specific dependency injection and bean management mechanism. Beans annotated with JSF annotations however are only useful within the web tier. All the scopes available with JSF annotations have been replicated within the CDI specification.
javax.annotation.ManagedBean (JSR 316) and other DI-related annotations under javax.annotation.* are an attempt to generalize the JSF-based annotations for other uses within the Java EE spec and really shouldn't be used by the end-developer.
Why they exist? Well IMO, the move from JSF beans to CDI beans is a natural evolution of the technology. JSF beans have had a good run but the likes of Spring, Guice and Seam made it obvious that the technology was not sufficient. There was also a need to bridge the gap between the web components and EJBs, and the response to that need is CDI.
See these related questions too:
JSF: Backing beans (#ManagedBean) or CDI Beans (#Named)?
Java EE 6 #javax.annotation.ManagedBean vs. #javax.inject.Named vs. #javax.faces.ManagedBean
I am trying to learn the concepts of Java EE (EJB,JSF...) and therefore I am working on an example application.
Unfortunately I have problems to understand how some concepts should work together and if I am doing it in an correct professional manner. At this point, I am really confused about all these different methods and hope someone can help me out.
The core functionality of my application consists of a document server where registered users can upload documents and describe it with useful information.
The Documents should simply be saved on the Server and all Information should be stored in a MySQL Database.
I created three Projects with Netbeans.
Enterprise Application Project (DocApp)
EJB Module (DocApp-ejb)
and a Web Application Project (DocApp-war).
The main things work fine like
accessing the database with JPA
uploading files with primefaces FileUploader
injecting JSF with EJB
and even the user authorization with JDBC-Realm as shown in this tutorial
http://jugojava.blogspot.de/2011/02/jdbc-security-realm-with-glassfish-and.html
My Problem now is, that all pages in a specific subdirectory should only be accessible by registered users.
The only way i see is to use one SessionScoped ManagedBean, instead of using multiple RequestScoped ManagedBeans .
This seems to be a bad practice but I have no Idea how to handle this otherwise.
The way i understand it, there should be one ManagedBeand for every JSF Page (xhtml).
Is there a good way to handle this or am i doing anything wrong?
The default mechanism to give access to a whole sub directory is adding a security constraint in web.xml for the URL pattern representing that directory.
Every registered user should get a role that represents being registered, eg "REGISTERED"
This role is then added to the security constraint in web.xml.
The interaction between JSF and the Servlet container managed security is a little awkward, but it does work.
I have a few questions on the various options and best practices when using JSF with EJB3.1. The mental model I have, given the daunting amount of choices and combinations available, is far from clear so some questions may not make sense.
JSF/Facelets reference backing beans (I am using the term "backing bean" for beans whose properties are written or read from Facelets pages) through EL code that is agnostic as to the actual annotations used in the bean classes (javax.faces.bean.* or javax.enterprise.context.*).
Is it correct to say that one can toggle between JSF and CDI scope annotations just by changing the imports in the bean classes without any changes to the Facelets xhtml code?
Is it an established pattern that JSF/Facelets should be used only for the xhtml markup code with all scope and lifecycle (plus injection) annotations done using CDI?
In a JBoss AS setting, where is the lifecycle management of the JSF backing beans (using either JSF or CDI annotations) taking place? In the web container or in the EJB3 container?
In a typical web application given that the SessionScoped beans can be provided by CDI, is there any need for using EJB3 beans other than those of type #Entity, e.g. for the last typical step in each "flow" when information is to be persisted in the database?
Is it correct to say that one can toggle between JSF and CDI scope annotations just by changing the imports in the bean classes without any changes to the Facelets xhtml code?
Yes.
Is it an established pattern that JSF/Facelets should be used only for the xhtml markup code with all scope and lifecycle (plus injection) annotations done using CDI?
JSF is moving towards CDI. The new #FlowScoped annotation of the upcoming JSF 2.2 is evidence of this as this extends from the CDI API. The only disadvantage is that CDI doesn't offer a standard annotation for the tremendously useful JSF #ViewScoped annotation. You'd need #ConversationScoped wherein you manually start and end the conversation, or take a look at a CDI extension like MyFaces CODI.
In a JBoss AS setting, where is the lifecycle management of the JSF backing beans (using either JSF or CDI annotations) taking place? In the web container or in the EJB3 container?
The web container (in flavor of a WAR). JSF is built on top of the Servlet API, so it's definitely the web container.
In a typical web application given that the SessionScoped beans can be provided by CDI, is there any need for using EJB3 beans other than those of type #Entity, e.g. for the last typical step in each "flow" when information is to be persisted in the database?
The #Entity is part of JPA, not of EJB. The #Entity is to be used on a model class which is mapped to a database table and usually solely meant to transfer data across the layers. What you're last describing sounds like candidate for a #Stateful EJB. To understand #Stateless vs #Stateful EJBs better, head to this detailed answer: JSF request scoped bean keeps recreating new Stateful session beans on every request?