I have 2 #SessionScoped beans in my small application. Even when I restart of clean the server, all of the form values are retained.
#ManagedBean(name = "bill")
#SessionScoped
public class Bill implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
private static final String MANAGED_BEAN_NAME = "bill";
/**
* #return the current instance of Bill
*/
public static Bill getCurrentInstance() {
return (Bill) FacesContext.getCurrentInstance().getExternalContext()
.getSessionMap().get(MANAGED_BEAN_NAME);
}
//other methods
}
#ManagedBean
#SessionScoped
public class TailorTip implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
private Bill bill;
private Participants[] participants;
private Integer participantIndex;
#PostConstruct
public void init() {
bill = Bill.getCurrentInstance();
}
//other methods
}
How do I avoid the retention of values? Note: I use tomcat.
This is indeed fully expected. Many servers save and restore sessions on restart, so that the endusers can continue with their website sessions. This is under the covers achieved by Java serialization. That's also exactly the reason why session scoped beans needs to implement Serializable.
As to the solution, there are several ways to fix this:
Put the bean in the right scope for the job. Are you absolutely sure that they need to be session scoped? Isn't the view scope a better fit for those beans, after all? The session scope is usually only used for client-specific information, such as logged-in user, its preferences, etc, and thus not for form data. Your apparent urgent need to clear them on every server restart confirms that the session scope is the wrong choice. See also How to choose the right bean scope?
Get rid of Serializable interface declaration in the class. This way they'll fail to be revived on server restart.
Tell Tomcat to not revive sessions on server restart. Edit context.xml to add a <Manager> element with an empty pathname to the <Context> element.
<Context ... >
<Manager pathname="" />
</Context>
See also:
JSF managed bean causing java.io.NotSerializableException during Tomcat deployment
If they're session scoped, then many servers retain session information across restarts. If you redeploy the application, then the information will be cleared. But simply restarting the application will not reset it. You'd have to consult your servers documentation to disable session persistence across server restarts.
Related
First I'd like to clear out that I know what a NullPointerException is and how to handle that. My question is about how to access the #ApplicationScoped bean that is created on server startup, through the scheduler that I would like to run once a day. All I get now is a new bean, which is null at the beginning and not the already created bean.
The scheduler does the initiation of the bean so I end up with two beans, one that is updated by the scheduler (all the time) and one that is used when navigating in the web application.
So...
I have a web application with a #ApplicationScoped bean. This one is loaded from database on Tomcat startup.
This means that if something is changed in database in some other way than through the web application the changes won't be viewable until the Tomcat has been restarted.
So I thought I could make a Schedule to reload this #ApplicationScoped bean on a specific time during the day. The trouble is that I get a whole new #ApplicationScoped bean.
So how should I do to get the current bean updated and not a new one?
I've tried the solution in this tread: Refresh/Reload Application scope managed bean without any luck. My bean is still null.
I've also looked at the following threads without really solving my problem:
application scoped bean's view is not updated
Access ApplicationScoped bean through ServletContext
My ApplicationBean.java
import javax.enterprise.context.ApplicationScoped;
#Named(value = "applicationBean")
#ApplicationScoped
public class ApplicationBean {
#PostConstruct
public void init() {
//load variables from db
}
}
My ScheduleTaskConfig.java
#WebListener
public class ScheduleTaskConfig implements ServletContextListener {
private ScheduledExecutorService scheduler;
#Override
public void contextInitialized(ServletContextEvent event) {
Reloader reloader = new Reloader(event.getServletContext());
scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(reloader, 2, 3, TimeUnit.MINUTES);
}
#Override
public void contextDestroyed(ServletContextEvent sce) {
scheduler.shutdownNow();
}
}
My Reloader.java
public class Reloader implements Runnable {
private ServletContext context;
public Reloader(ServletContext context) {
this.context = context;
}
#Override
public void run() {
ApplicationBean applicationBean = (ApplicationBean) context.getAttribute("applicationBean");
if (applicationBean != null) {
applicationBean.init();
}
}
}
I just don't know what is wrong. I don't understand how to solve this.
I know I've written that the schedule should run every 3 minutes but when I get this to work the schedule should run once a day.
Is there a better way to do this or have I just forgotten something? I've googled the whole day without getting forward so I really need help.
Thank you.
Edited:
So my servlet context is up and my listener is notified before my application context is up?
What if I use the webpage then my application context is up (?) but my scheduler still doesn't work, the bean in the scheduler is still a new one and not the one I've been using when navigating in the web application. Or am I just confused over this? :)
Thank you for your help.
Edited:
I'm using Primefaces 6.0 and I suppose this bean is a JSF bean. Other beans used are Spring beans imported from a model class. Sorry for the confusion I have removed the Spring notation and added Primefaces instead.
I hope this clears things out. Thank you
I'm trying to get used to how JSF works with regards to accessing data (coming from a spring background)
I'm creating a simple example that maintains a list of users, I have something like
<h:dataTable value="#{userListController.userList}" var="u">
<h:column>#{u.userId}</h:column>
<h:column>#{u.userName}</h:column>
</h:dataTable>
Then the "controller" has something like
#Named(value = "userListController")
#SessionScoped
public class UserListController {
#EJB
private UserListService userListService;
private List<User> userList;
public List<User> getUserList() {
userList = userListService.getUsers();
return userList;
}
}
And the "service" (although it seems more like a DAO) has
public class UserListService {
#PersistenceContext
private EntityManager em;
public List<User> getUsers() {
Query query = em.createQuery("SELECT u from User as u");
return query.getResultList();
}
}
Is this the correct way of doing things? Is my terminology right? The "service" feels more like a DAO? And the controller feels like it's doing some of the job of the service.
Is this the correct way of doing things?
Apart from performing business logic the inefficient way in a managed bean getter method, and using a too broad managed bean scope, it looks okay. If you move the service call from the getter method to a #PostConstruct method and use either #RequestScoped or #ViewScoped instead of #SessionScoped, it will look better.
See also:
Why JSF calls getters multiple times
How to choose the right bean scope?
Is my terminology right?
It's okay. As long as you're consistent with it and the code is readable in a sensible way. Only your way of naming classes and variables is somewhat awkward (illogical and/or duplication). For instance, I personally would use users instead of userList, and use var="user" instead of var="u", and use id and name instead of userId and userName. Also, a "UserListService" sounds like it can only deal with lists of users instead of users in general. I'd rather use "UserService" so you can also use it for creating, updating and deleting users.
See also:
JSF managed bean naming conventions
The "service" feels more like a DAO?
It isn't exactly a DAO. Basically, JPA is the real DAO here. Previously, when JPA didn't exist, everyone homegrew DAO interfaces so that the service methods can keep using them even when the underlying implementation ("plain old" JDBC, or "good old" Hibernate, etc) changes. The real task of a service method is transparently managing transactions. This isn't the responsibility of the DAO.
See also:
I found JPA, or alike, don't encourage DAO pattern
DAO and JDBC relation?
When is it necessary or convenient to use Spring or EJB3 or all of them together?
And the controller feels like it's doing some of the job of the service.
I can imagine that it does that in this relatively simple setup. However, the controller is in fact part of the frontend not the backend. The service is part of the backend which should be designed in such way that it's reusable across all different frontends, such as JSF, JAX-RS, "plain" JSP+Servlet, even Swing, etc. Moreover, the frontend-specific controller (also called "backing bean" or "presenter") allows you to deal in a frontend-specific way with success and/or exceptional outcomes, such as in JSF's case displaying a faces message in case of an exception thrown from a service.
See also:
JSF Service Layer
What components are MVC in JSF MVC framework?
All in all, the correct approach would be like below:
<h:dataTable value="#{userBacking.users}" var="user">
<h:column>#{user.id}</h:column>
<h:column>#{user.name}</h:column>
</h:dataTable>
#Named
#RequestScoped // Use #ViewScoped once you bring in ajax (e.g. CRUD)
public class UserBacking {
private List<User> users;
#EJB
private UserService userService;
#PostConstruct
public void init() {
users = userService.listAll();
}
public List<User> getUsers() {
return users;
}
}
#Stateless
public class UserService {
#PersistenceContext
private EntityManager em;
public List<User> listAll() {
return em.createQuery("SELECT u FROM User u", User.class).getResultList();
}
}
You can find here a real world kickoff project here utilizing the canonical Java EE / JSF / CDI / EJB / JPA practices: Java EE kickoff app.
See also:
Creating master-detail pages for entities, how to link them and which bean scope to choose
Passing a JSF2 managed pojo bean into EJB or putting what is required into a transfer object
Filter do not initialize EntityManager
javax.persistence.TransactionRequiredException in small facelet application
It is a DAO, well actually a repository but don't worry about that difference too much, as it is accessing the database using the persistence context.
You should create a Service class, that wraps that method and is where the transactions are invoked.
Sometimes the service classes feel unnecessary, but when you have a service method that calls many DAO methods, their use is more warranted.
I normally end up just creating the service, even if it does feel unnecessary, to ensure the patterns stay the same and the DAO is never injected directly.
This adds an extra layer of abstraction making future refactoring more flexible.
I'm working on a JSF application with JPA and CDI; I use the following backend architecture:
Controllers (CDI annotation for JSF process)
Services (CDI annotations to be injected into Controllers and other Services)
DAOs (handled with EntityManager)
My question is, how should exactly be EntityManager and transactions be handled?
For example transactions (I don't use EJB or Deltaspike, so no declarative transactions available) should be managed by the Service layer (am I right?), but each data-releated other operation should be handled by the DAOs. So where should EntityManager be injected?
Also, should EntityManager be request (or session or method) scoped?
Thanks,
krisy
I would use service layer to manage a business logic and data access layer to manage object-relational model. As a consequence of the above, entity manager and transactions should be part of DAO. It's important to keep transactions as short as possible.
The decision which type of scope to choose is not so obvious as it depends on the nature of your bean/application. An example usage followed by this presentation, slide #15:
#RequestScoped: DTO/Models, JSF backing beans
#ConversationScoped: multi-step workflow, Shopping cart
#SessionScoped: User login credentials
#ApplicationScoped: Data shared by entire app, Cache
As you can see a scope of a given bean and the related entity manager is specific for the problem it concerns. If a given bean is request scoped its state is preserved for a single HTTP request in the same HTTP session. For a session scoped bean the state is maintained through HTTP session. An example approach may look somehow like the following (pseudocode):
#SessionScoped // conversation, application scoped as well
public class ServiceImpl implements Service {
#Inject
private Dao dao;
public void createSomething(SomeDto dto) {
// dto -> entity transformation
dao.create(entity);
}
public SomeDto getSomething(int id) {
SomeEntity entity = em.findById(id);
// entity -> dto transformation
return dto;
}
}
#RequestScoped
#Transactional
public class DaoImpl implements Dao {
#Inject
private EntityManager em; //creating em is cheap
// TxType.REQUIRED by default
public void create(SomeEntity entity) {
em.persist(entity);
}
#Transactional(TxType.NOT_SUPPORTED)
public SomeEntity findById(int id) {
return em.find(SomeEntity.class, id);
}
}
In my application i have a service that performs heavy loading (parsing of different files) up on creation. The data is metadata, so wont change during runtime (localized strings, key/value mappings, etc.) Therefore I decided to make this Service SessionScoped, so I don't need to parse the values with every request. Not ApplicationScoped to make sure the data is refreshed, when the user logs in again.
this works pretty well, but now i need to access that service inside a thread, that is run with the #Schedule Annotation. Of course Weld does not like that and says: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.SessionScoped
#Singleton
public class DailyMails {
#Inject
MailService mailService; //just Named
#Inject
GroupDataService groupDataService; //Stateless
#Inject
LocalizationService localizationService; //SessionScoped
#Schedule(hour = "2", minute = "0", second = "0", dayOfWeek="Mon,Tue,Wed,Thu,Fri", persistent = false)
public void run() {
//do work
}
}
Can I manually create a Session at this point, so that I can use the SessionScoped service?
Edit: I know, that a Service should not ne SessionScoped nor should it hold any Data(-Collections). However in this Situation it seems legit to me to avoid multiple File-System accesses.
I thought about making the Service to a unscoped service and "cache" the data in a session scoped bean. However then I would need to inject the session bean to that Service, which will
again make the service kind of "session scoped".
Shouldn't this work:
#Inject #New
LocalizationService localizationService;
At least, that's how I interpret the specification.
I need to run some code when the FacesServlet starts, but as FacesServlet is declared final I can not extend it and overwrite the init() method.
In particular, I want to write some data to the database during development and testing, after hibernate has dropped and created the datamodel.
Is there a way to configure Faces to run some method, e.g. in faces-config.xml?
Or is it best to create a singleton bean that does the initialization?
Use an eagerly initialized application scoped managed bean.
#ManagedBean(eager=true)
#ApplicationScoped
public class App {
#PostConstruct
public void startup() {
// ...
}
#PreDestroy
public void shutdown() {
// ...
}
}
(class and method names actually doesn't matter, it's free to your choice, it's all about the annotations)
This is guaranteed to be constructed after the startup of the FacesServlet, so the FacesContext will be available whenever necessary. This in contrary to the ServletContextListener as suggested by the other answer.
You could implement your own ServletContextListener that gets notified when the web application is started. Since it's a container managed you could inject resources there are do whatever you want to do. The other option is to create a #Singleton ejb with #Startup and do the work in it's #PostCreate method. Usually the ServletContextListener works fine, however if you have more than one web application inside an ear and they all share the same persistence context you may consider using a #Singleton bean.
Hey you may want to use some aspects here. Just set it to run before
void init(ServletConfig servletConfig)
//Acquire the factory instances we will
//this is from here
Maybe this will help you.