Also, this allows for fine-grained security at database level: Virtual Private Database.

(c) Oracle

As described in the above image and referenced article, the user identified by userid 106 (let’s say that’s user john) will access the database using a private database connection. The user can only access rows that have that userid as primary or foreign key.  John can’t see the passwords, orders, credit card data or anything of other users even if he would somehow hack the webapplication. How to set up this finegrained securiy is beyond this article, but I hope the above example explains what the purpose VPD is.

If you develop your JEE software using Oracle software  proxy authentication requires only a bit of configuration, for example, see the following article how to setup proxy authentication using JHeadstart.

However, what if you’re JEE applicication consists of non-oracle software? Can you still use proxy authentication when you use software like JBoss, Hibernate, IBatis, MyFaces, Wicket etc? Yes you can! I’ll explain below how to set up proxy authentication using JBoss in such a way you don’t have to modify any of the code that uses JDBC, directly or indirectly.

• First a way is needed to set a username for each (JDBC) database connection retrieved. It-eye weblog explains how to open a connection to a database using java, and then switch to another username.
• Secondly, in your application users should authenticate them self using the default mechanism of J2EE 1.4 (and higher) application, using JAAS. Usually creating a security policy inside your web.xml or inside your ear is enough. Here’s the information how to do this under JBoss: Secure a webapplication.
  Since we’re using a database, the best option would be to use database based authentication, meaning user information comes out of a database table. There’s a lot of documentation on the web how to do add security, so I won’t repeat that here.
• Database connection in JBoss are retrieved using connection pooling, as is custom in any JEE server.  You can create a custom connection pool, that changes the switches to the user name that is currently logged in at the webapplication. That way, every action on the database is done under a database user that is currently logged in.Do to be able to do that, first, you’ll need a custom connection factory that extends the default connection factory. Our connection factory will return a customized datasource that modifies code.Here’s a code listing:

  package nl.gerbrandict.dbconnaudit;
  
  import java.sql.SQLException;
  import javax.resource.ResourceException;
  import javax.resource.spi.ConnectionManager;
  
  import org.apache.log4j.Logger;
  import org.apache.commons.lang.StringUtils;
  import org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory;
  
  /**
   * An extended connection factory, that uses the Oracle feature to change the username of an existing connection
   *
  
   * When a user authenticated on the application server, the database connection will switch to that username.
   * This allows for better auditing and potentially for improved security.
   *
   * Properties (get'ers and set'ters) can be set via the configuration section of the -ds file
   * @author gvdieijen
   */
  public class DBConnAuditConnectionFactory extends LocalManagedConnectionFactory {
  
      private String defaultProxyUser;
  
      public DBConnAuditConnectionFactory() throws SQLException {
          super();
  
      }
  
      @Override
      public Object createConnectionFactory(ConnectionManager cm) throws ResourceException {
          return new OracleWrapperDataSource(this, cm);
      }
  
      public void setEnableProxySession(Boolean enableProxySession) {
          this.enableDbConnAudit = enableProxySession;
      }
  
      public void setDefaultProxyUser(final String defaultProxyUser) {
          if (StringUtils.isEmpty(defaultProxyUser)) {
              this.defaultProxyUser=null;
          } else {
               this.defaultProxyUser = defaultProxyUser;
          }
      }
  
      /**
       * Default db user to open proxy session for, when no authenticated user is active
       * @return
       */
      public String getDefaultProxyUser() {
      	return this.defaultProxyUser;
      }
  }

  As you can see, the file returns a OracleWrapperDatasource. That’s custom class, that extends the default WrapperDatasource of JBoss, and changes the user of jdbc connection just before the connection is handed of to the application. To speak in terms of the fine book

• Now, How can you use that new class? They have to be packed into a rar file. Functionally, that’s a Resource Adapter, a module that allows a J2EE application to use resources. Technically (and practically), it’s just a jar-archive similar to a war, with a different extension. Maven can create these files automatically for you, if you set the packaging type to rar instead of jar (which is the default).
• When you download JBoss, you’ll get a sample connection pool for a in-memory database: default-ds.xml, located in the server/default/deploy directory of jboss. To use the custom classses, copy the file into (for example) myoracleproxy-ds.xml and create a minor modification so a custom connection factory is used – update the managedconnectionfactory property, that a custom connectionfactory is used, that returns the proxied connections:

  <managedconnectionfactory-class>nl.gerbrandict.dbconnaudit.DBConnAuditConnectionFactory</managedconnectionfactory-class>

All in all, after some tweaking, all queries and updates to your Oracle database are done under the J2EE username. This means when user Joe logs in, all his database access will be logged under user Joe as well. This can improve auditing as well as security.

There are several possible answers to that question:

• Using a JMS, Java Messing Service. How to setup is beyond the scope of this weblog posting.
• Use of the Timerservice. The timerservice is part of JEE-spec (since 1.4). Using a few annotations you can have the same functionality as you would have when using threads – but compliant with the JEE-spec. I’ll explain how to use the TimerService, so you can stop worrying about not being JEE compliant (with regard to threads)!

The TimerService can only be used within a stateless EJB bean. So to start you’ll have to define one, by adding the right annotations:

..

@Stateless
public class MyTimerExampleBean implements MyTimerExample {

}
...
public interface MyTimerExample {
}

Within the bean you can inject the timerservice using the Resource annotation. As soon as the bean is deployed within an application server like JBoss, the bean is instantiated and the resources are injected and available for use.

    @Resource
    private TimerService timerService;

Now we’ll use our timerservice. We define a method called startMe and a method runMe. The startMe method will define a timer. The timer will then execute the runMe method after a predefined time.

When the runMe method is to be executed, the bean is newly instantiated. This means, if you set any local variables within your bean, those values will be lost. For that reason, we use the myInfo class to transfer parameters, in this case a delay and the message we want to print to the screen.

class HelloWorldInfo implements Serializable {
   String message;
   long delay;
   int counter;
}
public void startMe() {
    long waitTime =60*1000; //60 seconds, 1 minute
    HelloWorldInfo taskInformation=new HelloWorldInfo();
   taskInformation.message="Hello world";
   taskInformation.delay=12*1000; //12 seconds
   taskInformation.counter=0;

   Timer timer = timerService.createTimer(waitTime, taskInformation);

}
    @Timeout
    public synchronized void runMe(Timer timer) {

      final HelloWorldInfo myInfo = (HelloWorldInfo ) timer.getInfo();

      System.out.println("Going to do something important");
      Thread.wait(5000);
      System.out.println(myInfo.delay);
      System.out.println(myInfo.message);
  }

That’s all there is! Using the above code, will allow you to run code asynchronously in a similar fashion when using Thread and Runnable classes. You could for example call a remote webservice, or run a batch job on the database. The method runMe will run within a separate transaction – in case an error is thrown within the the runMe method, the transaction is rolled back. Since the bean is instantiated using the JEE-container, any resources associated with the bean will be discarded.

If you want want to execute the run method again, the easiest way is to call the startMe method again:

   public synchronized void runMe(Timer timer) {
     ...

   myInfo.counter++;
   myInfo.message="Doing hello world again for the "+myInfo.counter;
   myInfo.delay=6*1000; //now after 6 seconds

   Timer timer = timerService.createTimer(waitTime , myInfo
);
  }

The myInfo is modified and passed again to the timerserver. So next time the bean is instantiated and the run method is executed, it’ll display ‘Doing hello world again 1′, and will do so with an incrementing number until the application server is shut down. You can pass any information on, as long as the the class containing the information is serializable.

Bol.com Jboss in Action Javid Jamae & Peter Johnson

Take for example the console of the website called www.ccidgroup.net: what would happen when you hit destroy button on the MBean Inspector of the ROOT.war ?

JMX MBean View

…

I haven’t tried and I’ve sent a mail to webmaster@domain – but I’m slightly curious.

JGroups

A distributed application, where nodes of the application communicate with each other over a LAN using UDP. Each nodes discovers other nodes automatically, when a node crashes or shuts down, all nodes give notice automatically. And this is all possible without any application server, complicated configuration or what-ever-else with JGroups!

There are quite some tutorials, so I just list the basic steps to get started, most notably the maven dependencies.

Download JGroups

First download JGroups. You can get the latest version from the website JGroups. Alternatively, you can use Maven. First set up a maven-project, which is beyond the scope of this tutorial.

Add the JBoss repository, by adding the following entry to the repositories section of the maven project file (pom.xml):

<repository>

<id>maven.jboss.org</id>

<name>JBoss Maven Repository</name>

<url>http://repository.jboss.com/maven2</url>

</repository>

After that add the following dependencies to the Maven for the jgroups artifact (I use the current latest versions):

<dependency>

<groupId>jgroups</groupId>

<artifactId>jgroups</artifactId>

<version>2.7.0.GA</version>
</dependency>
<dependency>

<groupId>log4j</groupId>

<artifactId>log4j</artifactId>

<version>1.2.15</version>

</dependency>

Setting up a channel

To start using JGroups, no configuration or application server is necessary. In this posting very briefly a class will be that uses JGroups to transmit messages over nodes:

First import the necessary classes:

import org.jgroups.*;

Now set up a channel:

JChannel ch = new JChannel();

The code below you can put in a constructor of your class, so the JChannel is initalized only once. That’s all there is! When you run the application multiple times inside the network (or on your own machine, for testing), JGroups will automatically detect other nodes.

Now you can add a receiver to channel, to start receiving messages and being updated of new nodes.

This is possible by implementing the Receiver interface, as demonstrated below:

public class JGroupStart implements Receiver {

	private final static String CLUSTERNAME = "JGroups tutorial cluster";

	public JGroupStart() throws Exception {

		JChannel ch = new JChannel();
		ch.setReceiver(this);

		ch.connect(CLUSTERNAME);

        System.out.println("JGroups cluster is gestart");

        Thread.sleep(10000);

        Message m = new Message();
		m.setObject(new String("Hello world from node "+ch.getLocalAddressAsString()));
        ch.send(m);
	}

	public byte[] getState() {
        return null;
	}

	public void receive(Message message) {
		System.out.println("Messsage received: " + message.getObject());
	}

	public void setState(byte[] state) {

	}

	public void block() {
	}

	public void suspect(Address address) {
	}

	public void viewAccepted(View view) {
		System.out.println("A node has appeared or disappeared, got a new view: " + view);
		for (Address a : view.getMembers()) {
			System.out.println("Member address " + a);
		}
	}

	public static void main(String [] args) throws Exception {
		JGroupStart app=new JGroupStart();
	}
}

The class contains a main method so we can start it. After starting, a JGroups server – a node – in our network:

-------------------------------------------------------
GMS: address is 172.168.11.109:1999
-------------------------------------------------------
A node has appeared or disappeared, got a new view: [172.168.11.109:1999|0] [172.168.11.109:1999]
Member address 172.168.11.109:1999
JGroups cluster is gestart

To send a message over a channel, you can use the following code:

Message m = new Message();
		m.setObject("Hello world");
ch.send(m);

The setObject method accepts any Serializable class, in this case I just sent a simple String. All other nodes will receive this message:

Messsage received: Hello world

Allthough simple as that seems, the concept is powerful. As said, nodes discover eachother automatically. When a node crashes or disappears, other nodes are notified automatically. Naturally there are much more advanced examples then what I listed above. On the JGroups site there’s a article how to set up A simple clustered task distribution system.
Furthermore, JBoss 5.0GA contains a Cache: JBoss Cache. The distributed cache is built on top of JGroups. Using the JBoss Cache, JBoss can run distributed on multiple servers – this means if one server crashes or goes down for maintaince, another server takes over. Users or visitors of your site won’t even notice – except that the whole site might be a bit slower.
Of course the cache can be used outsite JBoss too. JBoss cache can be used standalone, allowing any Java application – standalone or not – to take advantage of this nice powerful open source technology.

1. In JBoss you have have a few standard configurations – limited, default, all . I tried to get clustering to work on the default configuration. I installed the pojocache, but then I had I had some problems getting @Replicated annotation to work (see also the posting below). After some Google’ing jboss errors something like AOP seemed have to be enabled.The Pojocache I got working, by downloading and adding the libraries myself. Then I found these libraries were already included in the all configuration.
   Still, the @Replicateble tag didn’t work. Just recently someone replied at my (slightly too frustrated) post at JBoss forum.
   The following options still need to be added to the run.sh or run.bat in the bin directory:

   set JAVA_OPTS=-Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true -Djboss.platform.mbeanserver  -javaagent:%JBOSS_HOME%/server/all/deployers/jboss-aop-jboss5.deployer/pluggable-instrumentor.jar %JAVA_OPTS%

   I haven’t tried the above option yet – I used the Serializable interface, although that’s a whole lot less powerful of course.
   Note you can use multiple java agents, so in case you use another agent like javarebel, that shouldn’t be a problem.

2. A nice thing in JBoss seemed the PojoCache. To get it to work, you’ll have to create a pojocache-service.xml (see PojoCache manual) and put the file in the server\all\deploy directory of your jboss-directory. After that you can reference the PojoCache using the following code:

   MBeanServer server = MBeanServerLocator.locateJBoss();
   
   ObjectName on = null;
   
   try {
   
   on = new ObjectName("jboss.cache:service=PojoCache");
   
   } catch (MalformedObjectNameException e) {
   
   throw new ContinuAansturingException("Cache service niet correct geconfigureerd.", e);
   
   }
   
   PojoCacheJmxWrapperMBean cacheWrapper = (PojoCacheJmxWrapperMBean)
   
   MBeanServerInvocationHandler.newProxyInstance(server, on,
   
   PojoCacheJmxWrapperMBean.class, false);
   
   PojoCache cache = cacheWrapper.getPojoCache();
   

3. Clustering Session beans -I needed a share state, for the time the application was running (no need for persistence). Using a clustered cache seemed perfect for that. I decided to use the @Clustered annotation, that works out-of-the-box, I do not have to configure the pojocache. Due to my lack of EJB-knowledge and hindsight, I thought to annotate a Stateful bean – seemed reasonable to get a shared state. As people with slightly more EJB experience known – a Stateful bean isn’t meant for that! The state is only kept inside a (user) transaction. As soon as the transaction is commit’ed or rolled back, the state is lost.
   Cost my some time before I figured that out, after a few null references.
4. Setting up the right node id and listening to right network interface – For nodes to discover each other, they have to listen to a network interface that connects them to eachother. By default JBoss will listen to localhost, so only nodes running on the same server will be detected. Naturally, you normally don’t nodes to discover eachother. This is possible by adding the following command-line arguments: –b 10.0.0.53 (where you can replace 10.0.0.53 with the correct network -address)
   Furthermore, all nodes in the network have to have a unique nodeid. This can be set by the following command-line argument: -Djboss.messaging.ServerPeerID=2 where you can replace the 2 with any unique identifier.
   As listed above, you need the ‘all’ configuration, or a copy there of. So an example of complete command to run jboss on windows would be:

   run -c all –b 10.0.0.53 -Djboss.messaging.ServerPeerID=2

All in all, having a good book sooner would have saved me quite some time before. I now have the very recently released JBoss in Action. The book helps a lot in understanding and using JBoss because the JBoss site is seriously lacking in good documentation. Maybe that’s the price you pay for using open-source: the only way Redhat can make money on JBoss is on support.

Bol.com Jboss in Action Javid Jamae & Peter Johnson

I could successfully instantiate a cache, using the default factory class. However, a more proper way would be to have JBoss instantiate and manage the cache, since the application has to run on top of JBoss.

In the JBoss Cache documentation I’ve found the following entry:

CacheFactory factory = new DefaultCacheFactory();

// Build but don't start the cache

// (although it would work OK if we started it)

Cache cache = factory.createCache("cache-configuration.xml");

MBeanServer server = getMBeanServer(); // however you do it

ObjectName on = new ObjectName("jboss.cache:service=Cache");

JmxRegistrationManager jmxManager = new JmxRegistrationManager(server, cache, on);

jmxManager.registerAllMBeans();

... use the cache

... on application shutdown

jmxManager.unregisterAllMBeans();

cache.stop();

Sounds great doesn’t it? Well, first of all, it’s an awful lot of code just to get access to the cache. Secondly, there’s a reference to a configuration file you first have to place somewhere, and thirdly there’s the line that’s commented with:

// however you do it

Arg! Why can’t those people of JBoss just explain *how* I have to do that. You might say, a clustered cache is complicated stuff. Transactions, commits over network, multi casts. That’s all pretty complicated. However, this configuration crap has nothing to do with that. I *hate* configuration. I *hate* xml. I just want working stuff.

O well, most closed source software isn’t much better, if not much worse. Probably what the people behind JBoss wants users to do, is buy a support contract. Still a lot less expensive than software like Weblogic or Websphere.