What is the difference between a .war and .ear file?
In a JEE application, modules are packaged as EAR, JAR and WAR based on what they are set out to do.
JAR: EJB modules are modules that contain enterprise java beans (Stateful-, Stateless or Singletons) and are packed as JAR files with .jar extenstion
WAR: Web modules which contain Servlet class files, JSP Files, static files like GIF, JPG, PNG and HTML files are packaged as a WAR file (web archive). A WAR file is a jar with different extension.
EAR: An EAR-file is also a jar file but with the .ear extension, which contains all modules in the application (jar and war) and in addition it can also contain jar files that the application is dependant of (if the choice is made to pack them with the application). The ear-file is deployed to an application server like JBoss, Websphere, Weblogic or Glassfish (among others).
In the JNDI namespace there can be several different types of resources available. These can include Enterprise Java Beans (EJB’s) located in another module, data sources or JMS queues etc.
Earlier those resources were most commonly fetched by doing an JNDI-Lookup in the current environment (the application server).
An Entity is much like a regular Java Bean. It has private properties that can be accessed through public get and set methods,
and can be treated as such (a regular bean). The things that make this ordinary class an Enity are the annotations that enables the bean to be
managed by the EJB container.
This is what a class could look like without the annotations:
Stateful session beans support callback events for the following events:
A method in the bean may be annotated to be executed when any of these events occur.
The PostContruct callback happens immediately after a bean is instantiated in the EJB container.
The bean may use dependency injection to get reference to other beans or resources, in that case the event happens after these injections are completed.
The method itself doesn’t have to have a certain name. It can be called anything and is a good place to for example create a Logger instance for logging.
A method could look like this:
A stateful session bean can store information between client calls, as opposed to stateless session beans that cannot remember anything about the user from its last call.
A stateful session bean looks like an ordinary Java class except that it is annotated with the @Stateful annotation.
The typical stateful session bean is a shopping cart which keeps track of items that the user has added duing it’s visit to a particular site.
Below is an example of how a shopping cart stateful session bean could be declared:
This example shows how to create a javax.jms.TopicConnectionFactory.
To be able to create a TopicConnectionFactory instance,
you’ll first need to instantiate a InitialContext object to look up the TopicConnectionFactory in the server’s naming service (JNDI tree).
The TopicConnectionFactory is used to create connections to a message server.
The behavior and attributes of the TopicConnectionFactory are configured by the system administrator of the messaging server.
Each vendor implements the the TopicConnectionFactory differently, so the configuration options may vary from one vendor to another.
It is possible to invoke a Session Bean over the network by declaring the interface of a session bean as Remote. This is done using the @Remote annotation, which is equal to having it extend the java.rmi.Remote interface.
The reference to the bean that gets aquired by a client is not a local reference on the same server but an RMI stub that can be used to invoke the session bean from another server or a client application.
The J2EE server (like Glassfish or Oracle Weblogic) manages the life cycle of a stateless session bean unlike regular Java classes. The server decides when to create and remove bean instances, so the application never knows how many instances of a session bean class that is created, nor does it know when they are created or destroyed.
Since the server itself needs to initialize services for the bean before the business logic is invoked, and the bean itself most likely will need to make some initializations of itself,
the constructor is not a good place for that bean initialization code.
To allow both the server and the enterprise bean to make their initializations, EJBs support something called “lifecycle callback methods” that are annotated by the programmer and invoked by the server at various points in th bean’s life cycle.
For stateless session beans there are two lifecycle callbacks:
A stateless session beans lifetime is the lifetime of a single method within it. It can contain several methods, but they are completely independent of each other.
A stateless session bean cannot hold any data between calls from the client, it is designed to carry out independent operations very efficiently.
Stateless session beans may scale to large numbers of clients with minimal impact to overall server resources.
A stateless session bean contains of two parts.