Java,J2ee,Hybris E-commerce suit,Apache Ofbiz ,database, E-commerce domain Experts

Difference between getRequestDispatcher method of the ServletRequest interface and that of the ServletContext interface?

RequestDispatcher getRequestDispatcher(String path) - the same method belongs to both the ServletRequest interface and the ServletContext interface. This method returns a RequestDispatcher object for the resource (dynamic or static) located at the given path. We can use this RequestDispatcher object to forward a request to the resource or to include the resource in a response.

Difference between the two getRequestDispatcher methods

The difference between ServletRequest.getRequestDispatcher(String path) and ServletContext.getRequestDispatcher(String path) is that the former can accept a relative path as well whereas the latter can accept paths relative to the current context root only.

If the path starts with a '/' in the getRequestDispatcher(String path) of the ServletRequest interface then it's interpreted as being relative to the current context root otherwise it'll be a relative to the request of the calling servlet. Whereas, the path of the getRequestDispatcher(String path) of the ServletContext interface must start with '/' only - being relative to the current context root.

Another difference between the two is that path of the getRequestDispatche(String path) of the ServletRequest interface cannot extend outside the current servlet context whereas getRequestDispatcher(String path) of the ServletContext can use the getContext(String uripath) method to obtain RequestDispatcher for resources in foreign contexts.

Java Web service : Ways of combining Web Services. Orchestration vs Choreography

As we know that Web Services are actually application components each of which normally performs one discrete functionality of the overall application. So, we definitely need some way of combining these individual components to make the entire application work. There are two popular ways of combining Web Services, which are:-

Orchestration - we have a central controller in this case and it can be executed
Choreography - we don't have any controller here and it can't be executed directly

Orchestration

In this case we have a central controller process which controls and co-ordinates all the Web Services involved in the application. This central process can be a Web Service a well. The point to note in this case is that all other Web Services don't really know that they are participating in a higher-level business process. How the participating Web Services will be called, what will be the control flow, what all transformation will take place, ... these all things are known only to the central controller process. The other Web Services simply honor the requests whenever called. The below diagram makes it quite easier to understand the overall process.

Since Orchestration provides a controlled environment hence alternative scenarios can be used in case a fault occurs in the normal flow. For example, suppose we need to call a Web Service which may result into fault and in such a case we may need to either call another Web Service OR to simply use a default value. IN case of Orchestration it's very easy to achieve - maybe by just having a switch activity to transfer the control either to the alternative Web Service OR to compute the required Default Value.

Choreography

Here we don't have any central controller process and hence all the participating Web Services know when to call, whom to interact, when to execute operations, etc. We can visualize choreography just like a collaborative effort of many participating Web Services and since we don't have any controller hence all the Web Services need to know the actual business process and things involved in it like message exchanges, time of call, etc. Find below a diagram depicting a typical Choreography process.

Orchestration vs Choregraphy

Easy to fugure out, right? Orchestration has a central controller process and all other participating Web Services don't know about the actual business process. They are called only by the controller process and they don't know anything about other Web Services involved in the application. Whereas Choreography doesn't have any controller process/service and all the participating Web Services know the actual business process and they are well aware of which all Web Services they need to interact with, when to execute the operations, etc.

So, we can say that Orchestration is a controlled and co-ordinated way of utilizing the services of all the participating Web Services whereas Choreography is just a collaborative effort of utilizing the services of the participating Web Services.

Falut handling is easier in Orchestration as the execution is controlled which is not the case with Choreography. Web Services can be easily and transparently replaced in case of Orchestration as the involved Web Services don't know the actual business process whereas it'll be difficult in case of Choreography.

Thus, we see that Orchestration is having quite a few advantages over Choreography and hence Orchestrtaion is normally preferred for business process implementations, but Choreography may certainly have its own usage in some selected scenarios.

Xml tutorial : XML Schema and its anatomy, Applications of XML Schemas, Namespaces

XML Schema was approved as an official recommendation by the WOrld Wide Web Consortium (W3C) in 2001. W3C defines XML Schema as "XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content, and semantics of XML documents."

As it's clear from the definition that XML Schema is a mechanism of defining basically the structure, content and semantics of XML Documents which conform to the Schema under consideration. But, DTD (Document Type Definition) also serves a similar purpose. So, why a need for something different was felt?

Well... the short answer is that XML Schema just evolved from DTDs in the wake of getting a more powerful and flexible mechanism as compared to what DTD supported. XML Schemas are XML documents themselves and hence all the benefits of XML - parsing, programmatically accessing, validating, and extending automatically apply to XML Schemas as well. These all benefits make Schemas a far better alternative to DTDs.

Do we still need DTDs?

Yeah, we need them, but probably only for the legacy applications where they have been in use since long. Almost all the newer applications now use Schemas only for the simple reason that XML Schemas are much more powerful & flexible and therefore offer many advantages over DTDs. However, DTDs are still supported and they can be used in tandem with XML Schemas as well.

Anatomy of XML Schemas

An XML Schema is made up of the following declarations and definitions. Few of these might be optional as well.

Document Type Declaration: Since an XML Schema is also an XML Document which obviously conforms to the W3C XML recommendations and hence they may contain the particular document type declaration, but this is not a mandatory requirement. If present, it's inferred by the root element named <Schema>
Namespace Declaration: Again an optional declaration which is used to provide a context for element names and attribute names used within an XML Document (which conforms to this Schema). This helps in avoiding ambiguity in name resolution and thereby helps building and extending XML Documents using URIs ensuring unique names for elements and attributes. Namespaces can either be defined inline (called inline xml namespace which are defined inline with element and atribute in the XML) or as Expanded names where the namespace name is combined with the local name to uniquely identify the particular name. Both the namespace and the local name are separated with a colon (e.g., NamespaceName:LocalName).
Type Definitions: These definitions are used to define Simple or Complex data types or structures, which are later re-used by all the client content models.
Element/Attribute Declarations: This section of an XML Schema defines the elements and their respective attributes which are used for tags in the XML instances using the Schema. Various constraints like id, type, max/minOccurs, substitutionGroup, etc. can also be defined in this section of an XML Schema.
Sequence Definition: As the name might suggest this section is used to enforce the order in which the child elements of the XML instances (using the XML Schema in consideration) are required to appear.

XML Schema applications/uses

Data Validation: XML Schema is used to define the structure of the elements and the attributes within the elements and this definition helps the XML parsers to validate the XML Document Syntax, Datatypes used by the XML Document/Instance, and/or the Inclusion of mandatory elements or attributes. This obviously helps the application designers to delegate some of the basic data validation (and data sufficiency) tasks to the XML Schema rather than doing all of them programmatically.
Content Model Definition: XML Schema supports both simple and complex data types definitions which ultimately provides flexibility of using concepts like inheritance to the data syntax. This consequently helps building the XML Schema defining extensible models highly suitable for large and complex applications.
Data Exchange/Integration: Since XML Schemas are themselves XML documents and hence they can be parsed and accessed similar to other XML instances by variety of XML companion tools for various purposes. For example: an XSD when used in conjunction with an appropriate XSLT and an XML-enabled database can support the changes made to the global elements defined by the XSD to be processed consistently. In addition, the output can simultaneously be produced in various formats like PDF, Doc, RTF, HTML, etc. using the single source publishing methodology. The data-oriented datatypes provided in XML Schema 1.1, in addition to the document-oriented datatypes as supported in the previous versions, facilitate complex document exchange and data integration scenarios. Namespaces supported by XML Schema can be used to have more than one vocabulary at a time in an XML instance as the namespaces enable the XML documents to contain unique identifiers. Namespaces facilitate ample opportunities for data exchange and integration by enabling the entire XML frameworks to co-exist within the same architecture. This feature is extremely helpful in mergers and acquisitions, and supply chain requirements, where we generally have a plethora of heterogeneous data constructs.
Industry XML Standards: These standards aim to streamline and provide a basis for industry-wide data integration by implementing common XML vocabularies which enable the business partners to seamlessly exchange data across different systems and architectures. Several new industry standards are strongly being followed and they are paving way for a seamless data integration and inter-operability. Some of these standards are DITA, DocBook, SCORM, ACORD, CXML, FIXML, and XBRL.

An interesting try-catch-finally scenario | Java exception

If not very comfortable with finally block and its execution then you may probably like to go through this article It covers some pretty interesting scenarios covering various possible scenarios of try, catch, and finally blocks followed by the precise explanation of their execution in each of these scenarios. Come back to this article once you finish that as this article is more like a logical extension of that article. If already comfortable with try-catch-finally then you may proceed straightaway with this one.

One of our visitors has asked another interesting scenario involving nested try blocks in response to the above mentioned article. I have created two possible cases taking reference of that scenario and have tried to explain the execution of each of these cases below:

Case #1: nested 'try' with a 'finally' block associated with the inner 'try' and a 'catch' with the outer


public class TestFinally {

   public static void main(String[] args) {
        
         try{
               try{
                     throw new NullPointerException ("e1");
               }
               finally{
                     System.out.println("e2");
               }
         }
         catch(Exception e){
                     e.printStackTrace();
         }
   }
}

Output: what do you expect as the output here? As we all know that 'finally' will always get executed irrespective of 'try' finishes its execution with or without exception. In our case the inner 'try' throws an exception which has no matching 'catch' associated with the corresponding (inner) 'try' block. As per the Exception Mechanism in Java, the uncaught exception will be propagated until it's either executed by some matching 'catch' block on its way back or it'll be handled by the default JVM handler which simply terminates the program after printing a stack trace.

But, before the control leaves the inner 'try' block, the entire inner block should complete its execution and hence the associated 'finally' block will get executed before the control leaves the inner block for the simple reason that 'finally' in any case has to be executed and the control won't go back to the inner block once it comes out of it.

The 'catch' block associated with the outer 'try' block expects an exception of type 'Exception' and hence a 'NullPointerException' (a subclass of the the Exception class) thrown from the inner 'try' block (which has been propagated) can be handled by this 'catch' handler and hence this 'catch' block will be executed. Do I still need to tell you the output of this code-snippet. Here is it for your reference:


e2

java.lang.NullPointerException: e1

     at TestFinally.main(TestFinally.java:8)

Case #2: nested 'try' with 'catch' block associated with the inner 'try' and 'finally' with the outer


public class TestFinally2 {

   public static void main(String[] args) {

         try{
               try{
                     throw new NullPointerException ("e1");
               }
               catch(Exception e){
                     e.printStackTrace();
               }
         }
         finally{
                     System.out.println("e2");
         }
   }
}

Output: This is pretty straightforward I think. Since an exception is being thrown from the inner 'try' block and we have an associated matching 'catch' handler for this exception so obviously it will be handled there. Now the control leaves the inner block and hence the outer 'finally' gets executed as 'finally' block in any case has to be executed. All right? Please find below the output for your reference:


java.lang.NullPointerException: e1

     at TestFinally2.main(TestFinally2.java:8)

e2

Java error: java.lang.UnsupportedClassVersionError: when is it thrown by a JVM & how to resolve it?

UnsupportedClassVersionError is (evidently a descendant of the Error class in Java) which subclasses java.lang.ClassFormatError which in turn subclasses java.lang.LinkageError (which is a direct subclass of java.lang.Error). This error is thrown in the cases when the JVM (Java Virtual Machine) attempts to read a class file and finds that the major and minor version numbers in the particular class file are not supported. This happens in the cases when a higher version of Java Compiler is used to generate the class file than the JVM version which is used to execute that class file. Please do notice that this is not true vice-versa which means you can comfortably use a higher version of JVM to run a class file compiled using an earlier version of Java Compiler. Let’s understand why? We'll see below a valid Java program and subsequently an alert and a stack trace of the error which are thrown as a result of the above explained situation which causes UnsupportedClassVersionError. FYI:


public class TestFinally {

      public static void main(String[] args) {
              
            try{
                  try{
                        throw new NullPointerException ("e1");
                  }
                  finally{
                        System.out.println("e2");
                  }
            }
            catch(Exception e){
                        e.printStackTrace();
            }
      }
}

The error alert and the stack trace if the right JVM is not used


java.lang.UnsupportedClassVersionError: TestFinally (Unsupported major.minor version 49.0)
      at java.lang.ClassLoader.defineClass0(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
      at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
      at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

The minor and major version numbers are represented by the major_version and minor_version items respectively in a Java Class File structure. A combination of these two unsigned integers (both of length 2 bytes each) determines the particular version of the class file format. If a class file has major version number M and minor version number m, we denote the version of its class file format as M.m.

As per Java VM Spec, “A Java virtual machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 v Mj.m. Only Sun can specify what range of versions a Java virtual machine implementation conforming to a certain release level of the Java platform may support.” For example: Implementations of version 1.2 of the Java 2 platform can support class file formats of versions in the range 45.0 through 46.0 inclusive.

Major version number of the class file formats of the popular Java versions are: J2SE 6.0 = 50, J2SE 5.0 = 49, JDK 1.4 = 48, JDK 1.3 = 47, JDK 1.2 = 46, JDK 1.1 = 45. Now you understand what in our example “major.minor version 49.0” signifies? It simply means we have used J2SE 5.0 for compiling the source code as the class file format is 49.0 where major_version is ‘49’ and minor_version is ‘0’.

Errors are never detected at compile time. This is quite easier to understand in this case – how can the compiler have the information at the time of compilation about which version of JVM would be used execute the compiled class file? It can't, right? So is the case with other errors as well. This is the reason why all the Errors are unchecked. The error alert also rightly shows that it's a JVM Launcher error.

How to resolve UnsupportedClassVersionError?

Whenever you encounter this error, do check if you’re using an earlier version of JVM to execute the class file than the corresponding version of compiler you used to compile the source code. The example shown here was compiled using Java 5.0 compiler, but when I tried to run using JVM 1.4, I got the above error. I just needed to switch either to a JVM version 5.0 or above OR needed to switch to a Java Compiler of JDK 1.4 or below (you of course need to make sure the source code is compatible with the corresponding version of the compiler otherwise you’ll start getting other compiler errors).

A higher JVM version doesn’t cause a problem in most of cases unless the class file format is quite old (and hence doesn’t lie in the supported range as specified by Sun for that particular JVM version ... as discussed above). But, it’s always a good practice to have both the Compiler and the JVM of the same version.

Usage of ThreadLocal: per-thread Singleton and per-thread Logging | Java Thread

Should you require a refresh of what ThreadLocals in Java are and how they work, refer to first. You can then proceed with the current article for understanding two of the most common uses of ThreadLocals in Java.

per-thread Singleton impl using ThreadLocal

Suppose you have a need of having a JDBC Connection objects per thread of your application. The moment you hear the term 'per-thread', ThreadLocal automatically comes into mind as that's what it's primarily meant for. Below is a sample implementation of how easily can you actually use ThreadLocal for a per-thread JDBC Connection object in Java.


public class ConnectionDispenser {

 private static class ThreadLocalConnection extends ThreadLocal {

   public Object initialValue() {

     return DriverManager.getConnection(ConfigurationSingleton.getDbUrl());

   }

 }

 private static ThreadLocalConnection conn = new ThreadLocalConnection();

 public static Connection getConnection() {

   return (Connection) conn.get();

 }

}

Most of the code is self-explanatory and you can easily see how overriding the 'initialValue()' method of ThreadLocal is doing the trick of getting a Connection object by calling 'getConnection' method of the 'DriverManager' class. As you know the 'initialValue()' method is called only once for a ThreadLocal object and hence the Connection object will be obtained only once per thread (as a ThreadLocal object is created per thread only). From then on, whenever the particular thread requires the Connection object it simply calls the static 'getConnection' method of the your 'ConnectionDispenser' class, which in turn calls the 'get()' method of ThreadLocal to fetch the Connection object associated with that particular thread.

per-thread Debug Logging impl using ThreadLocal

Ever thought of having a per-thread DEBUG logging for any of your applications? Few multi-threading applications do get trickier at times and having per-thread DEBUG logs might be of great help in such situations as you probably can't visualize the actual order in which the threads might have executed and changed the shared objects. Here goes a sample implementation of per-thread DEBUG logging in Java using ThreadLocal.


public class DebugLogger {

 private static class ThreadLocalList extends ThreadLocal {

   public Object initialValue() {

     return new ArrayList();

   }

   public List getList() {

     return (List) super.get();

   }

 }


 private ThreadLocalList list = new ThreadLocalList();

 private static String[] stringArray = new String[0];


 public void clear() {

   list.getList().clear();

 }


 public void put(String text) {

   list.getList().add(text);

 }


 public String[] get() {

   return list.getList().toArray(stringArray);

 }

}

As you can identify we are using an ArrayList object to store the logging info for a thread. 'initialValue' has been overridden to initialize every thread with a new ArrayList object. Whenever your multi-threaded application calls the 'put' method of your 'DebugLogger' class then all that method does is that it adds the logging info (passed as an String parameter to the 'put' call) to the corresponding ArrayList object of the current thread. Similarly a 'get' call of your 'DebugLogger' class simply returns the associated ArrayList object of the current thread in form of an String array. Evidently the 'clear' method of your 'DebugLogger' class is for clearing the logging info captured so far for the current thread - it'll simply clear the ArrayList object holding logging info for the current thread. This might help you getting rid of the non-essential logging info, maybe based on some condition, when you know for sure that all that you need for your debugging is what you are going to capture next and now what has already been captured so far.

Source: a nice article on ThreadLocals in Java, which I thoroughly enjoyed.