https://alextheedom.wordpress.com/context-and-dependency-injection-in-java-ee/
The Java EE programming model has been simplified substantially since J2EE. Annotations have replaced the XML description files, convention over configuration have replaced the tedious manual configuration and dependency injection hides the creation and look up of resources.
Resource are created and injected at injection points marked by annotations such as @Inject. All you need is a POJO that meets all of the conditional of the managed beans specification JSR 299 and depending on the annotation used it will become an EJB, servlet, singleton or RESTful web service.
JSR 299 Managed bean specification
- It is not a nonstatic inner class.
- It is a concrete class or is annotated @Decorator.
- It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.
- It has an appropriate constructor. That is, one of the following is the case:
- The class has a constructor with no parameters.
- The class declares a constructor annotated @Inject.
No special declaration, such as an annotation, is required to define a managed bean.
To enable CDI you must have a beans.xml file in your project (under the META-INF or WEB-INF).
To enable CDI you must have a beans.xml file in your project (under the META-INF or WEB-INF).
The object is injected by the container and is determined by type. Using an interface as a type can confuse the container if there is more than one concrete implementation. It doesn’t know which object to inject. This confusion can be resolved by the use of a qualifier annotation that marks the concrete implementation you want to implement.
https://alextheedom.wordpress.com/deep-dive-singleton-pattern/@Singletonpublic class Logger { private Logger(){ // Creation code here }}Used like so: @InjectLogger logger;
The first thing you will have noticed is how much less code is required to create a singleton. The EJB container creates an instance of the Logger class and will inject the same instance where ever it finds an injection point. Injection points are annotated @Inject. The creation of the singleton class is done by the container and the container knows to create only one instance because the class is annotated with the @Singleton stereotype annotation and concurrency is managed by the conclusion.
By default the singleton bean is initialized lazily, it wont be created until first use. Normally this is sufficient for most use case scenarios, however you may want the singleton bean to perform application start up tasks in which case you must annotate the bean with @Startup. The EJB container must ensure that the bean is initialized before it delivers client requests. Adding the @PostConstruct annotation to the method that performs application start up request.
@Startup@Singletonpublic class Logger { private Logger() { // Creation code here } @PostConstruct void startUpTask() { // Perform Start Up Tasks }} |
Methods annotated WRITE, locks to other beans while it is being invoked. Methods that affect change will be annotated this way. Methods annotated READ allow concurrent access.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| @Singleton@ConcurrencyManagement(ConcurrencyManagementType.BEAN)public class Logger { private Logger(){ // Creation code here } @Lock(LockType.WRITE) public void addMessage(String message){ // Add message to log } @Lock(LockType.READ) public String getMessage(){ // Get message }} |
A call to the getMessage method will be forced to wait unitl the addMessage method completes. This may result in a ConcurrentAccessTimeoutException if the addMessage() method does not complete within the specified timeout period. The timeout period can be configured with an annotation either at the class level or the method level.
1
2
3
4
5
| @AccessTimeout(value = 30, unit=TimeUnit.SECONDS)@Lock(LockType.WRITE)public void addMessage(String message){ // Add message to log} |
