After hours of searching and debugging I finally managed to get it up and running. Now I’m going to list the steps involved. The most interesting and insightful resource I found is this post, which describes how to setup JSF on App Engine as a step in configuring JBoss Seam.
As the post author states, you’ll have to enable sessions in appengine-web.xml, then configure JSF as usually, then set it up to use JBoss’s EL implementation and finally use those patched classes in order to avoid API calls that are restricted by the security policy of App Engine. I only used the patched classes under ‘jboss-el’ and ‘jsf_mojarra’ since I don’t use Seam.

After this I added Facelets and gone through the necessary configuration steps, built the application and tried to run it on App Engine.

Problems Occurred (yes, of course, Murphy’s Law dictates it):

1) FacesServlet was not properly initialized. This is probably because App Engine does not initialize servlets at startup, instead initialization is postponed until the first request. As a result an IllegalStateException was thrown. To resolve the issue I had to add the following to web.xml:
<listener>
    <listener-class>
        com.sun.faces.config.ConfigureListener
    </listener-class>
</listener>
Error Message:
javax.servlet.ServletException: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

2) An error was thrown during FacesServlet initialization due to the use of a restricted class. After examining the stack trace I realized that JSF was trying to perform some XML validation and failed throwing a NoClassDefFoundError. I had no other option but to deactivate XML validation by setting the following at web.xml:
<context-param>
    <param-name>com.sun.faces.validateXml</param-name>
    <param-value>false</param-value>
</context-param>
Error Message:
java.lang.NoClassDefFoundError: com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary is a restricted class. Please see the Google App Engine developer’s guide for more details.

3) EL API classes were missing, had to include the EL API class library to the project.

Error Message:
java.lang.ClassNotFoundException: javax.el.CompositeELResolver
 

One last upload of the application after all the above tweaks and voilà! The homepage loaded without any errors! The fact is that I didn’t have time to perform any further tests and for sure I cannot tell if all the features of JSF and Facelets will work normally. I’m waiting for your feedback on this. Good Luck!

Of course, this adds platform dependency to your code, and if you want your application to be portable it’s a good practice to avoid using the exec() method. But if it is necessary to initiate a native application for any reason, the way is easy and pretty straight-forward. The fact is that there’s always a case where executing a command of the operating system is the only way to achieve specific functionality.

In this case, independence can be approached if the command to be executed exist(with common or different syntax) in various operating systems. The first step is to find out the syntax of the command for every OS. Then within the code, you can use System.getProperty(”os.name”) to determine the OS that is being to host your Java application and finally use this information to execute the command using the corresponding syntax.

There is one more useful feature of the exec() method: it’s return value is an instance of the Process class, which can be used to get access to the actual process of the application initiated. Check out the javadoc of the Process class to find out more.

In this post I will provide a quick guide to help you get up and started with log4j. But fist of all you’ll have to download the latest version. Once you do, follow the instructions below:

1. Add log4j’s jar(log4j-x.x.xx.jar where x.x.xx is the version of the release you’ve downloaded) file to your application’s classpath.

2. Create a file named “log4j.properties” and place it in the default package of your source code(the root folder where all your code resides). Copy the following lines in it:
# Log levels
# Uncomment the following line to enable full loggin for every class
#log4j.rootLogger=trace, stdout, R
log4j.logger.gr.xfrag=trace, stdout, R

# Console appender configuration
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
# Pattern to output the caller's file name and line number.
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

# Rolling File Appender
log4j.appender.R=org.apache.log4j.RollingFileAppender
# Path and file name to store the log file.
log4j.appender.R.File=./logs/applog.log
log4j.appender.R.MaxFileSize=500KB
# Keep one backup file
log4j.appender.R.MaxBackupIndex=1
# Rolling File Appender layout
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d - %c - %p - %m%n
Here is a quick explanation of what the above properties do:
“log4j.logger.xxx” controls the loggers, where xxx is the package for witch you want to set log levels.
The line
log4j.logger.foo.bar=trace, stdout, R
means that you want every class under the foo.bar package to have a logging level of trace, and output the log to the standard output(the console) using a Console Appender named stdout and to a file using a Rolling File Appender named R.

After that you define the appenders I mentioned earlier and set their properties.
The lines
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) – %m%n
define the ConsoleAppender named stdout, set it’s layout to PatternLayout and then assign a pattern for the output.

Following the same procedure the RollingFileAppender is defined, setting some additional properties: the file name of the log, the size of the log and the number of backup files to keep.

3. The third and final step is about the code you’ll have to use. There’s not much to be said, this is the easiest part. Take a look of the class below:
import org.apache.log4j.Level;
import org.apache.log4j.Logger;

public class Main {
    private static Logger logger = Logger.getLogger(Main.class);
    
    public static void main(String[] args) {
        
        long time = System.currentTimeMillis();
        logger.info("main method called..");
        logger.info("another informative message");
        logger.warn("This one is a warning!");
        logger.log(Level.TRACE,
                "And a trace message using log() method.");
        long logTime = System.currentTimeMillis() - time;
        
        logger.debug("Time taken to log the previous messages: "
                + logTime + " msecs");

        // Exception logging example:
        try{
            String subs = "hello".substring(6);
        }catch (Exception e){
            logger.error("Error in main() method:", e);
        }      
              
    }
}
First you have to import org.apache.log4j.Logger and org.apache.log4j.Level(if you want to use the log() method).

Then instantiate a static Logger object using the static method getLogger() and provide your class as an argument.

To log messages through your class, you use the logging methods of the created Logger object. There are two ways to log messages:
Directly, using the methods trace(), debug(), info(), warn(), error() and fatal(), providing the message as an argument.
Using the log() method, providing the level of the message from the Level class and the message to log as arguments.

According to the configuration you provide in the properties file, a message will be logged – or not. For example, if you set the level to WARN, all messages of level WARN, ERROR and FATAL will be logged and everything else will be omitted. In other words, the hierarchy is:
TRACE < DEBUG < INFO < WARN < ERROR < FATAL.

Now, check out how the appenders output the messages according to their pattern. Here’s what you get at the console when you run the Main class:
INFO [main] (Main.java:12) - main method called..
INFO [main] (Main.java:13) - another informative message
WARN [main] (Main.java:14) - This one is a warning!
TRACE [main] (Main.java:15) - And a trace message using log() method.
DEBUG [main] (Main.java:19) - Time taken to log the previous messages: 0 msecs
ERROR [main] (Main.java:26) - Error in main() method:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(String.java:1938)
        at java.lang.String.substring(String.java:1905)
        at gr.xfrag.loggingexample.Main.main(Main.java:24)

And the same in the log file:
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - INFO - main method called..
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - INFO - another informative message
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - WARN - This one is a warning!
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - TRACE - And a trace message using log() method.
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - DEBUG - Time taken to log the previous messages: 0 msecs
2008-01-10 15:39:46,724 - gr.xfrag.loggingexample.Main - ERROR - Error in main() method:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
  at java.lang.String.substring(String.java:1938)
  at java.lang.String.substring(String.java:1905)
  at gr.xfrag.loggingexample.Main.main(Main.java:24)
Besides the deferences of the formating, notice how long it takes to log those messages – zero milliseconds on my machine. If you ask me, I’ll say that speed is the most impressive feature of log4j..

I hope the above information will help you get started with log4j and logging in general. You can learn more by reading the manual located at log4j’s home page: Log4j Manual

I also uploaded the example code as a NetBeans 6.0 project. Use the following link to download the zip archive:
Log4j Example NetBeans Project

When you declare a Servlet in your web application’s configuration file (that’s web.xml), you also have to declare a mapping for the Servlet to make the web container forward the requests to the Servlet. There’s two types of mappings you can choose from: extension mapping and prefix mapping. Extension mapping will be of the form “*.extension” and path prefix mapping will be “/path/*”. Here’s an example:

<servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>

I prefer extension mapping for JSF, because this way I’m not restricted to have a certain path for my JSF-enabled pages. The challenge I was talking about previously, has to do with my requirement to go beyond the default mapping mechanism. I want to be able to invoke JSF pages from any path, without using an extension. For example, say there is a JSF page displaying user account information, that has to be invoked using the URL “/account/view.faces”. Wouldn’t it be nicer to have “/account/view” instead?

After a small research, I’ve found out that a Filter can do the job. All that have to be done is a check of the requested URL pattern and if it match the mapping criteria, forward the request to the FacesServlet. Here is how I’ve done it:

public class MappingFilter extends HttpServlet implements Filter {
    ...
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        
        HttpServletRequest httpReq = (HttpServletRequest) request;
        // Get the requested URI
        String uri = httpReq.getRequestURI();
        
        try{
            // Check if the URI matches mapping creteria.
            boolean matches = uri.matches(".*/[\\w]+");
            if(matches){
                ServletContext context = filterConfig.getServletContext();
                // Strip context path from the requested URI
                String path = context.getContextPath();
                if (uri.startsWith(path)){
                    uri = uri.substring(path.length());
                }
                // Check if there is actually a file to handle the forward.
                URL url = context.getResource(uri+".jsp");
                if(url != null){
                    // Generate the forward URI
                    String forwardURI = uri + facesExtension;
                    // Get the request dispatcher
                    RequestDispatcher rd =
                        context.getRequestDispatcher(forwardURI);
                    if(rd != null){
                        // Forward the request to FacesServlet
                        rd.forward(request, response);
                        return;
                    }
                }
            }
            // We are not interested for this request, pass it to the FilterChain.
            chain.doFilter(request, response);
            
        } catch (ServletException sx) {
            filterConfig.getServletContext().log(sx.getMessage());
        } catch (IOException iox) {
            filterConfig.getServletContext().log(iox.getMessage());
        }
        
    }
    ...
}

This filter works just fine and can be used to map extension-less requests to any Servlet. In other words, you can use it to map requests for plain JSP pages also. But when it comes to JSF, there’s a problem: JSF will write action URLs to the forms according to the servlet-mapping parameter that you have set in your web.xml configuration file. So, even if you request using the extension-less URL, after submitting the form your web browser’s bar will have the original location (the one with the extension) -and that’s not nice. After making a huge research this time, struggling for hours to find something in javadocs and in search engines, I’ve managed to find the class responsible for the creation of the action URL. It’s name is ViewHandler and the method is getActionURL(). I’ve also found that you can easily make a custom ViewHandler that sits on top of the one the framework is using and change only part of it’s functionality.

All you have to do is to create a class that extends javax.faces.application.ViewHandler and specify a constructor that takes a parameter of the same type as an argument. Then you declare it in faces-config.xml like this:

<application>        
    <view-handler>gr.xfrag.faces.mapping.MappingViewHandler</view-handler>        
</application>

The JSF framework will find your declaration, and will call your implementation’s constructor, passing it the default ViewHandler used by the implementation you’re using(if you use JSF-RI it will pass com.sun.faces.application.ViewHandlerImpl). You can use this class to delegate every method you don’t want to customize from your custom ViewHandler to the default one. Using this technique, I’ve been able to strip the extension from the action URLs like this:

public class MappingViewHandler extends ViewHandler{
    
    /**
     * The original handler we are customizing.
     */
    private ViewHandler prevHandler = null;
    
    /** Creates a new instance of MappingViewHandler. By including
     * a parameter of the same type, we encourage the JSF framework
     * to pass a reference of the previously used ViewHandler. This way
     * we can use all the previous functionallity and override only the
     * method we are interested in (in this case, the getActionURL() method).
     */
    public MappingViewHandler(ViewHandler prevHandler) {
        this.prevHandler = prevHandler;
    }
    
    
    /**
     * Delegate control to the original ViewHandler
     */
    public Locale calculateLocale(FacesContext context) {
        return prevHandler.calculateLocale(context);
    }

    ...

    /**
     * This is the only method needed to be extended. First, we get the
     * normal URL form the original ViewHandler. Then we simply return
     * the same URL with the extension stripped of.
     */
    public String getActionURL(FacesContext context, String viewId) {
        String origURL = prevHandler.getActionURL(context, viewId);
        int dotIdx = origURL.lastIndexOf(".");
        if (dotIdx > 0) {
            return origURL.substring(0,dotIdx);
        }
        else return origURL;
    }

    ...
}

This way you can have flawless extension-less mapping for JavaServer Faces. If you want to disable requests for URLs having an extension completely (they will still work even if you use my classes), you can add a few more lines of code to the MappingFilter.

To get the complete source code, use the following links:

• MappingFilter
• MappingViewHandler

The good thing is that now I can say I have a clear image of what it takes to consider yourself a web-designer. The whole site is XHTML and CSS valid and cross-browser compatible. I assume the later relying on my tests on Firefox, Internet Explorer 6.0 and Opera 9.0. If you notice any odd behavior on your browser, please notify me and I’ll try to fix it. I really want everyone to be able to read the blog without problems.

The bad side is that I didn’t had any time to spend writing anything about Java… Well I’m pretty stressed up lately studying for the exams at the University, but I’ll try to steal some time and write a few posts.

A good example is an application which continuously tracks a number of important data and represents values on the screen, each one on a separate label. It will be easier for the user to notice a change if the labels perform some kind of animation in response to an update of their value.

It is obvious that to make the above happen, we must “inject” animation code inside JLabel. The task is to figure out a way to start an animation thread whenever the text value of the label is updated. Well you can say this one is easy, because there’s the setText() method which we can override like this:

public void setText(String text){
  super.setText(text);
  if (!text.equals(lastValue)){
    lastValue = text;
    animate();
  }
}


Alright, now that we have set up a mechanism to start the animation, we have to implement the animation procedure itself. The question is: What do we have to put inside animate() method?
When I was trying to find an answer to the above question, I was sure for one thing only: There must be a thread to carry on the animation, witch I had to initiate during the call of animate() method. So I decided to make the class implement the Runnable Interface, and put my core animation code inside the run() method. I ended up with the following body for animate():

private void animate() {
// Only animate if there's not another animation in progress
// and this Label is actually added to a parent Container, i.e.
// if it is visible.
  if(!animating && this.getParent()!=null){
    Thread t = new Thread(this);
    t.start();
  }
}


Now we have to deal with the animation procedure, which involves the manipulation of the paintComponent() method. But this is the most tricky part: Simply having a loop repeating a call to paintComponent() is not a solution, because it requires a Graphics object reference to the screen area where the label resides. This object is normally passed to the method by the Event Model and you actually don’t have control over the last. The right way to make paintComponent() get called with an appropriate Graphics object is to call the repaint() method of the Component. This will add a request to the event queue and eventually will lead to a call of paintComponent().

Ok, so we can have an animation loop inside run() which calls repaint() at the end of every animation frame. Unfortunately, this approach will not work. Subsequent calls to repaint() with sort intervals between them will get stacked in the event queue, but will be treated as one request. Let’s say we make 10 calls of repaint() with an interval of 200 milliseconds. The most probable result is to get only one call of paintComponent() because it’s up to the Event Model to decide when to dispatch the event.

Here is the workaround I figured out:
First, override paintComponent() and add the necessary code to perform the drawing for every frame of the fade effect. Also add a paintCalled flag to be informed about the method call.

public void paintComponent(Graphics g){
  // Let the Label perform its normal painting.
  super.paintComponent(g);
  // Now make the fade effect.
  if(fade != 0){
    Insets i = this.getInsets();
    g.setColor(fadeColor);
    g.fillRect(i.left, i.top,
      getWidth() - i.left - i.right,
      getHeight() - i.top - i.bottom);
  }
  // paintComponent() called, we can continue to the next
  // animation frame.
  paintCalled = true;
}


Second, inside the animation loop, wait for paintComponent() to be called before proceeding to the next animation frame by checking the value of paintCalled flag. A sleep interval of 100 milliseconds proved to be satisfying.

public void run() {
  animating = true;
  fade = initFade;
  try {
    while (fade!=0) { //The animation stops when fade reaches 0.
      ... // Animation control code.
      repaint();
      // Now wait until paintComponent() gets called.
      while(!paintCalled && fade!=0){
        Thread.sleep(100);
      }
    }
    animating = false;
  }
  catch (Exception e) {
    ...
  }
}

And that’s all. It works like a charm!
You can find the full source code of FadeOnChangeLabel here: FadeOnChangeLabel source code. The full class has a method to set fade options(setParams()) and there’s also an additional method named setRepaintContainer() that can be used in circumstances where the JLabel doesn’t control it’s painting, like when you make custom Renderers for list or tree items. Call setRepaintContainer() on the label and pass the Container object that controls it’s painting.
I’ve fully documented the file using comments and hope it would be easy for everyone to understand how it works.

A couple of links to broaden your knowledge on the field:

1. Painting in AWT and Swing
2. Using Swing Components

Finally I can enable search engine bots to crawl the site and make JavaWords available to everyone. Unfortunately(for the readers), I will be on vacation the next days and obviously there will not be anything of great interest to read here until my return…