venerdì 21 giugno 2013

Tricky session management

Session management is always a pain in the ass for the programmers.
Is never the case to say that it is easy.

With the introduction of the technology up to here spoken in this blog (EJB), we have a new way to manage user' session.

Let's see how.
This practice will work both in the case you want to develop a web application that uses a EJB as logic tier and in case you have a desktop application that uses the logic tier as business tier.

The trick consist in use a stateful session bean in order to keep active the session.

//@StatefulTimeout(value = 10, unit = TimeUnit.SECONDS)
@StatefulTimeout(value = 2, unit = TimeUnit.HOURS)
public class LoginManager 
implements IUser {
 private static Logger logger = Logger.getLogger(LoginManager.class);
 private Integer IdUtente;
    public void doLogout() {"distruggo la sessione e rimuovo l'EJB");
     this.IdUtente = null;
    private void myPreDestroy(){"PREDESTROY invalido la sessione e distruggo il bean");
     this.IdUtente = null;
The method doLogin(String user, String password) is omitted because irrelevant for this scope.
In order to understand the trick, let's analyze the code from the top.

Stateful session beans, so the EJB container will handle itself the question to manage the user session. 
Remote, needed because we want to expose this methods via the public interface IUser.
Statefultimeout is used to keep active for a certain defined time the EJB. After this time is triggered, the ejb container (jboss/glassfish/whatever) will handle to remove the ejb.
Exaclty: the ejb will be removed, thus the user session will be invalidated.
Let's see the

  •  @remove notation. Indicates that the stateful session bean is to be removed by the container after completion of the method. 
  •  @predestroy notation. Goes hand in hand with remove, when the method marked with remove completes, the EJB container will invoke the method annotated with the @javax.annotation.PreDestroy annotation, if any, and then destroy the stateful session bean.

Remove is used to "remove" the bean after the method doLogout is called. 
Predestroy is used to invalidate the session, when the timer triggers the end of the session. Infact no one will call the doLogout method, but we want to invalidate anyhow the session.

Of couse the invalidation here means just put a variable to null, but you may want to perform more complicated actions. 

On the client side the session is maintained just keeping the pointer to the ejb handler. If the ejb has been removed on server side, using the stored handler will result in an exception. Thus the programmer will understand that the session is no more valid. 


martedì 18 giugno 2013

EJB smart lookup

I want to post a nice solution i found for looking up the EJB, easy and simple.
It follows the KISS idea, Keep It Simple and Strong.
Part of this solution is a contribution of Massimiliano.
Let's start from this idea:
I want to provide to the user a library that is capable to lookup enterprise beans, without telling him anything about the class that implements the exposed interfaces.

I have many enterprise beans in my application, one of the is for example the account manager:

import javax.ejb.Remote;
import javax.ejb.Stateless;
@Stateless(name = "Account")

public class AccountManager implements IAccount {

This class implements the interface IAccount.  It is and EJB stateless bean, and the name used to look up this stateless bean is Account. Telling the name of the bean is the first step. Doing so we know the name we have to use for the lookup.
Once deployed the EJB projects an output like this:


We need to consider the red part, to look up the EJB. Removing the name of the bean the red part would look like /MyBankLogicEAR/MyBankLogic/NameOfThePackage.AccountManager!main.IAccount

As already said, I want the user NOT to be aware of the path, the name and just avoid him all the problems of looking up the beans.

This said let's take a look at the code produced by Massimiliano:
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
try {
            final Context context = new InitialContext(jndiProperties);
            String appName = "";
            String moduleName = "jboss-firstbean";
            String distinctName = "";
            String beanName = "FirstBean";
            String interfaceFullName = "ejb.RemoteFirstBean";
            final String jndi = "ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName;
            RemoteFirstBean statelessRemote = (RemoteFirstBean)context.lookup(jndi);

        } catch (NamingException ex) {
this is part of the post access EJB on jboss as 7. You may refer to it for more detailed explanations.
Thus this said, i want to avoid the user to use this snipped of code, but instead just tell which interface implementation he wants to lookup.
Interfaces are common among the client and the server, and shares the accessible remote methods. A part these methods, user must NOT be aware of everything else.

This is the solution i propose:
package utility;

import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class Lookup<tipo>{

 private static final Hashtable jndiProperties = new Hashtable();
 private static final String appname = "MyBankLogicEAR";
 private static final String modulename = "MyBankLogic";
 private static final String distname = "";
 private static Context context;
 private Boolean isStateless = true;
 private String interfaceName = "";

 public Lookup(Boolean isStateLess, Class <Tipo> classe) {
  this.isStateless = isStateLess;
  this.interfaceName = classe.getName();
 public <Tipo> Tipo lookup() throws Exception{
  Tipo res = null;
  String beanName = "";
  switch (interfaceName) {
  case "main.IAccount":
   beanName = "Account";
  case "main.ICliente":
   beanName = "Cliente";
  case "main.ICommonOperation":
   beanName = "Common";
  case "main.IDipendente":
   beanName = "Dipendente";
  case "main.IServizi":
   beanName = "Servizi";
  case "main.IUser":
   beanName = "Login";
  case "main.IReportGeneration":
   beanName = "Report";
   beanName = "";

   return null;
  res = lookup(beanName, interfaceName, isStateless);
  return res;


 private <Tipo> Tipo lookup(String beanName, String interfaceName,
   boolean stateless) throws Exception{
  Object bean;
  try {

   context = new InitialContext(jndiProperties);
   String jndi = "ejb:" + appname + "/" + modulename + "/" + distname
     + "/" + beanName + "!" + interfaceName;
   if (!stateless) {
    jndi = jndi + "?stateful";
   //System.out.println("jndi: " + jndi);
   bean = context.lookup(jndi);
   return (Tipo) bean;
  } catch (NamingException ex) {
   throw new Exception("Non posso fare il lookup all'EJB");

In this way the user with a simple code like:
IUser  u = new Lookup<IUser>(Boolean.FALSE, IUser.class).lookup();
Can lookup the EJB which is responsible to provide the methods exposed in the interface IUser.

This is very simple because programmers on server side are aware of the names of the beans, and they may also write an even complex code for look up, like a factory does. Hence they can provide a simple library with this class to lookup the beans.
It is strong because user just knows whether or not an EJB is stateless or not, thus thanks to the interface and using the library it can lookup beans on the Jboss as 7 without having any problem with the name of the application, the EAR,  or the module name.

EJB 3 lifecycle

Today we will see how stateful and stateless bean does live their life, thus this will be used in another article in order to do a tricky session managment.

The lifecycle

We must distinguish between stateless session bean and stateful session bean because their lifecycle is different.

Before describing the difference in the lifecycle, let's recall the diffrerences between stateful and stateless:

  • Stateful
    they use class variables that are kept across the "conversation" between client and server (bean).
    Thus is possible to declare global variable in the class that implements the EJB, and theese variables are hold among the different requests of the client.
    When the client terminates there are two options to be undertaken: the bean is removed or session ends, thus state disappears.

    This kind of EJB are less scalable, wtr to the stateless. This is due to the overhead introduced by the need to keep the conversational state (memory on server side, methods called to maintain the EJB...).

  • Stateless
    They do not use class variables,  it will be useless because they die after the method call.

    They are throwaway enterprise beans. Thus by this feature their usage result in a more easy scalable application building. This type of beans can serve different clients at the same moment, without keeping track the about the session management. Hence there is no overhead for the server which is less stressed by the usage of this type of beans.

Let's take a look at the lifecycle now. Let's start by the latest one described above.

Stateless bean lifecycle
  • Stateless

    Stateless'bean lifecycle is described by the image here on the side.
    Very simply: 2 states for this state machine. The bean does not exist when is waiting to be called by the client. Once upon the bean is called it goes to the state ready. During this phase/state the bean can compute and perform the operation requested by the client through the remote method invocation. Hence once the method is terminated the bean goes back to does not exists.
    We can notice that there are:
Stateful bean lifecycle
  • Stateful

    Stateful beans add more than what the stateless offers. The basic concept remains the same.
    There are the does not exist state and the ready state, but further there is a state which is passive.
    This state is coming out from the need of maintaing the session, thus the variables. Once up on the bean is created is not destroyed when the first method invocation finishes, but is remains ready to satisfy other client requests. Anyhow the memory of the server may be used by other beans, or in general by other tasks, thus the bean is passivated and removed by the memory. From the oracle docs we can read "(Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) ".
    We can notice the need of:
    1. PASSIVATION. Used to move from the primary memory (ram probably) to a secondary memory on the server (cache, hard disk, raw memory)
    2. ACTIVATION. Used to bring back from secondary memory the bean, thus placing it in the primary memory ready to be called and serve the client.

Note that every step may be controlled through the annotation, we may for example want to run a task upon the Passivation or Activation of the bean, as well as when is Created or Removed.

We will see how to do a tricky session management with a stateful session bean in another article.


Roseinda EJB tutotial session bean
docs oracle
image sources
docs oracle

mercoledì 6 febbraio 2013

Enabling and using log4j on JBoss AS 7

Hi all,
today we will see how to enable and use log4j on JBoss as 7.
As you may already know JBoss comes already with his own version of log4j which is located under %jboss-home/modules/org/apache/log4j.

The following steps explains you what you have to do:
  1.  add the log4j.jar to your classpath, this may be done easly with the following steps
    • right click on your application - ejbmodule, Build path , configure build path..
    • then Add external jar, which you will find in the path mentioned above 
  2. Configure the logger. See below.
  3. Go the class you want to use the logger, suppose is in "mypackage.subpackage"
    add the import at the top of the class
    import org.apache.log4j.Logger;
  4.  create a field with the logger:
    private static Logger logger = Logger.getLogger(YourEJBClass.class);
  5. use the logger"started"); logger.debug("value of x" + x.toString());

Configure the logger

JBoss already comes with a configuration file under %Jboss-home/standalone/configuration/standalone.xml.
By default, your logger will output to server.log and console, but you can add some appender to output your app logs to another file.
Stop the server before start modifing the standalone.xml.
Log4j is highly customizable, here is a basic configuration:

<periodic-rotating-file-handler name="FILETWO">
    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
  <file relative-to="jboss.server.log.dir" path="mylogfile.log"/>
  <suffix value=".yyyy-MM-dd"/>
  <append value="true"/>
This will be added in the standalone.xml, you can put it in the subsystem forlogging, after the CONSOLE one and the FILE one.

After this snippet of code, and before the <root-logger> node you can put the following snippet
<logger category="mypackage.subpackage">
    <level name="DEBUG"/>
        <handler name="CONSOLE"/>
        <handler name="FILETWO"/>
Start again the server and enjoy your logging system.

sources: my original question at stackoverflow. Rafael answers and his blog

sabato 22 dicembre 2012

Interfaces: Remote vs Local

Many of you may be confused as i was upon the terminology and the usage of interfaces.
Should they be remote? or should they be local?


Nice question, weird anser. Depends is always a good answer but I will explain here my point of view, after having read here and there some hints.

When you design your appliaction you first decide what it has to do, and doing so, you will decide the logic that your EJB will hold.
The separation between the "Logic"(hold by the EJB tier) and the "Presentation"(hold by the web application, or generally your client) following the EJB architecture is foundamental, and here it comes the time to decide what you want your client to be.

i.e. Suppose you want your logic to implement a calculator, you will provide sum, subtraction, multiplication and division through EJB.

The interfaces are just the view exposed to the client of your Logic, without knowing of course how it is implemented.

i.e. your client will provide a sort of gui or some input methods for the numbers and the operation you want to do, hence calling the EJB it will perform the computation.

At this point you may wonder where you should have your client.

At the very beginning EJB was meant to provide remote access throught RMI standard, so the client was meant to be on a different machine from the one who acted as container for EJBs (remote).
Moving to version 2.0 the Java EE team decided to provide also a different approch to EJB. You wonder: why should i run through RMI, sockets and network connection when i have the client on the same JVM as the EJB container?
So they introduced the local interface that allows the client to call directly methods on bean, bypassing the RMI sematics(local), you will find that you write local interfaces in some special cases.

How much good is this idea to have it local?? I can't say. Still you should have a stub and a skeleton as the RMI paradigm impose, but you don't have the network in the middle because the client and the server(ejb container) run on the same java virtual machine and hence on the same heap.
Instead with the remote interface you have two different JVM and two different heaps.

Anyhow, you have to choose based on your client-program. For sure you will not have both the implementation, it will be useless. Think about it, should you have a remote interface and a local interface that expose the same things? or partial things on the remote and partial on local?

Furthermore in my opinion i think that if you are going to use EJB to provide the logics, your client will be running on a different machine.

other sources:

book: Head first EJB

venerdì 21 dicembre 2012

Installing and configuring JBoss

As you may have noticed if you installed Netbeans (the full version) as IDE, you have also installed the latest version of tomcat and the latest version of glassfish.
For many of you thoose servers may be enought to start writing code, and testing the available technologies.

With this post we will explain you how to install a new server: JBoss AS 7, that for many of you may be already a know resource, but for other may be a new one.

This server that will be installed is Java EE compliant, as glassfish is (remember that Tomcat is not), and is provided by JBoss (

So let's start.

1) Install latest version of JBoss AS (7 currently, at the time of the post writing).

Instruction for doing so can be found here for those who use Windows OS

for the others who use Linux based systems or MacOS,+Unix+or+Mac+OS+X

We installed JBoss on windows 7, Mac Os 10.6 and Ubuntu 10.10 and the lastest Linux Mint (at writing time), it is working perfectly without any problem.

RECAP OF INSTALLING: unzip and choose a folder where to place it. That place will be - inside the jboss 7.1.x - the home for the server.

At this point you have JBoss AS 7 installed.

2) Configure IDE

For the sake of semplicity we'll use Eclipse for which there are the latest updates available coming directly from the jboss comunity (i have to say that personally i like more NetBeans - that atm does not support JBAS7).
Once you have eclipse installed follow the steps described here
(Section is "Installation from update site")

that said, continue with this steps to set up and use Jboss with eclipse

once you have finished this step your job is done.
You have successfully configured eclipse to use your jboss server.

Enjoy your server!

Ps: Note that the server provided in this way is suitable only for testing and building application to run on your localhost, for configuring your server in order to accept connection not only from localhost please check out this post

EDIT: update on 10th april 2013. Tested on Mac OS 10.8.3. Working successfully!

Accessing remote EJB on JBoss AS 7.1 from web application

Finally, after many and many hours spent on a solution, I'm able to deploy an EJB module and access it from a differente machine! Here are the steps:

1) JBoss AS 7.1 running on a Debian Distribution. To build and deploy the EJB module I used Eclipse (juno version)
2) Apache Tomcat 7.0.32 on a DIFFERENT machine on which I'm going to develop a simple servlet to get the remote ejb deployed on JBoss. I used Netbeans 7.2 here, just because I still prefer Netbeans when developing web applications. 

STEP 1. This is the key point of the entire work. I found hundreds of guides on the web explaining how to invoke remote ejb from a separated client, but noone of these pointed out this important issue. Either you are using Glassfish or JBoss to develop your EJB module you first have to set your server in such a way that is reachable from the outside and not only in localhost. To do this you have to edit the server descriptor, in this case ( JBoss ) standalone.xml. In ${JBOSS_HOME}/standalone/configuration/ there is our file, open it. Quite at the end of the file, we can find the interfaces definitions; ADD A NEW INTERFACE (I called it mine), setting the access of it to any ip. The result should be this:

Following the interfaces, we can find the socket-binding-group tag, which sets the ports required for the given interfaces. In our case, change the default-interface parameter to match the new interface ( mine again in this case ); the outpout should be:
STEP 2. Now we need to add a new APPLICATION user to the JBoss server. To do that run the add-user script ( ${JBOSS_HOME}/bin/ ) and select the b) option. The user and password will be used by the client to access the EJB module on the server. The a) option instead (managment user) allow you to create a username and password needed to access the administration panel of JBoss.

STEP 3. We are ready to develop an EJBModule on our JBoss server. Just create for example a stateless session bean on eclipse, providing a remote interface:

session bean pattern:

package ejb;

import javax.ejb.Remote;

public class FirstBean implements RemoteFirstBean{
//implemtation of interface's methods

interface pattern:

package ejb;

public interface RemoteFirstBean{
//declaration of methods

Now we can deploy the module on JBoss, no errors should rise up.

STEP 4. On my client pc, I create a java Web application using Tomcat as web server. After that, just create a servlet including in the processRequest method the following code just to test our remote invocation:

final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
try {
            final Context context = new InitialContext(jndiProperties);
            String appName = "";
            String moduleName = "jboss-firstbean";
            String distinctName = "";
            String beanName = "FirstBean";
            String interfaceFullName = "ejb.RemoteFirstBean";
            final String jndi = "ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName;
            RemoteFirstBean statelessRemote = (RemoteFirstBean)context.lookup(jndi);

        } catch (NamingException ex) {

As we can see, first create an InitialContext putting "org.jboss.ejb.client.naming" as url_pkg_prefixes. This tells our application to lookup in his classpath for the file in which it will find all the information to access our remote ejb. Now we just need to lookup in the context for the bean using the jndi specification used the JBoss (remember to include in the project the same interface as the JBoss one). The jndi specification is the following:


Appname should be the name of the .ear file we have deployed on JBoss (if deploying an Enterprise Application) . In my case I just deployed a .jar file as simple EJB module so app-name will be empty. Module-name is the name of the EJB module deployed ( the .jar file on JBoss ), in my case is "jboss-firstbean". Distinct name as well is empty. The full path of the remote interface in my case is ejb.RemoteFirstBean. The resulting jndi will be:


After the lookup, we can try some methods of the bean to verify if everything works.

STEP 5. As I said before, we must now set the properties file. It must be placed in the classpath of the web application. Create a file with the name and insert the following(field,value):

4447 is the default port for remoting of JBoss. Just use the Ip of the JBoss server machine.

STEP 6. Last step. In order to use org.jboss.ejb.client.naming on the client application, I needed to include in my project the jboss-client.jar library which can be found in ${JBOSS_HOME}/bin/client/

STEP 7. Run the servlet, and all should works fine :) (EJBModule should be running as well :P )