I know that I know nothing

What's the difference between <%@ include file="header.html" %> and <jsp:include page="header.jsp" />

clock April 9, 2015 21:18 by author Administrator



1) The include directive: <%@ include file="header.html" %>

Static: adds the content from the value of the file attribute to the current page at translation time. The directive was originally intended for static layout templates, like HTML headers.
2) The <jsp:include> standard action <jsp:include page="header.jsp" />

Dynamic: adds the content from the value of the page attribute to the current page at request time. Was intended more for dynamic content coming from JSPs.
3) The <c:import> JSTL tag: <c:import url=”” />

Dynamic: adds the content from the value of the URL attribute to the current page, at request time. It works a lot like <jsp:include>, but it’s more powerful and flexible: unlike the other two includes, the <c:import> url can be from outside the web Container!


ref :


create client-side web service using wsimport

clock June 6, 2014 13:00 by author Administrator


create java code

wsimport -keep -verbose soap.wsdl



create jar file

wsimport -clientjar wsclient.jar soap.wsdl


Weblogic fast-swap

clock May 17, 2013 22:23 by author Administrator

This is something that could eat up time in any bigger project. If you make changes to your working application and you need to track down bugs, it's inevitable to redeploy your application on any change. What is done in seconds, if you
a) know the WLS administration and/or
b) your application is quite lean

If you have a fullblown JEE application with all the magic inside, it's no problem to wait for a successful redeployment for minutes.
In practice there are some ways to get rid of this overhead very quickly.

1) Weblogic's ChangeAwareClassLoader (WLS <=10.x)
Java classloaders do not have any standard mechanism to undeploy or unload a set of classes, nor can they load new versions of classes. In order to make updates to classes in a running virtual machine, the classloader that loaded the changed classes must be replaced with a new classloader. When a classloader is replaced, all classes that were loaded from that classloader (or any classloaders that are offspring of that classloader) must be reloaded. Any instances of these classes must be re-instantiated. If you deploy an exploded application and run the WLS in development mode, you can take advantage from the ChangeAwareClassloader. If you make changes to a single class, the WLS simply replaces the whole classloader and starts over with your newly created class. This was one of the first approaches to quicker development roundtrips. Anyway it is still not the solution for bigger applications.

2) Weblogic Fast-Swap (WLS >=10.x)
Java EE 5 introduces the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing instances. This allows containers to reload altered classes without disturbing running applications, vastly speeding up iterative development cycles and improving the overall development and testing experiences. The usefulness of the Java EE dynamic class redefinition is severely curtailed, however, by the restriction that the shape of the class – its declared fields and methods – cannot change. The purpose of FastSwap is to remove this restriction in WLS, allowing the dynamic redefinition of classes with new shapes to facilitate iterative development.

With FastSwap, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately.

    • FastSwap is only supported when WLS is running in development mode. It is automatically disabled in production mode.
    • Only changes to class files in exploded directories are supported. Modifications to class files in archived applications, as well as archived JAR files appearing in the application’s classpath are not supported.

To enable FastSwap in your application, add <fast-swap>true</fast-swap> to the weblogic-application.xml file.

FastSwap can also be enabled for a standalone web-application by adding the <fast-swap> element to the weblogic.xml file.

Once FastSwap is enabled at the descriptor level, an appropriate ClassLoader is instantiated when the application is deployed to WLS. It is recommended that you have your IDE setting set to "compile-on-save" so that java files are compiled on saving. The FastSwap agent tries to find all classes that have been modified since the last iteration by looking at all directories in the classpath.

FastSwap is supported with POJOs (JARs), Web applications (WARs) and enterprise applications (EARs) deployed in an exploded format. FastSwap is not supported with resource adapters (RARs).


Supported changes:
    • Addition and Removal of static methods
    • Addition and Removal of instance methods
    • Changes to static and instance method bodies
    • Addition and Removal of static fields
    • Addition and Removal of instance fields
    • Java Reflection results do not include newly added fields and methods and include removed fields and methods. As a result, use of the reflection API on the modified classes can result in undesired behavior.
    • Changing the hierarchy of an already existing class is not supported by FastSwap. For example, either a) changing the list of implemented interfaces of a class; or b) changing the superclass of a class, is not supported.
    • Addition or removal of Java annotations is not supported by FastSwap, since this is tied to the reflection changes mentioned above.
    • Addition or removal of methods on EJB Interfaces is not supported by FastSwap since an EJB Compilation step is required to reflect the changes at runtime.
    • Addition or removal of constants from Enums is not supported.
    • Addition or removal of the finalize method is not supported.

When FastSwap is enabled, after you recompile a class, FastSwap attempts to redefine classes in existing classloaders. If redefinition fails because your changes fall outside the scope of supported FastSwap changes, the JVM throws an UnsupportedOperationException in the WLS window and in the server log file. Your application will not reflect the changes, but will continue to run.


Fluent Object Creation

clock January 23, 2013 22:02 by author Administrator
Many posts have been written on this subject (overwhelmingly many) but I just wanted to contribute my two-cents and write a short post about how I use the Fluent Object Creation pattern or object builders in Java to instantiate Value Objects.

 Value Objects are abstractions that are defined by their state (value) rather than their address in memory. Examples of value objects are things like money, a number, a coordinate, etc. They are used not to describe Business Objects but rather descriptions of concrete indivisible entities.  Also, they make great candidates for adding them to collections and maps.

In Java, Value Objects should be declared final and provide no setter methods, basically making it's state immutable after creation, this is a very important requirement. Declaring them final makes them unable to serve as parent objects. This is done by design since value objects should model small and concrete entities. The reason being is that we should be able to create and compare multiple copies of these objects, which is always done by state not by reference. In addition, you should declare proper equals() and hashCode() methods to qualify for a proper value object.

In C++, the same principles apply. In C++ you should make use of the Copy Constructor and overload the assignment and comparison operators.  

The Fluent Object Creation pattern makes value object instantiation elegant and clean. There are many benefits that can be gained by using fluent object creation as we will see shortly. 




The end result of applying this pattern from the API user's perspective will look like the following:


Money fiveEuros = new Money.Builder()
   .reverse("Map of Europe")
   .obverse("Map of Spain")

I think you would agree that this pattern flows a lot more smoother as opposed to this:

Money fiveEuros = new Money();
fiveEuros.reverse("Map of Europe");
fiveEuros.obverse("Map of Spain");
List<String> colors = new ArrayList<String>();
for(String color: new String[] {"Bronze", "Silver"}) {

Which seems broken and has lots of typing and repetition. This is an example of building a pretty big  value object in my opinion, most of tend to be very small.

Before we talk about the benefits of creating objects this way, let's have a look at the structure of this pattern:

public final class Money {
      private Long value;
      private String countryOfOrigin;     
      private Currency currency;
      private String type; 
      private String reverse;
      private String obverse;    
      private List<String> colors;
     private Date year;    
      private Money() {   }

     // -- getters, hashCode, equals -- //

     // Static inner Builder class
   publicstaticclass Builder {
        private Money _temp = new Money();
        public Builder countryOfOrigin(String countryOfOrigin) {
_temp.contryOfOrigin = countryOfOrigin;
public Builder currency(Currency c) {
_temp.currency = c;
public Builder type(String t) {
_temp.type = t;
public Builder reverse(String r) {
_temp.reverse = r;

       public Builder obverse(String o) {
_temp.obverse = o;
return this;

public Builder addColor(String c) {
if(_temp.colors == null) {
              _temp.colors = new ArrayList<String>(); 
return this;
         public Builder year(String y) {
              if(y == null || y.isEmpty()) {
                  _temp.year = new Date();
              else {
                  _temp.year = DateFormat.parse(y);
return this;
public Money build() {
                // Validate object
               if(Strings.isNullOrEmpty( || _temp.currency == null) {
                  throw new IllegalArgumentException("Coin currency and value required");
    } }

This is also a matter of taste, but I prefer the static inner class approach. I like the canonical nature of referring to the builder as Money.Builder. Also making it static is required since the builder instance needs to live independently of the enclosing class.

I like this pattern because it has the following benefits:

  1. Greater object encapsulation: I can easily enforce object construction using builders by making the Money constructor private (this is just stylistic). This completely hides all of the intricacies of creating this object: list creation, date parsing, etc. From the user's perspective, what we end up with is an object that is simple to instantiate. My illustration is a very simple one, but imagine more complex object graphs.
  2. Code readability: Using this pattern to create objects, makes unit tests and code very easy to read and follow. 
  3. Less typing in the long run: Even though you have to add an extra builder method for every added attributes, the amount of typing you save in the long run makes it worth while. 


Using the fluent creation pattern is more work up front, but the benefits of having it pays off at the end. It makes instantiating objects very elegant and clean. You don't have to use it with Value Objects, most of the benefit of using Fluent Object Creation is when you need to build pretty complex object graphs, but I wanted to show that it can also suit small value objects.





retrieve currently logged-in users using the SessionRegistry

clock December 28, 2012 17:04 by author Administrator

creating and manipulating Microsoft Office(Word docx, Powerpoint pptx, and Excel xlsx) in java

clock October 25, 2012 18:03 by author Administrator

Create complex Word (.docx) documents programatically with docx4j

lvdpal's  Creating Word documents with Docx4j, which covers tables in some detail

Jos Dirksen's  Create complex Word (.docx) documents programatically with docx4j

Joshua Born's  Creating Word Documents in Java

Glen Smith's  Creating Word docx documents dynamically from Grails (or Java)

  Spring MVC (Russian)

java api

java captcha

clock October 5, 2012 18:46 by author Administrator

file upload

clock September 24, 2012 21:24 by author Administrator,1,32.html

Spring Security (redirecting to "/favicon.ico" after login )

clock September 21, 2012 21:38 by author Administrator

The issue is, when the browser cache is empty and a user comes in, here is what happens:

  • the user requests URL "/". This URL is cached.
  • the browser makes a requests to "/favicon.ico". This URL becomes the new URL where to redirect to upon authentication.
  • the user posts the login form and is redirected to "/favicon.ico".

To fix this, you need to set "/favicon.ico" as being a non-secured resources:

<intercept-url pattern="/favicon.ico" access="ROLE_ANONYMOUS" />

Top 10 Eclipse Shortcuts

clock August 24, 2012 23:04 by author Administrator


Here are some of my most used keyboard shortcuts for the Eclipse IDE.

  • Code Assist (CTRL + Space)

  • Quick Fix (CTRL + 1)

  • Refactoring (ALT + SHIFT + T)

  • Source (ALT + SHIFT + S)

  • Surround With (ALT + SHIFT + Z)

  • Delete Rows (CTRL + D)

  • Call Hierarchy (CTRL + ALT + H)

  • Quick Type Hierarchy (CTRL + T)

  • Quick Outline (CTRL + O)

  • Show All Shortcuts (CTRL + SHIFT + L)


About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog

Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...


Month List

Sign In