Posted in Uncategorized

GlassFish V3 admin console taking too much time to load

GlassFish V3 admin console taking too much time to load.

If you have installed Glassfish V3 and trying to load admin console, but after signing in, is it taking too much time to get to the main page ? Do you have server.log entry like this:

admin console: initSessionAttributes()
Cannot refresh Catalog : Connection timed out

then its time to tweak some files. Here its how:

1. Update the %GLASSFISH_HOME/glassfish/domains/domain1/domain.xml

  1. <java-config>
  2. <jvm-options><!–jvm-options>
  3. <!–java-config>

This will block up the News item, the registration item, etc

2. Remove update tool jar
(Backup and remove this JAR)


Delete this dir:



Now start the server (bin/asadmin start-domain) and you will see the admin console won’t be hang up and take you directly to main page.

copy from:

Posted in Uncategorized

Adapter Pattern

In computer programming, the adapter pattern (often referred to as the wrapper pattern or simply a wrapper) is a design pattern that translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer (i.e. flags) but your client requires a ‘true’/’false’, the adapter would be responsible for extracting the appropriate values from the integer value. Another example is transforming the format of dates (e.g. YYYYMMDD to MM/DD/YYYY or DD/MM/YYYY).

There are two types of adapter patterns:

Object Adapter pattern

In this type of adapter pattern, the adapter contains an instance of the class it wraps. In this situation, the adapter makes calls to the instance of the wrapped object.

The object adapter pattern expressed in UML. The adapter hides the adaptee’s interface from the client.

The object adapter pattern expressed in LePUS3.

Class Adapter pattern

This type of adapter uses multiple polymorphic interfaces to achieve its goal. The adapter is created by implementing or inheriting both the interface that is expected and the interface that is pre-existing. It is typical for the expected interface to be created as a pure interface class, especially in languages such as Java that do not support multiple inheritance.

The class adapter pattern expressed in UML.

The class adapter pattern expressed in LePUS3

The adapter pattern is useful in situations where an already existing class provides some or all of the services you need but does not use the interface you need. A good real life example is an adapter that converts the interface of a Document Object Model of an XML document into a tree structure that can be displayed. A link to a tutorial that uses the adapter design pattern is listed in the links below.

A further form of runtime Adapter pattern

There is a further form of runtime Adapter pattern as follows:

It is desired for classA to supply classB with some data, let us suppose some String data. A compile time solution is:


However, suppose that the format of the string data must be varied. A compile time solution is to use inheritance:

Format1ClassA extends ClassA {    public String getStringData() {       return format(toString());    } }

and perhaps create the correctly “formatting” object at runtime by means of the Factory pattern.

A solution using “adapters” proceeds as follows:

(i) define an intermediary “Provider” interface, and write an implementation of that Provider interface which wraps the source of the data, ClassA in this example, and outputs the data formatted as appropriate:

public interface StringProvider {     public String getStringData(); }   public class ClassAFormat1 implements StringProvider {     ClassA classA;       public ClassAFormat1(ClassA classA) {         this.classA = classA;     }       public String getStringData() {         return format(classA.toString());     } }

(ii) Write an Adapter class which returns the specific implementation of the Provider:

public class ClassAFormat1Adapter extends Adapter {    public Object adapt(Object o) {       return new ClassAFormat1((ClassA) o);    }      public boolean isAdapterFor(Class c) {       return c.equals(StringProvider.class);    } }

(iii) Register the Adapter with a global registry, so that the Adapter can be looked up at runtime:

AdapterFactory.getInstance().registerAdapter(ClassA.class, ClassAFormat1Adapter.class, "format1");

(iv) In your code, when you wish to transfer data from ClassA to ClassB, write:

Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format1"); StringProvider provider = (StringProvider) adapter.adapt(classA); String string = provider.getStringData(); classB.setStringData(string);

or more concisely:

classB.setStringData(((StringProvider) AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format1").adapt(classA)).getStringData());

(v) The advantage can be seen in that, if it is desired to transfer the data in a second format, then look up the different adapter/provider:

Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format2");

(vi) And if it is desired to output the data from ClassA as, say, image data in Class C:

Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, ImageProvider.class, "format1"); ImageProvider provider = (ImageProvider) adapter.adapt(classA); classC.setImage(provider.getImage());

(vii) In this way, the use of adapters and providers allows multiple “views” by ClassB and ClassC into ClassA without having to alter the class hierarchy. In general, it permits a mechanism for arbitrary data flows between objects which can be retrofitted to an existing object hierarchy.

Implementation of Adapter pattern

When implementing the adapter pattern, for clarity use the class name [AdapteeClassName]To[Interface]Adapter, for example DAOToProviderAdapter. It should have a constructor method with adaptee class variable as parameter. This parameter will be passed to the instance member of [AdapteeClassName]To[Interface]Adapter.

Class SampleAdapter implements ClientClass {     private AdapteeClass mInstance;     public SampleAdapter(AdapteeClass instance)     {          mInstance=instance;     }     @Override     public void ClientClassMethod()     {        // call AdapteeClass's method to implement ClientClassMethod     }   }

Posted in Uncategorized

Bridge Pattern


The bridge pattern is a design pattern used in software engineering which is meant to “decouple an abstraction from its implementation so that the two can vary independently”.[1] The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

When a class varies often, the features of object-oriented programming become very useful because changes to a program‘s code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does vary often. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

The bridge pattern is often confused with the adapter pattern. In fact, the bridge pattern is often implemented using the class adapter pattern, e.g. in the Java code below.

Variant: The implementation can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized.

Related pattern:

Template Pattern, Strategy Pattern

Similar Pattern:

Adapter Pattern

/** "Implementor" */ interface DrawingAPI {     public void drawCircle(double x, double y, double radius); }   /** "ConcreteImplementor"  1/2 */ class DrawingAPI1 implements DrawingAPI {    public void drawCircle(double x, double y, double radius) {         System.out.printf(" at %f:%f radius %f\n", x, y, radius);    } }   /** "ConcreteImplementor" 2/2 */ class DrawingAPI2 implements DrawingAPI {    public void drawCircle(double x, double y, double radius) {          System.out.printf(" at %f:%f radius %f\n", x, y, radius);    } }   /** "Abstraction" */ abstract class Shape {    protected DrawingAPI drawingAPI;      protected Shape(DrawingAPI drawingAPI){       this.drawingAPI = drawingAPI;    }      public void draw();                             // low-level    public void resizeByPercentage(double pct);     // high-level }   /** "Refined Abstraction" */ class CircleShape extends Shape {    private double x, y, radius;    public CircleShape(double x, double y, double radius, DrawingAPI drawingAPI) {       super(drawingAPI);       this.x = x;  this.y = y;  this.radius = radius;     }      // low-level i.e. Implementation specific    public void draw() {         drawingAPI.drawCircle(x, y, radius);    }       // high-level i.e. Abstraction specific    public void resizeByPercentage(double pct) {         radius *= pct;    } }   /** "Client" */ class BridgePattern {    public static void main(String[] args) {        Shape[] shapes = new Shape[] {            new CircleShape(1, 2, 3, new DrawingAPI1()),            new CircleShape(5, 7, 11, new DrawingAPI2()),        };          for (Shape shape : shapes) {            shape.resizeByPercentage(2.5);            shape.draw();        }    } }