http://antoniogoncalves.

org/2011/05/23/to-inject-or-not-to-inject-cdi-is-thequestion/
http://vimeo.com/42083007
http://www.adam-bien.com/roller/abien/entry/jpa_ejb3_killed_the_dao
http://blog.arungupta.me/2014/06/testable-javaee7-maven-archetype-usingarquillian-techtip34/
http://www.javacodegeeks.com/2014/06/java-ee7-and-maven-project-fornewbies-part-5-unit-testing-using-arquillian-wildfly-8.html
http://javapapo.blogspot.gr/2014/06/java-ee7-and-maven-project-fornewbies_23.html
http://blog.progs.be/585/wildfly-integration-arquillian-maven
http://www.hascode.com/2014/05/java-ee-logging-user-interaction-the-aspectoriented-way-using-interceptors/
http://www.solewing.org/blog/2014/11/property-injection-with-cdi/ **
Service name/ full terms
Java Transaction API
Java Persitence API
Java Persistence Query Language
Validation
Java Message Service
Java Naming and Directory Interface
JavaMail
JavaBeans Activation Framework
XML processing (Java API for XML Processing)
Simple API for XML
Document Object Model
Streaming API for XML
Java Architecture for XML binding
JSON Processing
Java EE Connector Architecture
Security services
Java Authentication and Authorization
Java Authorization Service Provider Contract
for Containers
Java Authentication Service Provider
Interface for Containers
Web services (SOAP & RESTful web service)
Java API for XML Web Services
Java API for XML-based RPC
Java API for RESTful Web Services

Abbreviation
JTA
JPA
JPQL
Bean Validation
JMS
JNDI
JAF API
JAXP
SAX
DOM
StAX
JAXB
JSON-P
JAAS
JACC
JASPIC
JAX-WS
JAX-RPC
JAX-RS

Depedency Injection
Context Depedency Injection
Management
Java Management Extensions
Deployment
Remote Method InvocationInternet Inter-ORB
Protocol
Enterprise Information System

DI
CDI
JMX
RMI-IIOP
EIS

Deployment descriptors

Imperative programming and declarative programming

Imperative programming specifies the algorithm to achieve a goal (what has to be
done), whereas declarative programming specifies how to achieve this goal (how it
has to be done). In Java EE, declarative programming is done by using metadata, that
is, annotations or/and deployment descriptors.
Listing 1-2. An EJB Deployment Descriptor
<ejb-jar
xmlns="http://xmlns.jcp.org/xml/ns/javaee"xmlns:xsi="http://www.w3.org/2001/X
MLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
version="3.2">

<enterprise-beans>
<session>
http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd"
<ejb-name>ItemEJB</ejb-name>
<remote>org.agoncal.book.javaee7.ItemRemote</remote>
<local>org.agoncal.book.javaee7.ItemLocal</local>
<local-bean/>
<ejb-class>org.agoncal.book.javaee7.ItemEJB</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
TRANSACTION
ACID (Atomicity, Consistency, Isolation, Durability)
http://msdn.microsoft.com/en-us/library/ms173763.aspx
SPECIAL NOTES WHICH HELP CLARIFYING BETWEEN BEAN MANAGER IN JAVA EE
6&7
Source: http://stackoverflow.com/questions/11986847/java-ee-6-javaxannotation-managedbean-vs-javax-inject-named-vs-javax-faces#answers-header
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.
Lets start with the simplest, JSF Managed beans.
JSF Managed Beans
In short, dont 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.beanpackage 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 shouldnt 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 dont 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.Statefulannotation 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 dont want
to try and get CDI working in Tomcat (although there are some Maven archetypes for that so
theres 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 @ViewScopedwill 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, justdownload it and use @ViewAccessScoped annotation instead
of @ViewScoped.
Use CDI @ConversationScoped and make it long running. See here for more info.
Some parts gotten from here.

QUESTION AND ANSWER WHILE READING

Chapter 1
Chapter 2
Chapter 3
Chapter 4
ID Question
Answer
1
Got this exception
. At first I add this to pom
Caused by:
<dependency>
java.lang.ClassNotFoundExceptio
<groupId>org.glassfish</groupId>
n:
<artifactId>javax.el</artifactId>
javax.el.PropertyNotFoundExcept
<version>3.0.0</version>
ion
</dependency>
If the bean validation
Everything worked as expected. But I
constraint(s) is violated
think about whether there is any
expression language implementation from
JBOSS and I found this
<dependency>
<groupId>org.jboss.spec.javax.el</groupI
d>
<artifactId>jboss-elapi_3.0_spec</artifactId>
<version>1.0.4.Final</version>
</dependency>
This worked find with NotNull vailidator ,
but with @Size(min = 10, max = 2000),
the program throught this exception
java.lang.ClassNotFoundException:
com.sun.el.ExpressionFactoryImpl
(next question related to this)
21

What if I define the scope of

depedency in maven provide for
javax.el. What is the
implementation of Wildfly server
(Jboss)

According to
http://blog.arungupta.me/2013/10/javaee-7-implementations-in-wildfly-tech-tip3/
The implemtation for Expression
Language in Wildfly is from Glassfish

Using Arquillian to integration

test deploy as a JavaArchive will
not print anything out

Change the logging level of entire Wildfly

in standalone.xml -> search for profile

Chapter 5
Chapter 6
Chapter 7

The Java EE specification defines portable JNDI names with the following syntax
java:<scope>[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interfacename>]
Each portion of the JNDI name has the following meaning:
<scope> defines a series of standard namespaces that map to the various scopes of a
Java EE application:

global: The java:global prefix allows a component executing outside a Java EE

application to access a global namespace.

app: The java:app prefix allows a component executing within a Java EE

application to access an application-specific namespace.

module: The java:module prefix allows a component executing within a Java

EE application to access a module-specific namespace.

comp: The java:comp prefix is a private component-specific namespace and is

not accessible by other components.

<app-name> is only required if the session bean is packaged within an ear or war file.
If this is the case, the <app-name> defaults to the name of the ear or war file
(without the .ear or .war file extension).
<module-name> is the name of the module in which the session bean is packaged. It
can be an EJB module in a stand-alone jar file or a web module in a war file. The
<module-name> defaults to the base name of the archive with no file extension.
<bean-name> is the name of the session bean.
<fully-qualified-interface-name> is the fully qualified name of each defined business
interface. For the no-interface view, the name can be the fully qualified bean
class name.
Questions
1. When I deploy the EJB to application server I found that there are many thing I cannot
imagine how it work. There are a lot of way to package different kind of component into
a JEE application server. Let take an example
I have 3 project : EAR, EJB , and WEB. The EAR project contains EJB and WEB. When
I deploy EAR I have some EJBs in the server and a web which I can access via a URL.
But I can also deploy the EJB and WEB seperately and I got other EJBs and an other
web. So the question is raised How those deployed component deployed and work ? are
they have something related to others ?

Then an other question What is the role of JEE application server like JBOSS,
GLASSFISH, WEBLOGIC .. -> the answer seems to be in chapter 1 of Java EE 7
Tutorial Volume 1 5th Edition.
2. Why do we need RMI for remote invocation for EJB. At first , I guess that the JEE
Application Server starts many JVM and EJBs may be existed in different JVM. One
more possibility is that this is for the scalability of application. An JEE component from
one application server can use another component from other ones.