Executing JNDI based Pentaho reports using the Java API

alfresco business reporting logoI am working on the Alfresco Business Reporting project. In there, the tool can execute PentahoJaspersoft reports (against Alfresco business objects, using the Pentaho/Jasersoft Java API) on a scheduled basis. I ran into the issue of portability of the (Pentaho) reports. The database, url, credentials were not identical on my Development, Test and Production environments… JNDI is the answer.

In JNDI ( (Java Naming and Directory Interface) world, a datasource is identified by a name, and each naming provider can carry different credentials/url’s for the same name in different environments. Datasources can be LDAP systems, JDBC connections etc. Just what I needed.
I ran into 3 issues, initially entangled;
  1. How does the Pentaho reporting API deal with JNDI
  2. Running a report using my custom Java logic from a command-line
  3. Running a report from within Alfresco – How to manage the duplicate credentials. The reporting database connection properties were already defined in alfresco-global.properties, and I prefer to re-use these in the named JNDI connection.
 Although I like journeys, I do prefer reaching destination too, especially in this particular case. There were not many useful guides along the route, so having it finally figured out, also resulting in this blog.
How does the Pentaho reporting API deal with JNDI

The Pentaho report definition (.prpt files) are zip files containing mostly XML files. One of the files contains all database related info. This means the JNDI name and the JDBC userame/password/driver/url information is stored inside the report. It appears hard to override when executing the report using the Java API.
The Pentaho API has a class MasterReport, that has the methods setDataFactory and setDataSource. The DataFactory is typically used for JDBC like connections (user, pass, url, driver).  I have had no success in overriding these values when executing a report in a different environment.
The JNDI name is stored in the report too, but since it is resolved against the context at time of execution, it is perfectly fine to use the name as stored. Exactly how JNDI was meant. Find here how to configure the Pentaho Report Designer for JNDI.
Running a report using my custom Java logic from a command-line
I created a command-line version of the logic to execute reports. Building stuff into Alfresco, restarting and the full procedure takes too much time. But how to use JNDI like this?
Most guides expect some kind of JNDI provider (usually application servers like JBoss, Tomcat), and tell you how to get definitions from there. I do not want to depend om yet another definition of my reporting database details, it is in Alfresco’s global properties already. I got stuck in Simple-JNDI and related tools, that apparently get datasources and details from, yet again, an existing JNDI provider. The Report executer does not accept anything that Simple-JNDI provides (DataSource or Connection). (Wonder how Pentaho Report Designer does the trick itself… I have had my share of reverse engineering for now…) The Pentaho report just requests the JNDI name, and gets provided by the environment. How to get such a responsive environment?
I finally ran into this guide from Oracle. It inspired me to finalize their idea (stopRegistry was missing):
private static Registry startRegistry() throws RemoteException {
    System. out .println("enter startRegistry" );
    Registry registry = null ;
    try {
        registry = LocateRegistry.createRegistry(Registry. REGISTRY_PORT );
        System. out .println("exit startRegistry: RMI registry created.");
    } catch (ExportException e){
        System. out .println("exit startRegistry: RMI registry already existed.");
    return registry;

private static boolean stopRegistry(Registry registry) {
    System. out .println("enter stopRegistry" );
    boolean result = false;
    try {
        result = UnicastRemoteObject.unexportObject(registry, true );
    } catch (NoSuchObjectException e) {
        System. out .println("stopRegistry: RMI registry already stopped.");
    System. out .println("exit stopRegistry: RMI registry stopped: " + result);
    return result;

private static InitialContext createContext() throws NamingException {
    Properties env = new Properties();
    env.put(Context. INITIAL_CONTEXT_FACTORY ,"com.sun.jndi.rmi.registry.RegistryContextFactory" );
    env.put(Context. PROVIDER_URL , "rmi://localhost:" +Registry. REGISTRY_PORT);
    InitialContext context = new InitialContext(env);
    return context;

private static void setJndiDataSource(String source) throws NamingException, RemoteException{
    System. out .println("enter setJndiDataSource source="+source);

    ConnectionPoolDataSource dataSource = newMysqlConnectionPoolDataSource();
    ((MysqlDataSource) dataSource).setUser( "username" );
    ((MysqlDataSource) dataSource).setPassword("password" );
    ((MysqlDataSource) dataSource).setServerName("localhost" );
    ((MysqlDataSource) dataSource).setPort(3306);
    ((MysqlDataSource) dataSource).setDatabaseName("alfrescoreporting" );
    DataSource ds = (javax.sql.DataSource)dataSource;
    InitialContext context = createContext();
    context.rebind( "java:/comp/env/jdbc/" +source, ds);
    System. out .println("exit setJndiDataSource" );
Remind that the unexportObject() method only works with the exact object as returned by createRegistry() call … I invoked startRegistry() and setJndiDataSource() before and stopRegistry() after Pentaho’s  reportProcessor.processReport() and got exactly what I needed!  (I suggest you call the stopRegistry() in a finally part of the try/catch block around the processReport()).
Now I was able to build my own JNDI provider that actually allowed me to execute a Pentaho JNDI-based report from the command-line (e.g. without any application server).
Running a report from within Alfresco
It would be too easy if my command-line code would work inside an application server too. Th application Server (Tomcat in my case) owns the Registry. You can access the registry read-only, but not rebind and therefore ‘dynamically’ adding the appropriate details for any given JNDI name. This actually makes sense of course.
Basically, define a JNDI source within Tomcat (or application server of choice). I followed Tomcat’s example, and added
<Resource defaultTransactionIsolation="-1" defaultAutoCommit="false"
    maxActive="15" maxIdle="3" initialSize="1"
    username="username" password="password"
    type="javax.sql.DataSource" auth="Container"
to my META-INF/context.xml. My web.xml was enahnced with:
    <description>Alfresco Reporting JNDI definitition</description>
You also need to make sure your database driver (mysql-connector-java-5.x.yy.jar, or any Postgres, Oracle, MSSql equivalent) is located in tomcat/lib. (Usually it is already there.)
According the guys from Tomcat, you’re done. However, it doesn’t work. Apparently you also need to tweak <applicationname>.xml (in my case: alfresco.xml) in tomcat/conf/Catalina/localhost. You need to insert exactly the same line(s) as added to context.xml above.
And now we’re done. Pentaho reports are executed using the Java API in a web application like Alfresco using JNDI!
2013-01-24: NoteToSelf: NEVER assign a DataFactory to a JNDI based report object. It will never execute that way.
2013-04-24: Update project logo to comply with Alfresco’s trademark guidelines and policies

1 Response to “Executing JNDI based Pentaho reports using the Java API”

  1. 1 anonymousbi May 14, 2012 at 14:06

    Great resource check my blog, I will try to make a POC with your post
    thanks 🙂

Comments are currently closed.