Changing Default GlassFish v3 Prelude Port Numbers 4848, 8080, and 8181 (The Open Road)

1. To change the HTTP port to 10080:
   
   asadmin set server.http-service.http-listener.http-listener-1.port=10080
   
   
2. To change the HTTPS port to 10443:
   
   asadmin set server.http-service.http-listener.http-listener-2.port=10443
   
   
3. To change the administration server port to 14848:
   
   asadmin set server.http-service.http-listener.admin-listener.port=14848
   

How To Fix LinkageError when using JAXB with JDK 1.6

If you run across an error like this when trying to use JAXB:

java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI
(from jar:file:/somedirectory/jaxb-impl.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.5.0/docs/guide/standards/)

This is apparently only a problem with JDK 1.6, not with JDK 1.5. It can be fixed by setting the JRE to 1.6.21 or 1.6.24 patches and not the 1.6 version

It can als be fixed by putting the jaxb-api.jar that you're trying to use into JDK_HOME/jre/lib/endorsed. If the endorsed directory doesn't exist, make it.

Error while configuring Jersey in JBOSS 5.1.0.GA

15:46:27,736 WARNING [AnnotatedClassScanner] URL, vfszip:/F:/Covisint HIE/jboss-5.1.0.GA/server/default/deploy/RestFulPrj.war/WEB-INF/classes/com/rest/cannot be converted to a URI

15:46:27,879 INFO [WebApplicationImpl] Initiating Jersey application, version 'Jersey: 1.1.1-ea-SNAPSHOT 07/13/2009 06:16 AM'

15:46:28,189 SEVERE [WebApplicationImpl] The ResourceConfig instance does not contain any root resource classes.

15:46:28,190 ERROR [[/RestFulPrj]] StandardWrapper.Throwable

com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.

Are you deploying resources classes in a jar in WEB-INF/lib ?

The issue was fixed for the scheme of "vfsfile" but not for a scheme
of "vfszip".

Looking at the URL: vfszip:/F:/Covisint HIE/jboss-5.1.0.GA/server/default/deploy/RestFulPrj.war/WEB-INF/classes/com/rest/cannot be converted to a URI is a JBOSS propriety code to access the jar

This has been solved by adding all the jersey 1.3 snapshot jars instead of jersey 1.1.1 jars which i had previously from the loc http://download.java.net/maven/2/com/sun/jersey/

Difference between Strategy and Command Pattern

Typically the Command pattern is used to make an object out of what needs to be done -- to take an operation and its arguments and wrap them up in an object to be logged, held for undo, sent to a remote site, etc. There will tend to be a large number of distinct Command objects that pass through a given point in a system over time, and the Command objects will hold varying parameters describing the operation requested.

The Strategy pattern, on the other hand, is used to specify how something should be done, and plugs into a larger object or method to provide a specific algorithm. A Strategy for sorting might be a merge sort, might be an insertion sort, or perhaps something more complex like only using merge sort if the list is larger than some minimum size. Strategy objects are rarely subjected to the sort of mass shuffling about that Command objects are, instead often being used for configuration or tuning purposes.

Both patterns involve factoring the code and possibly parameters for individual operations out of the original class that contained them into another object to provide for independent variability. The differences are in the use cases encountered in practice and the intent behind each pattern.

Volatile Keyword

What does volatile do?

This is probably best explained by comparing the effects that volatile and synchronized have on a method. volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords:

         int i1;  
            int geti1() {return i1;} volatile int i2; 
             int geti2() {return i2;}          int i3; synchronized int geti3() {return i3;} 

geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main" memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to "main" memory or other threads.

On the other hand, geti2() effectively accesses the value of i2 from "main" memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in "main" memory. Effectively, a variable declared volatile must have it's data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Of course, it is likely that volatile variables have a higher access and update overhead than "plain" variables, since the reason threads can have their own copy of data is for better efficiency.

Well if volatile already synchronizes data across threads, what is synchronized for? Well there are two differences. Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block, if both threads use the same monitor (effectively the same object lock). That's the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with "main" memory. So executing geti3() does the following:

1. The thread acquires the lock on the monitor for object this (assuming the monitor is unlocked, otherwise the thread waits until the monitor is unlocked).
2. The thread memory flushes all its variables, i.e. it has all of its variables effectively read from "main" memory (JVMs can use dirty sets to optimize this so that only "dirty" variables are flushed, but conceptually this is the same. See section 17.9 of the Java language specification).
3. The code block is executed (in this case setting the return value to the current value of i3, which may have just been reset from "main" memory).
4. (Any changes to variables would normally now be written out to "main" memory, but for geti3() we have no changes.)
5. The thread releases the lock on the monitor for object this.

So where volatile only synchronizes the value of one variable between thread memory and "main" memory, synchronized synchronizes the value of all variables between thread memory and "main" memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.

try with resource block

Often we use the try block while using resources like Streams and Connections. In these cases it is mandatory to close the resources after the completion of the task. We usually do the same in the finally block as in the example below

BufferedReader br = new BufferedReader(new FileReader(path));

try {

return br.readLine();

} finally {

br.close();

}

In Java 7 this process has been shortened by the try-with-resource statement. In this the resources are implicitly closed on the completion of the try fragment irrespective of whether the code was successfully executed or with exception. The only change is that the resource must implement the java.lang.AutoCloseable interface. The classes java.io.InputStream, OutputStream, Reader, Writer, java.sql.Connection, Statement, and ResultSet have been retrofitted to implement the AutoCloseable interface and can all be used as resources in a try-with-resources statement.

The Catch Blocks

Java 7.0 has come up with a new feature where it is possible to catch multiple exceptions in a particular catch block. For example

catch (IOException | SQLException ex) {

logger.log(ex);

throw ex;

}

In this case both IOException and SQLException will be caught in the same block.It has to be noted though that the parameter is implicitly final i.e the parameter cannot be assigned to any other Object.