The applications will be named the same as their WAR files and can be accessed using URLs that start with that name. For example, to access index.jsp in the root directory of a WAR file called myapp.war running on Tomcat on the localhost you will need the following URL:

http://localhost:8080/myapp/index.jsp

When there are multiple applications running in the same Tomcat server, they must all have different names.

Any absolute URLs that you need to include in your application must include the applictions name at the start. For example, if in index.jsp we want to reference an image in ‘/images/banner.png’ the absolute URL will be: ‘/myapp/images/banner.png’.

It is bad practice to hard code the application’s name in the URL as this may change for different deployments of the application. Instead, it may be added dynamically using the following scriptlet:

${pageContext.request.contextPath}

So, to add an img tag that refers to the banner image use:

<img src="${pageContext.request.contextPath}/images/banner.png"/>

Alternatively, there are a number of custom tag libraries that will automatically do this for you. Spring MVC ships with such a tag:

<spring:url value='/images/banner.png'>

this will achieve the same results as the scriptlet shown above but is simpler to remember when adding a number of links in your JSPs.

select dbname=db_name(dbid),login=suser_name(suid), #connections=count(suid)
from master..sysprocesses
--where  suser_name(suid) like '%dblogin%'
group by dbid, suid
order by count(suid)

dd/mm/yyyy at hh:mm:ss

System.out.printf("Date: %1$te/%1$tm/%1$tY at %1$tH:%1$tM:%1$tS%n", new Date());

The % characters mark a placeholders for String content, the 1$ indicates that the first vararg should be used for each placeholder (there is only one varag value supplied), the letter ‘t’ in each placeholder indicates a time conversion and the e, m, Y, H, M, S characters indicate what value should be taken from the new Date object for that time conversion.

I’ll demonstrate the technique with an Ant target that I wrote to check whether Ivy had downloaded any jars that had the pattern SNAPSHOT in their name:

<target name="ivy-count-snapshot-jars" depends="init" if="ivy.present">
    <resourcecount property="ivy.snapshot.count">
        <fileset dir="${ivylib.dir}" includes="**/*SNAPSHOT*.jar"/>
    </resourcecount>
    <condition property="ivy.snapshot.present">
        <not>
            <equals arg1="${ivy.snapshot.count}" arg2="0"/>
        </not>
    </condition>
</target>

<target name="ivy-check-snapshot-jars"
        depends="ivy-count-snapshot-jars"
        if="ivy.snapshot.present">
     <echo>WARNING: Project uses ${ivy.snapshot.count} SNAPSHOT jar(s).</echo>
</target>

The first target does most of the work and is used to count the number of jar files with ‘SNAPSHOT’ in their name; it also sets a property if the count is not zero.

The second target is the main one that should be used to perform the check. It depends on the first target (ensuring that the count is done first) and will only then run if the first target sets the ‘ivy.snapshot.present’ property. Thus the warning message will only get echoed if there are snapshot jars in the project.

This can happen in numerous circumstances where you’d like an application to maintain a degree of liveness. I’ve used it recently in an application that needed to run a number of external scripts; if the script does not complete, for whatever reason, the timeout ensures the the calling thread does not get blocked and the remaining scripts can be launched.

Here’s the basic idea:

public class TimeoutDemo {

    //maintains a thread for executing the doWork method
    private ExecutorService executor = Executors.newFixedThreadPool(1);

    public void doWork() {
        //perform some long running task here...
    }

    public void doWorkWithTimeout(int timeoutSecs) {

        //set the executor thread working
        final Future<?> future = executor.submit(new Runnable() {
            public void run() {
                try {
                    doWork();
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            }
        });

        //check the outcome of the executor thread and limit the time allowed for it to complete
        try {
            future.get(timeoutSecs, TimeUnit.SECONDS);
        } catch (Exception e) {
            //ExecutionException: deliverer threw exception
            //TimeoutException: didn't complete within downloadTimeoutSecs
            //InterruptedException: the executor thread was interrupted

            //interrupts the worker thread if necessary
            future.cancel(true);

            log.warn("encountered problem while doing some work", e);
        }
    }
}

The doWork method is the one that will actually do some potentially long running work. The doWorkWithTimeout illustrates how the java.util.concurrent classes can be used to prevent the method from taking too long to complete. When calling the latter method, just specify the timeout period in minutes.

The trick here is that the actual work will be done by a dedicated worker thread. The calling thread will handle the timeout management and also handle any exceptions thrown by the worker.

Variations of this pattern can be used for methods that accept parameters (just make them final) and for ones that return values too (just return the value from the future.get(…) call).

The ‘/test’ in the URL will map to a servlet called test. The servlet will dispatch the request to a JSP for rendering that has the following scriplet code in it:

RequestURL: <%= request.getRequestURL() %> <br>
RequestURI: <%= request.getRequestURI() %> <br>
QueryString: <%= request.getQueryString() %> <br>
ServletPath: <%= request.getServletPath() %> <br>
PathInfo: <%= request.getPathInfo() %> <br>
PathTranslated: <%= request.getPathTranslated() %><br>
AuthType: <%= request.getAuthType() %> <br>
LocalAddress: <%= request.getLocalAddr() %> <br>
Method: <%= request.getMethod() %> <br>
RemoteUser: <%= request.getRemoteUser() %> <br>

this is the output generated:

RequestURL: https://localhost:8443/test/welcome
RequestURI: /test/welcome
QueryString: a=1&b=2
ServletPath: /test
PathInfo: /welcome
PathTranslated: C:\projects\testproj\out\artifacts\testapp_war_exploded\welcome
AuthType: CLIENT_CERT
LocalAddress: 127.0.0.1
Method: GET
RemoteUser: Steve

What is Flash Scope

Flash scope is a useful part of many web frameworks. It allows the use of the post/redirect/get design pattern to alleviate many of the problems associated with handling multiple submits or resubmission of data in browser requests to the server.

Flash scope is an additional scope to those provided in a standard Java Web application (page, request, session and application). Any attributes held in flash scope will be available for the duration of the current request, and the subsequent request too.

My Implementation

To implement flash scope in my application, I added a servlet filter that checks for request attribute names starting with ‘flash.‘. When it finds such an attribute, it ensures that it is made available in the subsequent request by temporarily storing it in the user’s session, and then reinstating it when the next request is received.

For example, to add a message to flash scope, just use the regular syntax for adding a request scoped attribute and let the fiter take care of it:

request.setAttribute("flash.message", "Here is the news...");

The above attribute can then be accessed in the redirect target JSP using EL or scriptlet syntax (omitting the ‘flash.‘ prefix):

${message}
or
<%= request.getAttribute("message")  %>

Here’s the code for the filter:

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;

/**
 * Ensures that any request parameters whose names start
 * with 'flash.' are available for the next request too.
 */
public class FlashScopeFilter implements Filter {

    private static final String FLASH_SESSION_KEY = "FLASH_SESSION_KEY";

    @SuppressWarnings("unchecked")
    public void doFilter(ServletRequest request, ServletResponse response,
					FilterChain chain) throws IOException, ServletException {

        //reinstate any flash scoped params from the users session
		//and clear the session
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpSession session = httpRequest.getSession(false);
            if (session != null) {
                Map<String, Object> flashParams = (Map<String, Object>)
									session.getAttribute(FLASH_SESSION_KEY);
                if (flashParams != null) {
                    for (Map.Entry<String, Object> flashEntry : flashParams.entrySet()) {
                        request.setAttribute(flashEntry.getKey(), flashEntry.getValue());
                    }
                    session.removeAttribute(FLASH_SESSION_KEY);
                }
            }
        }

        //process the chain
        chain.doFilter(request, response);

        //store any flash scoped params in the user's session for the
		//next request
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            Map<String, Object> flashParams = new HashMap();
			Enumeration e = httpRequest.getAttributeNames();
            while (e.hasMoreElements()) {
                String paramName = (String) e.nextElement();
                if (paramName.startsWith("flash.")) {
                    Object value = request.getAttribute(paramName);
                    paramName = paramName.substring(6, paramName.length());
                    flashParams.put(paramName, value);
                }
            }
            if (flashParams.size() > 0) {
                HttpSession session = httpRequest.getSession(false);
                session.setAttribute(FLASH_SESSION_KEY, flashParams);
            }
        }
    }

    public void init(FilterConfig filterConfig) throws ServletException {
        //no-op
    }

    public void destroy() {
        //no-op
    }
}

You can see from the listing, that the filter stores the flash scoped parameters in a session scoped map called FLASH_SESSION_KEY. Before the request is processed by the filter chain, the flash attributes are retrieved from the session and added to request scope; after the chain has finished, any new flash scoped parameters are stored in a new session scoped map.

Note that the attributes have the ‘flash.‘ prefix removed when added to the session scoped map – this not only ensures that they can be accessed using their ’short name’, but that they are only kept in the session for one extra request.

This approach is not Spring specific and should work with and Java Web framework. I’ve omitted the configuration for the filter as there are loads of examples of how to do this on the Internet already.

select name,type from sysobjects where (name like '%Sales%') and type = 'U'

The sysobjects table stores data about various items in the database including tables (note that the type column is set to ‘U’ for user tables).

To search for columns, you can use a similar query:

select name,object_name(id) from syscolumns where name like '%currency%'

This time, we’re querying a similar table specifically for columns. The ID column in this table is a foreigh key that refers to the primary key in the sysobjects table; thus allowing us to discover which table the column belongs to (done in this example using the object_name function).

This query will therefore return a list of all columns with the text ‘currency’ in their name, and the tables to which they belong.

<jsp:include page="renderTree.jsp">
    <jsp:param name="nodes" value="${node.children}"/>
</jsp:include>

After a while of not getting very far with this and trying to figure out why I was getting stack overflow errors, I figured out that the jsp:param tag was not passing the state across as I’d expected in the recursive call.

The solution was to explicily place the parameter on the request before making the call, like so:

<c:set var="nodes" value="${node.children}" scope="request"/>
<jsp:include page="renderTree.jsp"/>

This resulted in the correct recursive behaviour that I was expecting.

java.net.BindException: Address already in use: JVM_Bind <null>:8080

This can be caused if you already have Tomcat running as it will hold onto a network port for handling HTTP requests. In the above example the port shown is 8080.

However, this error is sometimes apparent even when Tomcat has already been shut down, expecially if you’ve shut it down abruptly. The problem here is that the Tomcat process may not have completely ended and that Windows is holding onto the network port for it.

To resolve this do the following:

1. find the process ID that has the port reserved,
2. kill the process, releasing the port.

Step 1 – Find the process thats holding onto the port

Start a command prompt and enter the command:

netstat -ano

The flags for this cause (a)  all connections and ports to be listed, (n) port numbers to be shown numerically, and importantly (o) which causes the process ID to be included in the output. The results of running this should look something like this:

Active Connections

Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       496
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:1776           0.0.0.0:0              LISTENING       1128
TCP    0.0.0.0:2864           0.0.0.0:0              LISTENING       2524
TCP    0.0.0.0:3306           0.0.0.0:0              LISTENING       1708
TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       424
TCP    0.0.0.0:6942           0.0.0.0:0              LISTENING       2524
TCP    0.0.0.0:8008           0.0.0.0:0              LISTENING       1292
TCP    0.0.0.0:8009           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:8012           0.0.0.0:0              LISTENING       1456
TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:8443           0.0.0.0:0              LISTENING       2904
TCP    0.0.0.0:15000          0.0.0.0:0              LISTENING       1864
TCP    0.0.0.0:33115          0.0.0.0:0              LISTENING       704
TCP    0.0.0.0:63342          0.0.0.0:0              LISTENING       2524
TCP    10.136.38.94:139       0.0.0.0:0              LISTENING       4

In the output, port 8080 (under Local Address, on line 14) can be seen to belong to process ID (PID) 2904.

Step 2 – Kill the process

Press <CTRL><ALT><DEL> and then select Task Manager, then from the Task Manager choose the menus: View | Select Columns. In the dialog that appears check the PID checkbox to display the process ID and then dismiss it by pressing OK.

With the Processes tab selected you should be able to idenify the process with the PID that we found in step 1. In this example the value would be 2904.

Select this process and click End Process. Confirm that you want to kill the process and you should find that once it has been killed off, the network port it was holding has been released.