User development, The document "JBossCacheAndWebLogic", was updated Feb 22, 2010 by Manik Surtani. To view the document, visit: http://community.jboss.org/docs/DOC-10252#cf Document: -------------------------------------------------------------- h2. JBossCacheAndWebLogic   This page acts as a landing page for configuring WebLogic to start up an instance of JBossCache and bind it to local JNDI so it is accessible to applications deployed within WebLogic.   To demonstrate a working cache, I've created a web app, which contains a JSP that allows you to add elements to the cache under a specified node.  Another servlet allows you to view the contents of the cache, and manipulate contents.  In addition to the web app, I've created a j2ee services class, which handles the startup and shutdown of the JBossCache within WebLogic.   h3. The environment   This code has been tested with JBossCache 1.1.x, 1.2.x and 1.3beta, and has been run with Sun JDK 1.4.2 and 1.5.0, as well as BEA JRockit 1.4.2 and 1.5.0.  All tested on a RHEL 3.0 server running on dual x86 CPUs.   h3. Building the sample code   Download the sample code JBossCacheAndWebLogic-src.zip.  Pls ignore the attachments at the bottom of this page (including binaries - these will be removed shortly).  Pls always use the srcs and build these against the JBossCache and WebLogic distros you use).   The sample code requires http://ant.apache.org, most versions should do.  Simply unzip the sample code, edit the build.properties file to point to your JBossCache distro and the weblogic.jar file from your WebLogic installation, and run +ant+.  The build file will generate a jar file containing the startup and shutdown classes, and a war file containing a sample application that uses this.   h3. Your classpath   The jar file containing the startup and shutdown class (see the section above on building the startup and shutdown classes), as well as the path to the JBossCache configuration, should both be in your WebLogic classpath before starting the WebLogic servers.  In addition, the lib jars (that come with your JBossCache distro) should be in your WebLogic classpath.   ** commons-logging.jar ** concurrent.jar ** javassist.jar ** jboss-aop.jar (optional, only if you use AOP) ** jboss-cache.jar ** jboss-common.jar ** jboss-jmx.jar ** jboss-system.jar ** jgroups.jar ** log4j.jar ** trove.jar (optional, only if you use AOP)   You will need a path to a jboss-cache compliant XML configuration file (please read the http://docs.jboss.org/jbcache/TreeCache.html#d0e607 for this). The binary above looks for +etc/jbosscache-config.xml+ in your classpath. It is also a good idea to have your log4j configuration file in the classpath!!   You are now ready to start up your WebLogic instances.   h3. Configuring your WebLogic   * http://community.jboss.org/docs/DOC-9369 * http://community.jboss.org/docs/DOC-9370   h3. Sample Servlet   For the sake of example, I use plain, ordinary servlets in the sample webapp.  I have an abstract servlet class, CacheServlet, which has a protected getCache() method.  This servlet also maintains a static reference to the TreeCache object bound in JNDI by my startup class.  This saves on JNDI lookups every time the TreeCache is needed.   The other servlet classes simply subclass CacheServlet, and can access the TreeCache in JNDI by using CacheServlet.getCache().  By using this method to access the TreeCache, the demo servlets have full access to the JBossCache service.   Simply deploy the WAR file above to your WebLogic cluster (that has been started up with the j2ee service configured as a startup/shutdown class), and browse to http://your-server/JBossCacheServlet/.   You will be allowed to add values to your cache, and to display the contents of the cache.   Now try accessing this same webapp on another server in your cluster.  You should be able to make changes to the cache there as well, and have the changes replicated to all servers in the cluster.   Experiment and play around   h3. Using this code in your projects   This code has been written purely as an example.  I would recommend several improvements/enhancements to it before you attempt to use this in a real, live environment:   ** The JBossCacheManager class should refer to a config file (even just a simple properties file) for details on how to connect to the JNDI tree. ** It should also get the JNDI name it binds the TreeCache to from it's configuration. ** The JNDI initial context lookup code is very WebLogic-specific and probably ought to be genericised (i.e., don't use weblogic.jndi.Environment) ** The above comment holds true for the CacheServlet as well. ** Write a singleton helper class (not dissimmilar in function to CacheServlet) if you want other classes to have access to the distributed cache.   That's it!   h3. Registering JBoss Cache as an MBean in WebLogic   If you want use JBoss Cache as an MBean in WebLogic, have a look here: JBossCacheMBeansWithBeaWeblogic   h3. Startup and Shutdown classes   * See http://edocs.bea.com/wls/docs81/ConsoleHelp/startup_shutdown.html on registering startup and shutdown classes. * See http://edocs.bea.com/wls/docs90/programming/lifecycle.html on how to write a startup and shutdown class. * Your startup class should:     Create a cache using a configuration file.     Start the cache.     Bind the cache to JNDI * Your shutdown class should:     Retrieve the cache from JNDI.     Un-bind the cache from JNDI.     Stop the cache. * Create a helper JBossCacheManager class with a static getCache() method, which gets the cache from JNDI.     --------------------------------------------------------------