google Analytics

Tuesday, October 19, 2010

Java Exception Chaining

public void printStackTrace()



Prints this throwable and its backtrace to the standard error stream. This method prints a stack trace for this Throwable object on the error output stream that is the value of the field System.err. The first line of output contains the result of the toString() method for this object. Remaining lines represent data previously recorded by the method fillInStackTrace(). The format of this information depends on the implementation, but the following example may be regarded as typical:


at MyClass.mash(
at MyClass.crunch(
at MyClass.main(

This example was produced by running the program:

class MyClass {
public static void main(String[] args) {
static void crunch(int[] a) {
static void mash(int[] b) {



The backtrace for a throwable with an initialized, non-null cause should generally include the backtrace for the cause. The format of this information depends on the implementation, but the following example may be regarded as typical:

HighLevelException: MidLevelException: LowLevelException
at Junk.a(
at Junk.main(
Caused by: MidLevelException: LowLevelException
at Junk.c(
at Junk.b(
at Junk.a(
... 1 more
Caused by: LowLevelException
at Junk.e(
at Junk.d(
at Junk.c(
... 3 more

Note the presence of lines containing the characters "...". These lines indicate that the remainder of the stack trace for this exception matches the indicated number of frames from the bottom of the stack trace of the exception that was caused by this exception (the "enclosing" exception). This shorthand can greatly reduce the length of the output in the common case where a wrapped exception is thrown from same method as the "causative exception" is caught. The above example was produced by running the program:

public class Junk {
public static void main(String args[]) {
try {
} catch(HighLevelException e) {
static void a() throws HighLevelException {
try {
} catch(MidLevelException e) {
throw new HighLevelException(e);
static void b() throws MidLevelException {
static void c() throws MidLevelException {
try {
} catch(LowLevelException e) {
throw new MidLevelException(e);
static void d() throws LowLevelException {
static void e() throws LowLevelException {
throw new LowLevelException();

class HighLevelException extends Exception {
HighLevelException(Throwable cause) { super(cause); }

class MidLevelException extends Exception {
MidLevelException(Throwable cause) { super(cause); }

class LowLevelException extends Exception {



Tuesday, October 12, 2010

JBOSS Clustering

JBOSS JMS clustering


run.bat -c node1 -g PartitionA -u -b localhost -Djboss.messaging.ServerPeerID=1
run.bat -c node2 -g PartitionB -u -b localhost -Djboss.messaging.ServerPeerID=2


JBoss Messaging clusters JMS queues and topics transparently  across the cluster. Messages sent to
a distributed queue or topic on one node are consumable on other nodes. To designate that a particular destination is clustered, simply set the Clustered attribute in the destination deployment descriptor to true:

<mbean code="org.jboss.jms.server.destination.QueueService"
<depends optional-attribute-name="ServerPeer">
<attribute name="Clustered">true</attribute>

Configuring EJB 3.0 Stateful Session Bean cache
The @org.jboss.ejb3.annotation.CacheConfig Annotation


Configuring entity caching

<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.region.factory_class"
<property name="hibernate.cache.region.jbc2.cachefactory" value="java:CacheManager"/>
<property name="hibernate.cache.region.jbc2.cfg.entity" value="mvcc-entity"/>
<property name="hibernate.cache.region.jbc2.cfg.collection" value="mvcc-entity"/>



import javax.persistence.*;
import org.hibernate.annotations.*;
@Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class ProductEntity implements Serializable {
//deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-configs.xml & jboss-cache-manager-jboss-beans.xml


Clustering web applications

Configuring HTTP replication

In web.xml add adding the<distributable /> tag

. . . . .
<distributable />

Refer :jbossweb.deployer\META-INF\war-deployers-jboss-beans.xml

The jboss-web.xml

<!DOCTYPE jboss-web PUBLIC
-//JBoss//DTD Web Application 5.0//EN>



Jboss  clustering Example
Clustering Web Using Jboss
JMS Clustering Example
Running Jboss in Clustering Mode


Thursday, October 7, 2010

JtaTransactionManager Bean

JtaTransactionManager Bean

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
<bean id="jtaTransactionManager"

By default, the JtaTransactionManager will attempt to automatically detect a UserTransaction
bound to the java:comp/UserTransaction JNDI name; if the java:comp/UserTransaction object also
implements the TransactionManager, the JtaTransactionManager will use that; if the java:comp/
UserTransaction does not implement the TransactionManager, the JtaTransactionManager will attempt
to find the TransactionManager under these JNDI names:
  1. • java:comp/UserTransaction: The default JNDI name, used by Resin 2.x, Oracle OC4J (Orion),
  2. JOnAS (JOTM), BEA WebLogic, and IBM WebSphere
  3. • java:pm/TransactionManager: JNDI name for TransactionManager in Borland Enterprise Server and Sun Application Server (Sun ONE 7 and later)
  4. • java:comp/TransactionManager: JNDI name used in Resin 3.x
  5. • java:/TransactionManager: The name used in the JBoss Application Server


jtatransactionmanager example
jtatransactionmanager spring example
jtatransactionmanager hibernate