I am writing bean validation on my persistence model. I need to call my EJB Bean in order to retrieve some configuration parammeter from DB. How can I achieve this?
I tried to mark my EntityValidator as #Stateless and #LocalBean, but JBoss is still treats my EntityValidator as POJO. Can I do something about it? Alternatively, how can I retrieve EJB from POJO.
As of Bean Validation 1.0, you can't get EJBs injected into validators out of the box. This will change with Bean Validation 1.1, though.
Currently you have the following possibilities:
Retrieve the EJB via JNDI: MyEjb myEjb = InitialContext.doLookup(myEjbName);
Implement a custom ConstraintValidatorFactory which injects EJB references into created validator objects
Use Seam Validation, which enables dependency injection for validator objects using #Inject (disclaimer: I'm the author of Seam Validation)
With Bean 1.1 this will be possible out of box.
Currently, injection is not working in validators.
I've read that there are plans for future extension of bean validaton to enable exactly that behaviour.
However, there should be extension like seam or deltaspike, which could enabled you to provide injection.
Check this:
injection in validators
I don't think jboss will inject your bean to the JPA validator.
You can use JDNI to lookup your EJB for POJO.
Related
I feel there is a little mess in the Java EE 6 spec. There are several sets of annotations.
We have javax.ejb annotations like #Stateful and #Stateless for creating EJBs.
There is also a #javax.annotation.ManagedBean to create a managed bean.
There are annotations in javax.enterprise.context like #SessionScoped and #RequestScoped.
What is more there are also #ManagedBean and #SessionScoped/#RequestScoped annotations in javax.faces.bean package.
And to make things event more complicated there is a package javax.inject with #Named annotation.
Can someone please describe how they are related one to another?
Where can I use #EJB, #Inject or #ManagedPropery to inject other beans?
First of all let me do some clarifications:
Managed bean definition : generally a managed bean is an object that its life cycle (construction, destruction, etc) is managed by a container.
In Java ee we have many containers that manage life cycle of their objects, like JSF container, EJB container, CDI container, Servlet container, etc.
All of these containers work kind of independent, they boot in application server initialization and scan classes of all artifacts including jar, ejb-jar, war and ear files in deployment time and gather and store some metadata about them, then when you need an object of a class at runtime they will give you instances of those classes and after finishing the job, they will destroy them.
So we can say that we have:
JSF managed beans
CDI managed beans
EJB managed beans
And even Servlets are managed beans because they are instantiated and destroyed by a container, which is a servlet container.
So when you see the Managed Bean word, you should ask about the context or type of it.(JSF, CDI, EJB, etc.)
Then you might ask why we have many of these containers: AFAIK, Java EE guys wanted to have a dependency injection framework, but they could not gather all requirements in one specification because they could not predict the future requirements and they made EJB 1.0 and then 2.0 and then 3.0 and now 3.1 but EJB's target was for just some requirements (transaction, distributed component model, etc).
At the same time (in parallel) they realized that they need to support JSF too, then they made JSF managed beans and another container for JSF beans and they considered it a mature DI container, but still it was not complete and mature container.
After that Gavin King and some other nice guys ;) made CDI which is the most mature DI container I've seen. CDI (inspired by Seam2, Guice and Spring) was made to fill the gap between JSF and EJB and lots of other useful stuff like pojo injection, producer methods, interceptors, decorators, integration SPI, very flexible, etc. and it can even do what EJB and JSF managed beans are doing then we can have just one mature and powerful DI container. But for some backward compatibility and political reasons Java EE guys want to keep them!!!
Here you can find the difference and use cases for each of these types:
JSF Managed Beans, CDI Beans and EJBs
JSF was initially developed with its own managed bean and dependency injection mechanism which was enhanced for JSF 2.0 to include annotation based beans. When CDI was released with Java EE 6, it was regarded as the managed bean framework for that platform and of course, EJBs outdated them all having been around for well over a decade.
The problem of course is knowing which one to use and when use them.
Let’s start with the simplest, JSF Managed beans.
JSF Managed Beans
In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.
They can be defined using the #javax.faces.bean.ManagedBean annotation which takes an optional name parameter. This name can be used to reference the bean from JSF pages.
Scope can be applied to the bean using one of the different scopes defined in the javax.faces.bean package which include the request, session, application, view and custom scopes.
#ManagedBean(name="someBean")
#RequestScoped
public class SomeBean {
....
....
}
JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.
CDI Beans
CDI is the bean management and dependency injection framework that was released as part of Java EE 6 and it includes a complete, comprehensive managed bean facility. CDI beans are far more advanced and flexible than simple JSF managed beans. They can make use of interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods.
To deploy CDI beans, you must place a file called beans.xml in a META-INF folder on the classpath. Once you do this, then every bean in the package becomes a CDI bean. There are a lot of features in CDI, too many to cover here, but as a quick reference for JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation. To inject a bean into another bean, you annotate the field with javax.inject.Inject annotation.
#Named("someBean")
#RequestScoped
public class SomeBean {
#Inject
private SomeService someService;
}
Automatic injection like that defined above can be controlled through the use of Qualifiers that can help match the specific class that you want injected. If you have multiple payment types, you might add a qualifier for whether it is asynchronous or not. While you can use the #Named annotation as a qualifier, you shouldn’t as it is provided for exposing the beans in EL.
CDI handles the injection of beans with mismatched scopes through the use of proxies. Because of this you can inject a request scoped bean into a session scoped bean and the reference will still be valid on each request because for each request, the proxy re-connects to a live instance of the request scoped bean.
CDI also has support for interceptors, events, the new conversation scope and many other features which makes it a much better choice over JSF managed beans.
EJB
EJBs predate CDI beans and are in someways similar to CDI beans and in other ways very different. Primarily, the differences between CDI beans and EJBs is that EJBs are :
Transactional
Remote or local
Able to passivate stateful beans freeing up resources
Able to make use of timers
Can be asynchronous
The two types of EJBs are called stateless and stateful. Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests. Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of.
Defining an EJB is simple, you just add either a javax.ejb.Stateless or javax.ejb.Stateful annotation to the class.
#Stateless
public class BookingService {
public String makeReservation(Item Item, Customer customer) {
...
...
}
}
Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.
While EJBs and CDI beans are very different in terms of features, writing the code to integrate them is very similar since CDI beans can be injected into EJBs and EJBs can be injected into CDI beans. There is no need to make any distinction when injecting one into the other. Again, the different scopes are handled by CDI through the use of proxying. One exception to this is that CDI does not support the injection of remote EJBs but that can be implemented by writing a simple producer method for it.
The javax.inject.Named annotation as well as any Qualifiers can be used on an EJB to match it to an injection point.
When to use which bean
How do you know when to use which bean? Simple.
Never use JSF managed beans unless you are working in a servlet container and don’t want to try and get CDI working in Tomcat (although there are some Maven archetypes for that so there’s no excuse).
In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, it's simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner. If you are stuck in a servlet container and are using CDI, then either hand written transactions or your own transaction interceptor is the only option without EJBs.
If you need to use #ViewScoped in CDI you should
use seam-faces or MyFaces CODI module. just add one of them to your classpath and #ViewScoped will work in CDI. MyFaces CODI has an even more solid support of #ViewScoped
use MyFaces CODI's #ViewAccessScoped, it is an extension written on top of CDI by Apache, just download it and use #ViewAccessScoped annotation instead of #ViewScoped.
Use CDI #ConversationScoped and make it long running. See here for more info.
Use Omnifaces #ViewScoped annotation
Some parts pilfered from here.
Yep, this can be confusing.
For some ehm historical reasons JSF and CDI are using the same annotations for scopes, but from different packages.
As you are probably guessing those from javax.faces.bean are from the JSF spec, and are not related to CDI. Do not use them unless you have a very good reason to do so. And do never ever mix them with CDI annotations from javax.ejb. This will produce a sheer endless lists of bugs and subtle anomalies.
I generally recommend that you skim the first few (or even more) pages of the excellent Weld documentation. This should put you on track for Java EE 6.
And feel free to post further questions here.
Since there are no replies specifically about #javax.annotation.ManagedBean, here's a link to the answer of a similar question: Backing beans (#ManagedBean) or CDI Beans (#Named)?. The spec can be found at http://download.oracle.com/otndocs/jcp/managed_beans-1.0-fr-eval-oth-JSpec/. So it looks to me that #javax.annotation.ManagedBean was meant to be a generalization of #javax.faces.bean.ManagedBean.
From what I gathered, JSF Managed Beans are being phased out in favour of CDI Beans (maybe getting deprecated from JSF 2.3?), so I guess #javax.annotation.ManagedBean is all the more becoming obsolete now.
I'm trying to add a Interceptor in a EJB at runtime programmatically via CDI extensions.
This EJB exposes a Remote interface for remote calls. But I'm trying to add this Interceptor in the implementation class of this EJB adding the #Interceptors annontation like in this other SO question (CDI Extensions - Add Interceptors in ProcessAnnotatedType phase)
I think the CDI Extension only executes after the EJB are already registered because the Interceptor is never called.
But, for test purpose I have successfully register and execute an Interceptor programmatically in a simple CDI Bean.
The problem is when I'm try to register in a EJB.
Am I missing something?
Edit:
I'm using Wildfly 8
I think the key problem here is the difference between #Interceptors (EJB ones) and #Interceptor (CDI ones). CDI does not govern EJB container hence adding the EJB annotation (#Interceptors) in CDI extension won't necessarrily kick EJB logic into effect - EJB container might have started at that moment and it won't know of the annotation. Furthermore the CDI extension would add this annotation to the AnnotatedType which is a structure EJB probably won't make use of. On the other hand, all this really depends on the application server as it is responsible for CDI/EJB integration hence as a "bonus" the behavior might differ between AS.
CDI extension is something which allows you to hook into CDI bootstrap lifecycle, therefore you are able to use/enable/add CDI interceptors. I would try going that way instead. BTW even the SO question you referred to speaks of beans.xml/#Priority for enablement which means it uses CDI interceptors and not EJB ones.
Also, an EJB bean should automatically become CDI bean therefore you can attach CDI interceptor to it without changing the bean itself.
I am building a sort of validation framework for a GWT project.
The point is to reuse the same validation code for both client and server side.
I found that jsr-303 Bean Validation is supported by both GWT(here) and Spring(here).
As my model object are generated and I cannot annotate them properly, I would like to use xml-based configuration for jsr-303 Bean Validation. However, I don't see a way of doing it with gwt-validation.
Is there a way I configure the gwt-validation using xml instead of annotations?
It looks like there's no way of doing this yet.
I feel there is a little mess in the Java EE 6 spec. There are several sets of annotations.
We have javax.ejb annotations like #Stateful and #Stateless for creating EJBs.
There is also a #javax.annotation.ManagedBean to create a managed bean.
There are annotations in javax.enterprise.context like #SessionScoped and #RequestScoped.
What is more there are also #ManagedBean and #SessionScoped/#RequestScoped annotations in javax.faces.bean package.
And to make things event more complicated there is a package javax.inject with #Named annotation.
Can someone please describe how they are related one to another?
Where can I use #EJB, #Inject or #ManagedPropery to inject other beans?
First of all let me do some clarifications:
Managed bean definition : generally a managed bean is an object that its life cycle (construction, destruction, etc) is managed by a container.
In Java ee we have many containers that manage life cycle of their objects, like JSF container, EJB container, CDI container, Servlet container, etc.
All of these containers work kind of independent, they boot in application server initialization and scan classes of all artifacts including jar, ejb-jar, war and ear files in deployment time and gather and store some metadata about them, then when you need an object of a class at runtime they will give you instances of those classes and after finishing the job, they will destroy them.
So we can say that we have:
JSF managed beans
CDI managed beans
EJB managed beans
And even Servlets are managed beans because they are instantiated and destroyed by a container, which is a servlet container.
So when you see the Managed Bean word, you should ask about the context or type of it.(JSF, CDI, EJB, etc.)
Then you might ask why we have many of these containers: AFAIK, Java EE guys wanted to have a dependency injection framework, but they could not gather all requirements in one specification because they could not predict the future requirements and they made EJB 1.0 and then 2.0 and then 3.0 and now 3.1 but EJB's target was for just some requirements (transaction, distributed component model, etc).
At the same time (in parallel) they realized that they need to support JSF too, then they made JSF managed beans and another container for JSF beans and they considered it a mature DI container, but still it was not complete and mature container.
After that Gavin King and some other nice guys ;) made CDI which is the most mature DI container I've seen. CDI (inspired by Seam2, Guice and Spring) was made to fill the gap between JSF and EJB and lots of other useful stuff like pojo injection, producer methods, interceptors, decorators, integration SPI, very flexible, etc. and it can even do what EJB and JSF managed beans are doing then we can have just one mature and powerful DI container. But for some backward compatibility and political reasons Java EE guys want to keep them!!!
Here you can find the difference and use cases for each of these types:
JSF Managed Beans, CDI Beans and EJBs
JSF was initially developed with its own managed bean and dependency injection mechanism which was enhanced for JSF 2.0 to include annotation based beans. When CDI was released with Java EE 6, it was regarded as the managed bean framework for that platform and of course, EJBs outdated them all having been around for well over a decade.
The problem of course is knowing which one to use and when use them.
Let’s start with the simplest, JSF Managed beans.
JSF Managed Beans
In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.
They can be defined using the #javax.faces.bean.ManagedBean annotation which takes an optional name parameter. This name can be used to reference the bean from JSF pages.
Scope can be applied to the bean using one of the different scopes defined in the javax.faces.bean package which include the request, session, application, view and custom scopes.
#ManagedBean(name="someBean")
#RequestScoped
public class SomeBean {
....
....
}
JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.
CDI Beans
CDI is the bean management and dependency injection framework that was released as part of Java EE 6 and it includes a complete, comprehensive managed bean facility. CDI beans are far more advanced and flexible than simple JSF managed beans. They can make use of interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods.
To deploy CDI beans, you must place a file called beans.xml in a META-INF folder on the classpath. Once you do this, then every bean in the package becomes a CDI bean. There are a lot of features in CDI, too many to cover here, but as a quick reference for JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation. To inject a bean into another bean, you annotate the field with javax.inject.Inject annotation.
#Named("someBean")
#RequestScoped
public class SomeBean {
#Inject
private SomeService someService;
}
Automatic injection like that defined above can be controlled through the use of Qualifiers that can help match the specific class that you want injected. If you have multiple payment types, you might add a qualifier for whether it is asynchronous or not. While you can use the #Named annotation as a qualifier, you shouldn’t as it is provided for exposing the beans in EL.
CDI handles the injection of beans with mismatched scopes through the use of proxies. Because of this you can inject a request scoped bean into a session scoped bean and the reference will still be valid on each request because for each request, the proxy re-connects to a live instance of the request scoped bean.
CDI also has support for interceptors, events, the new conversation scope and many other features which makes it a much better choice over JSF managed beans.
EJB
EJBs predate CDI beans and are in someways similar to CDI beans and in other ways very different. Primarily, the differences between CDI beans and EJBs is that EJBs are :
Transactional
Remote or local
Able to passivate stateful beans freeing up resources
Able to make use of timers
Can be asynchronous
The two types of EJBs are called stateless and stateful. Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests. Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of.
Defining an EJB is simple, you just add either a javax.ejb.Stateless or javax.ejb.Stateful annotation to the class.
#Stateless
public class BookingService {
public String makeReservation(Item Item, Customer customer) {
...
...
}
}
Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.
While EJBs and CDI beans are very different in terms of features, writing the code to integrate them is very similar since CDI beans can be injected into EJBs and EJBs can be injected into CDI beans. There is no need to make any distinction when injecting one into the other. Again, the different scopes are handled by CDI through the use of proxying. One exception to this is that CDI does not support the injection of remote EJBs but that can be implemented by writing a simple producer method for it.
The javax.inject.Named annotation as well as any Qualifiers can be used on an EJB to match it to an injection point.
When to use which bean
How do you know when to use which bean? Simple.
Never use JSF managed beans unless you are working in a servlet container and don’t want to try and get CDI working in Tomcat (although there are some Maven archetypes for that so there’s no excuse).
In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, it's simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner. If you are stuck in a servlet container and are using CDI, then either hand written transactions or your own transaction interceptor is the only option without EJBs.
If you need to use #ViewScoped in CDI you should
use seam-faces or MyFaces CODI module. just add one of them to your classpath and #ViewScoped will work in CDI. MyFaces CODI has an even more solid support of #ViewScoped
use MyFaces CODI's #ViewAccessScoped, it is an extension written on top of CDI by Apache, just download it and use #ViewAccessScoped annotation instead of #ViewScoped.
Use CDI #ConversationScoped and make it long running. See here for more info.
Use Omnifaces #ViewScoped annotation
Some parts pilfered from here.
Yep, this can be confusing.
For some ehm historical reasons JSF and CDI are using the same annotations for scopes, but from different packages.
As you are probably guessing those from javax.faces.bean are from the JSF spec, and are not related to CDI. Do not use them unless you have a very good reason to do so. And do never ever mix them with CDI annotations from javax.ejb. This will produce a sheer endless lists of bugs and subtle anomalies.
I generally recommend that you skim the first few (or even more) pages of the excellent Weld documentation. This should put you on track for Java EE 6.
And feel free to post further questions here.
Since there are no replies specifically about #javax.annotation.ManagedBean, here's a link to the answer of a similar question: Backing beans (#ManagedBean) or CDI Beans (#Named)?. The spec can be found at http://download.oracle.com/otndocs/jcp/managed_beans-1.0-fr-eval-oth-JSpec/. So it looks to me that #javax.annotation.ManagedBean was meant to be a generalization of #javax.faces.bean.ManagedBean.
From what I gathered, JSF Managed Beans are being phased out in favour of CDI Beans (maybe getting deprecated from JSF 2.3?), so I guess #javax.annotation.ManagedBean is all the more becoming obsolete now.
I am having a EJB 3.0 Session Bean which implements the Local interface, and I have a pure POJO also.
How can I inject a Session Bean into the POJO rather than manual JNDI look up in to POJO through spring(using #Resource and SpringBeanAutowiringInterceptor)?.
Is there any way to do that?
To inject an EJB3 into a POJO (which is possible since Spring 2.5), I think that you should use #EJB instead of #Resource. Quoting Spring EJB and JPA (read it all, it has many examples):
Don't forget to add:
<context:annotation-config/>
It allows various annotations to be detected in bean classes: Spring's #Required and #Autowired, as well as JSR 250's #PostConstruct, #PreDestroy and #Resource (if available), JAX-WS's #WebServiceRef (if available), EJB3's #EJB (if available), and JPA's #PersistenceContext and #PersistenceUnit (if available). Alternatively, you may choose to activate the individual BeanPostProcessors for those annotations.
Also have a look at Spring support for #EJB annotations: example? on the Spring forums.
One option is to use the poetically-named LocalStatelessSessionProxyFactoryBean, which creates a spring bean proxy pointing at the session EJB on JNDI. You can then wire this proxy into your POJO using the usual Spring wiring techniques. The proxy bean will implement the same local interface of your EJB.
See this section of the Spring manual for an example.