I would like to know which is good practice. For example, I have Person pojo for Entity Class,PersonService EJB stateless session bean for persisting Person class and indexBean(CDI request Scope bean)for binding with JSF to create Person class. Is it good to create new Person Object in indexBean instead of using #Inject?
If not, could you show me how should i design for this scenario? Thanks.
According to the CDI documentation of weld, you should not inject Entity beans:
According to this definition, JPA entities are technically managed beans. However, entities have their own special lifecycle, state and identity model and are usually instantiated by JPA or using new. Therefore we don’t recommend directly injecting an entity class. We especially recommend against assigning a scope other than #Dependent to an entity class, since JPA is not able to persist injected CDI proxies.
You can find further information here.
You shoud create a new Person object / or load it from Database (by your PersonService) in your indexBean, depending on your usecase. Also the persistence of the Person entity will finally be done by your PersonService.
Related
Do you think it is a good idea to put all widely used utility methods in an application scoped bean?
In the current implementation of the application I'm working on, all utility methods (manipulating with Strings, cookies, checking url, checking current page where the user is etc.) are all put in one big request scoped bean and they are referenced from every xhtml page.
I couldn't find any information on stackoverflow if the approach of putting utility methods in an application scoped bean would be a good or a bad choice.
Why I came across this idea is the need of reusing those methods in a bean of a wider scope then a request scoped bean (like view or session scoped bean). Correct me if I'm wrong but you should always inject same or wider scoped beans i.e. you shouldn't inject request scoped bean inside a view scoped one.
I think using utility methods from application scoped bean should be beneficial (there won't be any new object creations, one object will be created and re-used across all application), but still I would like a confirmation or someone to tell me if that is a wrong approach and why is it wrong.
As to the bean scope, if the bean doesn't have any state (i.e. the class doesn't have any mutable instance variables), then it can safely be application scoped. See also How to choose the right bean scope? This all is regardless of the purpose of the bean (utility or not). Given that utility functions are per definition stateless, then you should definitely be using an application scoped bean. It saves the cost of instantiating on every single request.
As to having utility methods in a managed bean, in object oriented perspective this is a poor practice, because in order to access them from EL those methods cannot be static while they should be. You can't use them as real utility methods in other normal Java classes. Static code analyzers like Sonar will mark them all with a big red flag. This is thus an anti-pattern. The correct approach would be to keep using a true utility class (public final class with private Constructor() with solely static methods) and register all those static methods as EL functions in your.taglib.xml as described in How to create a custom EL function to invoke a static method?
At least, this is what you should be doing when you intend to have a publicly reusable library such as JSTL fn:xxx(), PrimeFaces p:xxx() or OmniFaces of:xxx(). If you happen to use OmniFaces, then you could, instead of creating a your.taglib.xml file, reference the class in <o:importFunctions>. It will automatically export all public static methods of the given type into EL function scope.
<o:importFunctions type="com.example.Utils" var="u" />
...
<x:foo attr="#{u:foo(bean.property)}" />
If you don't use OmniFaces, and this all is for internal usage, then I can imagine that it becomes tiresome to redo all that your.taglib.xml registration boilerplate for every tiny utility function which suddenly pops up. I can rationalize and forgive abusing an application scoped bean for such "internal usage only" cases. Only when you start to externalize/modularize/publicize it, then you should really register them as EL functions and not expose poor practices into public.
I need to call a method annotated with #Asynchronous in EJB from a ConversationScoped bean. Inside this method I create instances of some classes using #Inject to inject ConversationScoped beans.
Is it somehow possible to set the context of the asynchronous method to given Conversation?
I hope you can help me.
No, absolutely not. EJBs do per definition not run in web container, but in EJB container. In essence, having any web-related artifact/dependency (including javax.faces.* classes) inside an EJB class is a red alert. You're not supposed to inject/access any class from the client tier (the WAR) in the business tier (the EJB/EAR). Moreover, conversation scoped beans are tied to a HTTP request parameter and this information is nowhere available in an EJB container.
Whatever problem you're trying to solve and for which you incorrectly thought that this all would be the right solution, it has to be solved differently. As an educated guess, I think you just need to let the EJB fire a CDI event or take a callback argument.
See also:
JSF Service Layer
JSF is capable to automatically validate objects connected with form. F.e. with have entity Person with bean validation in there. We can populate entity with form using {form.entity.field}. JSF managed bean is forced to have entity with entity getter getEntity() (to do automatic validation using annotations in another object).
On the other side, such a solution is not preferable and I should use dtos in jsf managed beans. Unfortunately, I want bean validation logic keep only in one place - entity.
Is it possible to validate entity dto's with annotations from entity (not copying) automatically with jsf (no or little code, using embedded jsf bean validator for jsr-303)?
In a small project of accounts' management, I've one EJB entity, one EJB stateless, one managed bean (faces-config.xml, with session scope). For presentation tiers, I've some pages that handle with this EJB entity (add an instance to the DataBase, insertion, update, deletion, etc.), everything is alright with DB.
However, when, for exemple, I identify myself, and go to account's creation page, I find the fields (<h:outputText />) of the EJB entity are all filled with the account I used for identification.. i tried to use callback methods for EJB entities & EJB stateless, but did not resolved it.
In brief, the objective is to "free" the memory from the instance of this EJB entity (declared as attribute in the managed bean class) in order to find the fields empty whenever I consult them.
How to do that ?
Implementing a simple Login screen using JSF and Spring and Hibernate. I have written the Service and Data Layer Beans in Spring and integrated them with Hibernate.
I defined a Sign Up (new User creation) screen with two fields user id, password in JSF and wired them to a Managed Bean. (Bean Name: Users) Here this bean is also the domain class.
Now on click of the create button in JSF view I need to call the Service Bean methods (which are spring beans). For this I see that I have two ways to do,
Write a method in Users managed bean that takes the given user, password and calls the spring service bean methods which in turn calls DAO bean methods for saving data in DB. But here my question is how far it is a good practise to write controller kind of method in Domain classes?
Second way is to define a new Managed Bean that has the Spring Service object as a property (Which is injected using spring+jsf integration) and a method to call the service bean methods.
Am I doing a correct design? Any thing wrong? Please suggest me for a better design.
Thanks
Dont make your domain class as jsf managed bean.
Generally what I follow is I encapsulate domain class and other UI supporting properties in a form bean(when scenario is complex else direct entity as a property in managed bean) and have it in managed bean.
Spring service is injected in managed bean and on action form bean/entity bean is passed to spring service for business/use case processing and persistence(dao/repository).
Template Code:
#ManagedBean
public class Bean{
private Entity entity;//or
private FormBean formBean;
#Inject private Service service;
public String doAction(){
//error processing from service layer and UI message handling
service.process(entity);//or
service.process(formBean);
return Navigation.Constant;
}
}
Managed bean purpose should be to collect view data and pass it to service for processing. If you make your domain/entity class as managed bean you will be coupling it with JSF library which is not good for reusability. As per design principle SRP(single responsibility principle), class should have one responsibility in that case it will have more and hence as mentioned above not good practice.
Point 2 as mentioned by you is better.
Hope this helps !!!!