By adding Java to their App Engine, Google has opened the door for a whole slew of languages that have been implemented on the JVM, now including PHP via Quercus.

This weekend I decided to give it a try and deploy a (very) old tutorial of mine - PHP Tutorial - on GAE.

I must admit that I was very pleasantly surprised by how effortless it was. OK, it’s a very rudimentary PHP application, the only PHP code used was to run the examples described on the code blocks and do some includes; nevertheless I didn’t feel the need to change a single line of code.

Also, deploying a Java application to GAE is simpler than a Python one. Not only because you have a very handy Eclipse plugin, but you will also find configuring the file appengine-web.xml a lot easier when compared to app.yaml.

All you need to do in order to deploy a PHP application, at least as simple as the one I’ve tried, is to follow these steps:

1. Install Google Plugin for Eclipse.
2. Create a Web Application Project in eclipse. The complete project directory looks like this:

   Guestbook/
     src/
       ...Java source code...
       META-INF/
         ...other configuration...
     war/
       ...JSPs, images, data files...
       WEB-INF/
         ...app configuration...
         lib/
           ...JARs for libraries...
         classes/
           ...compiled classes...
   

3. Copy all your PHP and static files to your-project/war.
4. Download Quercus binary (WAR file).
5. Unzip it and copy all files inside quercus.war/WEB-INF/lib to your-project/war/WEB-INF/lib.
6. Edit your deployment descriptor file web.xml. Mine looks like this:
   ^?Download web.xml

   <?xml version="1.0" encoding="utf-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <description>PHP Tutorial</description>   <servlet> <servlet-name>Quercus Servlet</servlet-name> <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class> </servlet>   <servlet-mapping> <servlet-name>Quercus Servlet</servlet-name> <url-pattern>*.php</url-pattern> </servlet-mapping>   <welcome-file-list> <welcome-file>index.php</welcome-file> </welcome-file-list> </web-app>

7. Edit your configuration file appengine-web.xml. Mine looks like this:
   ^?Download appengine-web.xml

   <?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>php-tutorials</application> <version>1</version>   <!-- Configure java.util.logging --> <system-properties> <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" /> </system-properties>   <static-files> <include path="/**" expiration="600s" /> <include path="/**.png" expiration="30d" /> <include path="/**.jpg" expiration="30d" /> <include path="/**.gif" expiration="30d" /> <include path="/**.ico" expiration="30d" /> <include path="/**.swf" expiration="30d" /> <include path="/**.css" expiration="7d" /> <include path="/**.js" expiration="2d 12h" /> <exclude path="/**.php" /> <exclude path="/**.inc" /> </static-files> <resource-files> <include path="/**.php" /> <include path="/**.inc" /> </resource-files> </appengine-web-app>

Et voilà, you are done!

Now, run your application using the Run As >> Web Application command.
And finally, press the “Deploy App Engine Project” button to deploy to GAE.

Related Posts

• JBoss Web and PHP Install Tutorial
• Creating Offline Web Applications with Dojo Offline Tutorial
• More on offline web applications - Google Gears
• Web PHP framework - symfony
• BIRT and PHP Reporting

We need help with Phase 2: if you know a team contact for any of the targeted products that are claiming conformance to W3C Widgets, then would appreciate your help in making them aware of the results of the testing - Widgets 1.0: Compatibility Matrix for Packaging and Configuration.

Popular Posts

• .htaccess - gzip and cache your site for faster loading and bandwidth saving
• Stripes and jQuery Autocomplete
• Deploying BIRT Report Engine API with Jakarta Struts
• Stripes and EJB3
• More on compressing and caching your site with .htaccess

The used source code is also available.

Related Posts

• Stripes and jQuery Autocomplete
• Stripes and jQuery: AJAX forms and HTTP Session Validation
• BIRT/Stripes example
• Stripes and EJB3
• Deploying BIRT Report Engine API with Stripes

JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located.

The goal of this article is to show how easy it is to test these services using TestNG testing framework.

Configuring a service

PersonService is a simple POJO that doesn’t implement any special interfaces.
It has two properties, firstName and lastName, that are inject through a XML deployment descriptor.
The public method that clients will call is getName() and returns the person full name.

public class PersonService {
    private 1.5.0/docs/api/java/lang/String.html">String firstName;
    private 1.5.0/docs/api/java/lang/String.html">String lastName;
 
    public void setFirstName(1.5.0/docs/api/java/lang/String.html">String firstName) { this.firstName = firstName; }
    public void setLastName(1.5.0/docs/api/java/lang/String.html">String lastName) { this.lastName = lastName; }
 
    public 1.5.0/docs/api/java/lang/String.html">String getName() {
        return firstName + " " + lastName;
    }
}

Instances of this service are created by creating an XML deployment descriptor that contains a list of beans representing individual instances.

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"
    xmlns="urn:jboss:bean-deployer:2.0">
 
    <bean name="PersonService" class="com.samaxes.jboss.service.plain.PersonService">
        <property name="firstName">Samuel</property>
        <property name="lastName">Santos</property>
    </bean>
 
</deployment>

We have just declared that we want to create an instance of the PersonService class and register it with the name PersonService. This file is passed to an XML deployer associated with the microcontainer at runtime to perform the actual deployment and instantiate the beans.

Testing a service

JBoss Microcontainer makes it extremely easy to unit test services.
First, you need to create an EmbeddedBootstrap class and override the protected bootstrap() method.
This allows you to created an instance of JBoss Microcontainer together with an XML deployer.

public class EmbeddedBootstrap extends BasicBootstrap {
    protected BasicXMLDeployer deployer;
 
    public EmbeddedBootstrap() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
        super();
    }
 
    public void bootstrap() throws 1.5.0/docs/api/java/lang/Throwable.html">Throwable {
        super.bootstrap();
        deployer = new BasicXMLDeployer(getKernel());
        1.5.0/docs/api/java/lang/Runtime.html">Runtime.getRuntime().addShutdownHook(new Shutdown());
    }
 
    public void deploy(1.5.0/docs/api/java/net/URL.html">URL url) {
        try {
            // Workaround the fact that the BasicXMLDeployer does not handle redeployment correctly
            if (deployer.getDeploymentNames().contains(url.toString())) {
                log.info("Service is already deployed.");
                return;
            }
            deployer.deploy(url);
        } catch (1.5.0/docs/api/java/lang/Throwable.html">Throwable t) {
            log.warn("Error during deployment: " + url, t);
        }
    }
 
    public void undeploy(1.5.0/docs/api/java/net/URL.html">URL url) {
        if (!deployer.getDeploymentNames().contains(url.toString())) {
            log.info("Service is already undeployed.");
            return;
        }
        try {
            deployer.undeploy(url);
        } catch (1.5.0/docs/api/java/lang/Throwable.html">Throwable t) {
            log.warn("Error during undeployment: " + url, t);
        }
    }
 
    protected class Shutdown extends 1.5.0/docs/api/java/lang/Thread.html">Thread {
        public void run() {
            log.info("Shutting down");
            deployer.shutdown();
        }
    }
}

Next, you need to bootstrap the microcontainer. This is done in BaseTest class.

public class BaseTest<T> {
    private 1.5.0/docs/api/java/net/URL.html">URL url;
    private EmbeddedBootstrap bootstrap;
    private 1.5.0/docs/api/java/awt/image/Kernel.html">Kernel kernel;
    private KernelController controller;
 
    @BeforeSuite
    public void setUpSuite() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
        // Start JBoss Microcontainer
        bootstrap = new EmbeddedBootstrap();
        bootstrap.run();
 
        kernel = bootstrap.getKernel();
        controller = kernel.getController();
    }
 
    @AfterSuite
    public void tearDownSuite() {
    }
 
    protected void deploy(1.5.0/docs/api/java/lang/String.html">String url) {
        1.5.0/docs/api/java/lang/ClassLoader.html">ClassLoader cl = 1.5.0/docs/api/java/lang/Thread.html">Thread.currentThread().getContextClassLoader();
        this.url = cl.getResource(url);
 
        bootstrap.deploy(cl.getResource(url));
    }
 
    protected void undeploy() {
        bootstrap.undeploy(url);
    }
 
    @1.5.0/docs/api/java/lang/SuppressWarnings.html">SuppressWarnings( { "unchecked" })
    protected T getService(1.5.0/docs/api/java/lang/String.html">String name) {
        ControllerContext context = controller.getInstalledContext(name);
 
        return (context == null) ? null : (T) context.getTarget();
    }
}

All the test classes extend this one, this allows you to run the microcontainer only once before the test suite.
Another benefit is to have all the utility methods used in every test class in a central place.

Now we can proceed to the last part, and that is to deploy the Person service.

public class PersonServiceTest extends BaseTest<PersonService> {
    private static final 1.5.0/docs/api/java/util/logging/Logger.html">Logger LOGGER = LoggerFactory.getLogger(PersonServiceTest.class);
    private PersonService service;
 
    @BeforeClass
    public void setUp() {
        deploy("jboss-beans.xml");
        service = getService("PersonService");
    }
 
    @AfterClass
    public void tearDown() {
        undeploy();
    }
 
    @Test
    public void getName() {
        1.5.0/docs/api/java/lang/String.html">String name = service.getName();
        LOGGER.info("Name: {}", name);
        assertEquals("Samuel Santos", name);
    }
}

To see it in action, get this example source code and run the Maven command mvn test.

Related Posts

• JBoss PojoCache configuration
• JBoss AS 5.0 is out!
• Maven 2 Cobertura Plugin
• JBoss - Stacking Login Modules
• JBoss Seam 1.0 released

This plugin combines and minimizes JavaScript and CSS files using YUI Compressor for faster page loading.

More details can be found on the Maven Minify Plugin page.

Related Posts

• Maven 2 Cobertura Plugin
• Using Maven 2, XDoclet 2, and Hibernate 3
• Combine and minimize JavaScript and CSS files for faster loading
• Java Web Development with Stripes
• Unit Testing JBoss 5 Services

On most sites, the major component of download time is not the base HTML file itself, but the number of subsequent HTTP requests to load the page’s supporting files - CSS, JavaScript, images, etc.
Each of those are extra HTTP requests, and each unique request takes a relatively long time.
The fewer requests to the server that the browser has to make, the faster the page will load.
There is an inherent overhead in each HTTP request. It takes substantially less time to serve one 60K file than it does three 20K files and a lot less than it does six 10K files.

Combine and minimize files

This post will explain how to combine and minimize CSS and JavaScript files using YUI Compressor and Ant.

This can be done by just concatenating all files into two combined files (one for CSS and one for JavaScript) and minimize them. You can quickly go from 10 or more files down to 2, and their size can be greatly reduced.

To keep the modularity that comes with splitting these files out by section (or business unit), keep them split in your development process, and combine them in your build process. A first Ant task will combine them and a second task will generate their minimized versions.

This technique has been successfully used in libraries such as jQuery, MooTools, Dojo, ExtJS, YUI, etc, allowing developers to better organize their code.

Tools

Ant

Ant is a Java-based build tool. In theory, it is kind of like Make, without Make’s wrinkles and with the full portability of pure Java code.

YUI Compressor

The YUI Compressor is a JavaScript compressor which, in addition to removing comments and white-spaces, obfuscates local variables using the smallest possible variable name. This obfuscation is safe, even when using constructs such as ‘eval’ or ‘with’ (although the compression is not optimal in those cases). Compared to jsmin, the average savings is around 20%.

The YUI Compressor is also able to safely compress CSS files. The decision on which compressor is being used is made on the file extension (js or css).

Build

Download this build example source code.

Code example structure

This code example has the following file organization:

root
|-- build
|   `-- yuicompressor-2.4.2.jar
|-- src
|   |-- css
|   |   |-- base.css
|   |   |-- fonts.css
|   |   |-- reset.css
|   |   `-- style.css
|   |-- js
|   |   |-- samaxesjs.core.js
|   |   `-- samaxesjs.toc.js
|   `-- index.html
`-- build.xml

The build folder contains all the files needed to build the project.
The src folder contains all the project source files.
Finally, the build.xml file is the Ant build script. Here’s where you configure your project build process.

Build script

Let’s take a look at the project build script.

<project name="Build example" default="all" basedir=".">
    <!-- Setup -->
    <property name="SRC_DIR" value="src" description="Source folder" />
    <property name="SRC_CSS_DIR" value="${SRC_DIR}/css" description="CSS source folder" />
    <property name="SRC_JS_DIR" value="${SRC_DIR}/js" description="JavaScript source folder" />
    <property name="DIST_DIR" value="dist" description="Output folder for build targets" />
    <property name="DIST_CSS_DIR" value="${DIST_DIR}/css" description="Output folder for CSS files" />
    <property name="DIST_JS_DIR" value="${DIST_DIR}/js" description="Output folder for JavaScript files" />
    <property name="BUILD_DIR" value="build" description="Files needed to build" />
    <property name="YUI" value="${BUILD_DIR}/yuicompressor-2.4.2.jar" description="YUICompressor" />
 
    <!-- Files names for distribution -->
    <property name="CSS" value="${DIST_CSS_DIR}/style.css" />
    <property name="CSS_MIN" value="${DIST_CSS_DIR}/style.min.css" />
    <property name="JS" value="${DIST_JS_DIR}/samaxesjs.js" />
    <property name="JS_MIN" value="${DIST_JS_DIR}/samaxesjs.min.js" />
 
    <!-- Targets -->
    <target name="html" description="Copy HTML files to the output folder">
        <mkdir dir="${DIST_DIR}" />
        <copy todir="${DIST_DIR}">
            <fileset dir="${SRC_DIR}">
                <include name="*.*" />
            </fileset>
        </copy>
    </target>
 
    <target name="css" depends="html" description="Concatenate CSS source files">
        <echo message="Building ${CSS}" />
        <concat destfile="${CSS}">
            <fileset dir="${SRC_CSS_DIR}" includes="reset.css" />
            <fileset dir="${SRC_CSS_DIR}" includes="fonts.css" />
            <fileset dir="${SRC_CSS_DIR}" includes="base.css" />
            <fileset dir="${SRC_CSS_DIR}" includes="style.css" />
        </concat>
        <echo message="${CSS} built." />
    </target>
 
    <target name="css.min" depends="css" description="Minimize CSS files">
        <echo message="Building ${CSS_MIN}" />
        <apply executable="java" parallel="false" verbose="true" dest="${DIST_CSS_DIR}">
            <fileset dir="${DIST_CSS_DIR}">
                <include name="style.css" />
            </fileset>
            <arg line="-jar" />
            <arg path="${YUI}" />
            <arg value="--charset" />
            <arg value="ANSI" />
            <arg value="-o" />
            <targetfile />
            <mapper type="glob" from="style.css" to="style.min.css" />
        </apply>
        <echo message="${CSS_MIN} built." />
    </target>
 
    <target name="js" depends="html" description="Concatenate JavaScript source files">
        <echo message="Building ${JS}" />
        <concat destfile="${JS}">
            <fileset dir="${SRC_JS_DIR}" includes="samaxesjs.core.js" />
            <fileset dir="${SRC_JS_DIR}" includes="samaxesjs.toc.js" />
        </concat>
        <echo message="${JS} built." />
    </target>
 
    <target name="js.min" depends="js" description="Minimize JavaScript files">
        <echo message="Building ${JS_MIN}" />
        <apply executable="java" parallel="false" verbose="true" dest="${DIST_JS_DIR}">
            <fileset dir="${DIST_JS_DIR}">
                <include name="samaxesjs.js" />
            </fileset>
            <arg line="-jar" />
            <arg path="${YUI}" />
            <arg value="--charset" />
            <arg value="ANSI" />
            <arg value="-o" />
            <targetfile />
            <mapper type="glob" from="samaxesjs.js" to="samaxesjs.min.js" />
        </apply>
        <echo message="${JS_MIN} built." />
    </target>
 
    <target name="clean">
        <delete dir="${DIST_DIR}" />
    </target>
 
    <target name="all" depends="clean, html, css, css.min, js, js.min">
        <echo message="Build complete." />
    </target>
</project>

The html target creates a dist (distribution) folder and copies all the files under src folder into it.

<target name="html" description="Copy HTML files to the output folder">
    <mkdir dir="${DIST_DIR}" />
    <copy todir="${DIST_DIR}">
        <fileset dir="${SRC_DIR}">
            <include name="*.*" />
        </fileset>
    </copy>
</target>

The css target concatenates all CSS files under scr/css folder into the file dist/css/style.css.

<target name="css" depends="html" description="Concatenate CSS source files">
    <echo message="Building ${CSS}" />
    <concat destfile="${CSS}">
        <fileset dir="${SRC_CSS_DIR}" includes="reset.css" />
        <fileset dir="${SRC_CSS_DIR}" includes="fonts.css" />
        <fileset dir="${SRC_CSS_DIR}" includes="base.css" />
        <fileset dir="${SRC_CSS_DIR}" includes="style.css" />
    </concat>
    <echo message="${CSS} built." />
</target>

The css.min target takes the dist/css/style.css file as the input, minimizes its content, and copies it to dist/css/style.min.css.

<target name="css.min" depends="css" description="Minimize CSS files">
    <echo message="Building ${CSS_MIN}" />
    <apply executable="java" parallel="false" verbose="true" dest="${DIST_CSS_DIR}">
        <fileset dir="${DIST_CSS_DIR}">
            <include name="style.css" />
        </fileset>
        <arg line="-jar" />
        <arg path="${YUI}" />
        <arg value="--charset" />
        <arg value="ANSI" />
        <arg value="-o" />
        <targetfile />
        <mapper type="glob" from="style.css" to="style.min.css" />
    </apply>
    <echo message="${CSS_MIN} built." />
</target>

The js target concatenates all JavaScript files under scr/js folder into the file dist/js/samaxesjs.js.

<target name="js" depends="html" description="Concatenate JavaScript source files">
    <echo message="Building ${JS}" />
    <concat destfile="${JS}">
        <fileset dir="${SRC_JS_DIR}" includes="samaxesjs.core.js" />
        <fileset dir="${SRC_JS_DIR}" includes="samaxesjs.toc.js" />
    </concat>
    <echo message="${JS} built." />
</target>

The js.min target takes the dist/js/samaxesjs.js file as the input, minimizes its content, and copies it to dist/js/samaxesjs.min.js.

<target name="js.min" depends="js" description="Minimize JavaScript files">
    <echo message="Building ${JS_MIN}" />
    <apply executable="java" parallel="false" verbose="true" dest="${DIST_JS_DIR}">
        <fileset dir="${DIST_JS_DIR}">
            <include name="samaxesjs.js" />
        </fileset>
        <arg line="-jar" />
        <arg path="${YUI}" />
        <arg value="--charset" />
        <arg value="ANSI" />
        <arg value="-o" />
        <targetfile />
        <mapper type="glob" from="samaxesjs.js" to="samaxesjs.min.js" />
    </apply>
    <echo message="${JS_MIN} built." />
</target>

The clean target removes the dist folder.

<target name="clean">
    <delete dir="${DIST_DIR}" />
</target>

all is the default target and executes all the previous by the order defined in its depends attribute.

<target name="all" depends="clean, html, css, css.min, js, js.min">
    <echo message="Build complete." />
</target>

Execute script

Now that you know the file organization and the build script details; the next step is to execute the script and have the production code ready to be deployed into your hosting/server.

To execute the script make sure you have Ant installed (requires JRE), go to the project root folder (the folder that contains the build.xml file), and type:
ant (executes the default target: all)

Your project structure should now have a new folder dist:

root
|-- build
|   `-- yuicompressor-2.4.2.jar
|-- dist
|   |-- css
|   |   |-- style.css
|   |   `-- style.min.jcss
|   |-- js
|   |   |-- samaxesjs.js
|   |   `-- samaxesjs.min.js
|   `-- index.html
|-- src
|   |-- css
|   |   |-- base.css
|   |   |-- fonts.css
|   |   |-- reset.css
|   |   `-- style.css
|   |-- js
|   |   |-- samaxesjs.core.js
|   |   `-- samaxesjs.toc.js
|   `-- index.html
`-- build.xml

HTML file

If you take a look at the header section of the index.html file you’ll see that I’m only using the style.min.css and samaxesjs.min.js files.

<!DOCTYPE html>
<html>
<head>
    <!-- Other header elements... -->
 
    <!-- CSS -->
    <link rel="stylesheet" href="css/style.min.css" type="text/css" />
    <!-- JavaScript -->
    <script type="text/javascript" src="js/samaxesjs.min.js"></script>
</head>
<body>
    <!-- Other body elements... -->
</body>
</html>

You don’t need to worry about the number of CSS and JavaScript files you have. As long as you add them to the build script the code will be added to the combined file.

Debug

Minimizing JavaScript files makes them nearly impossible to debug since the code will all be in one single line of code.
If you look carefully to the dist/js folder you will see two files there - samaxesjs.min.js and samaxesjs.js. So in order to debug your JavaScript just change the line <script type="text/javascript" src="js/samaxesjs.min.js"></script> in your HTML file to <script type="text/javascript" src="js/samaxesjs.js"></script>.
Easy!

Compression results

The following images are screenshots taken from the YSlow Statistics’ report comparing the debug and minimized versions.

Debug version (combined but not minimized):

Minimized version (combined and minimized):

In this example you have file size reduction gains of nearly 48% for JavaScript files and 59% for CSS files.
As you can see the compression gains are quite considerable.

Related Posts

• Maven Minify Plugin using YUI Compressor
• More on compressing and caching your site with .htaccess
• .htaccess - gzip and cache your site for faster loading and bandwidth saving
• Maven 2 Cobertura Plugin
• Using Maven 2, XDoclet 2, and Hibernate 3

Hopefully the eighth version is going to be a lot easier to test and support since it’s more standards compliant and in that perspective, much closer to the other modern browsers. It’s also comes with easier debugging functionality as it has an integrated set of developer tools available by pressing F12 or by clicking ‘Developer Tools’ under Tools menu.

But right now, together with other major players (Firefox, Opera, Safari and Chrome) you can end up with a total of 7 browsers to test. You might even want to test different versions of individual browsers, transforming this task into a nightmare. Fortunately tools, allowing you to compare different rendering engines in a single unified interface, are emerging and can really save the day. Two great examples are:

1. Microsoft Expression Web SuperPreview
2. DebugBar IETester

For a complete list of browser’s compatibility, check the great Compatibility Master Table from QuirksMode.

Related Posts

• Unit Testing JBoss 5 Services
• Maven 2 Cobertura Plugin

If your log show an error similar to this:

12:38:51,693 ERROR [TerminalSessionHelper] ; nested exception is: 
	java.net.SocketTimeoutException: Read timed out
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.net.SocketTimeoutException: Read timed out
 faultActor: 
 faultNode: 
 faultDetail: 
	{http://xml.apache.org/axis/}stackTrace:java.net.SocketTimeoutException: Read timed out
...

And your call looks like this:

TerminalSessionService terminalSessionService = new TerminalSessionServiceLocator();
 
TerminalSession_PortType terminalSession_PortType = terminalSessionService.getTerminalSession();
 
((TerminalSessionSOAPBindingStub) terminalSession_PortType).setTimeout(15000);

Try to use CommonsHTTPSender as the Transport Sender of the Axis client:

BasicClientConfig basicClientConfig = new BasicClientConfig();
SimpleChain simpleChain = new SimpleChain();
 
simpleChain.addHandler(new CommonsHTTPSender());
basicClientConfig.deployTransport("http", simpleChain);
 
TerminalSessionService terminalSessionService = new TerminalSessionServiceLocator(basicClientConfig);
 
TerminalSession_PortType terminalSession_PortType = terminalSessionService.getTerminalSession();
 
((TerminalSessionSOAPBindingStub) terminalSession_PortType).setTimeout(15000);

This also has the advantage to use HTTP 1.1 instead of HTTP 1.0.
Note: You will need to add the common-httpclient.jar and common.codec.jar to the jar directory for this to work.

Still want to use HTTP 1.0? No problem, just add the following line of code:

((TerminalSessionSOAPBindingStub) terminalSession_PortType)._setProperty(
        MessageContext.HTTP_TRANSPORT_VERSION, HTTPConstants.HEADER_PROTOCOL_V10);

Hope this can save your time. Axis can be really painful…

Related Posts

• Java Web Development with Stripes
• Unit Testing JBoss 5 Services
• Maven Minify Plugin using YUI Compressor
• JBoss PojoCache configuration
• Stripes and jQuery Autocomplete

Introduction

This section gives you an introduction about PojoCache and its advantages over TreeCache (a plain cache system).

PojoCache is an in-memomy, transactional, and replicated POJO (plain old Java object) cache system that allows users to operate on a POJO transparently without active user management of either replication or persistency aspects. PojoCache, a component of JBossCache (uses PojoCache class as an internal implementation, the old implementation TreeCacheAop has been deprecated.), is the first in the market to provide a POJO cache functionality. JBossCache by itself is a 100% Java based library that can be run either as a standalone program or inside an application server.

TreeCache limitations:

• Users will have to manage the cache specifically; e.g., when an object is updated, a user will need a corresponding API call to update the cache content.
• If the object size is huge, even a single field update would trigger the whole object serialization. Thus, it can be unnecessarily expensive.
• The object structure can not have a graph relationship. That is, the object can not have sub-objects that are shared (multiple referenced) or referenced to itself (cyclic). Otherwise, the relationship will be broken upon serialization.

PojoCache advantages:

• No need to implement Serializable interface for the POJOs.
• Replication (or even persistency) is done on a per-field basis (as opposed to the whole object binary level).
• The object relationship and identity are preserved automatically in a distributed, replicated environment. It enables transparent usage behavior and increases software performance.

Use case

We had a project at Present Technologies where we needed to load small amounts of information from external resources and save it during short periods.
This information was read-only and could have a lot of concurrent read accesses. So we wanted a solution that was simpler, faster, and more scalable than saving the data in a traditional database.

Some thoughts we had before choosing PojoCache:

• The amount of information was really small, so keeping it in memory wasn’t a problem.
• Since this data was mainly read-only, replication to other nodes wouldn’t kill our network.
• We needed the object relationships and identities to be preserved automatically in a distributed, replicated environment. PojoCache enables transparent usage behavior and increases software performance.

So the idea was simple. When JBoss AS starts and every once in a while, a service (PojoCache MBean) will kick in, retrieve the data from the external resources, and put it into the cache. As soon as the transaction commits the cache is replicated to all the other nodes in the cluster.

Requirements

This article is targeted to JBossCache version 1.4.1 “Cayenne“, which comes bundle with JBoss AS 4.2.3, and to JDK 5.

Step by step configuration

How to configure PojoCache as a MBean service:

1. JBoss Cache with Java 5 annotations

   Copy the jar file jboss-cache-jdk50.jar from <JBOSS_HOME>/server/all/lib to <JBOSS_HOME>/server/default/lib.

2. PojoCache MBean service configuration

   Copy the PojoCache MBean service configuration file bellow to <JBOSS_HOME>/server/default/deploy.

   ^?Download example-pojocache-service.xml

   <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="org.jboss.cache.aop.PojoCache" name="jboss.cache:service=PojoCache"> <depends>jboss:service=TransactionManager</depends> <!-- Configure the TransactionManager --> <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>   <!-- Isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE --> <attribute name="IsolationLevel">REPEATABLE_READ</attribute>   <!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC --> <attribute name="CacheMode">REPL_SYNC</attribute>   <!-- Just used for async repl: use a replication queue --> <attribute name="UseReplQueue">false</attribute>   <!-- Replication interval for replication queue (in ms) --> <attribute name="ReplQueueInterval">0</attribute>   <!-- Max number of elements which trigger replication --> <attribute name="ReplQueueMaxElements">0</attribute>   <!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> <attribute name="ClusterName">TreeCache-Cluster</attribute>   <!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml <attribute name="ClusterProperties"></attribute> --> <attribute name="ClusterConfig"> <config> <!-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2" --> <!-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true --> <UDP mcast_addr="228.1.2.3" mcast_port="48866" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000" loopback="false" /> <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" /> <MERGE2 min_interval="10000" max_interval="20000" /> <FD_SOCK /> <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" /> <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" up_thread="false" down_thread="false" /> <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" /> <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" /> <FRAG frag_size="8192" down_thread="false" up_thread="false" /> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" /> <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" /> </config> </attribute>   <!-- Whether or not to fetch state on joining a cluster --> <attribute name="FetchStateOnStartup">true</attribute>   <!-- The max amount of time (in milliseconds) we wait until the initial state (ie. the contents of the cache) are retrieved from existing members in a clustered environment --> <attribute name="InitialStateRetrievalTimeout">5000</attribute>   <!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">15000</attribute>   <!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">10000</attribute>   <!-- Name of the eviction policy class. --> <attribute name="EvictionPolicyClass" /> </mbean> </server>

   Notes:

   • This example was taken from PojoCache User Documentation for Release 1.4.1 “Cayenne“.
   • A lot more examples can be found in the folder etc\META-INF present in the JBoss Cache releases.

3. Loadtime Instrumentation

   Copy the jar file pluggable-instrumentor.jar from <JBOSS_HOME>/server/default/deploy/jboss-aop-jdk50.deployer to <JBOSS_HOME>/bin.

4. “prepare” your POJOs

   Declare your POJOs as “prepared” by adding the type level annotation @org.jboss.cache.aop.annotation.PojoCacheable to all that need to be put into cache management.

5. AspectManager service configuration

   Edit jboss-service.xml in <JBOSS_HOME>/server/default/deploy/jboss-aop-jdk50.deployer/META-INF to enable loadtime transformations.

   ^?Download jboss-service.xml

   <?xml version="1.0" encoding="UTF-8"?> <!-- ===================================================================== --> <!-- JBoss Server Configuration --> <!-- ===================================================================== --> <server> <!-- The code for the service is different for the different run scenarios *** JBoss 4.0 * JDK 1.4 - org.jboss.aop.deployment.AspectManagerService * JDK 5 (not using -javaagent switch) - org.jboss.aop.deployment.AspectManagerService * JDK 5 (using -javaagent switch) - org.jboss.aop.deployment.AspectManagerServiceJDK5 * BEA JRockit 1.4.2 - org.jboss.aop.deployment.AspectManagerService *** JBoss 3.2 * JDK 1.4 - org.jboss.aop.deployment.AspectManagerService32 * JDK 5 (not using -javaagent switch) - org.jboss.aop.deployment.AspectManagerService32 * JDK 5 (using -javaagent switch) - org.jboss.aop.deployment.AspectManagerService32JDK5 * BEA JRockit 1.4.2 - org.jboss.aop.deployment.AspectManagerService32 --> <mbean code="org.jboss.aop.deployment.AspectManagerServiceJDK5" name="jboss.aop:service=AspectManager"> <attribute name="EnableLoadtimeWeaving">true</attribute> <!-- only relevant when EnableLoadtimeWeaving is true. When transformer is on, every loaded class gets transformed. If AOP can't find the class, then it throws an exception. Sometimes, classes may not have all the classes they reference. So, the Suppressing is needed. (i.e. Jboss cache in the default configuration --> <attribute name="SuppressTransformationErrors">true</attribute> <attribute name="Prune">true</attribute> <!--attribute name="Include">org.jboss.test, org.jboss.injbossaop</attribute--> <attribute name="Include">com.samaxes.example</attribute> <attribute name="Exclude">org, com, net, bsh, javassist, antlr, com.arjuna</attribute> <!-- This avoids instrumentation of hibernate cglib enhanced proxies <attribute name="Ignore">*$$EnhancerByCGLIB$$*</attribute> --> <attribute name="Optimized">true</attribute> <attribute name="Verbose">false</attribute> </mbean>   <mbean code="org.jboss.aop.deployment.AspectDeployer" name="jboss.aop:service=AspectDeployer"> </mbean> </server>

   Be sure to only include the packages that contains the POJOs to be aspectized and exclude all others.
   Not doing so can really slowdown your server startup!

6. AOP configuration

   Enable your POJOs to be aspectized copying the AOP configuration file bellow to <JBOSS_HOME>/server/default/deploy.

   ^?Download example-aop.xml

   <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE aop PUBLIC "-//JBoss//DTD JBOSS AOP 1.0//EN" "http://labs.jboss.com/portal/jbossaop/dtd/jboss-aop_1_0.dtd">   <aop> <!-- If a POJO has JDK5 PojoCacheable annotation, it will be aspectized. --> <prepare expr="field(* @org.jboss.cache.aop.annotation.PojoCacheable->*)" />   <!-- If a POJO has JDK5 InstanceOfPojoCacheable annotation, it will be aspectized. --> <prepare expr="field(* $instanceof{@org.jboss.cache.aop.annotation.InstanceOfPojoCacheable}->*)" /> </aop>

7. JAVA_OPTS environment variable

   Edit run.sh or run.bat (depending on what OS you’re on) and add the following to the JAVA_OPTS environment variable:
   set JAVA_OPTS=%JAVA_OPTS% -javaagent:pluggable-instrumentor.jar.

Usage

How to use and interact with PojoCache.

1. Sample POJO

   Create a simple POJO.

   ^?Download Person.java

   package com.samaxes.example;   import org.jboss.cache.aop.annotation.PojoCacheable;   @PojoCacheable public class Person { private 1.5.0/docs/api/java/lang/String.html">String firstName;   private 1.5.0/docs/api/java/lang/String.html">String lastName;   public 1.5.0/docs/api/java/lang/String.html">String getFirstName() { return firstName; }   public void setFirstName(1.5.0/docs/api/java/lang/String.html">String firstName) { this.firstName = firstName; }   public 1.5.0/docs/api/java/lang/String.html">String getLastName() { return lastName; }   public void setLastName(1.5.0/docs/api/java/lang/String.html">String lastName) { this.lastName = lastName; } }

2. Cache Helper Singleton

   Create a singleton to interact with PojoCache.

   ^?Download CacheHelper.java

   package com.samaxes.example;   import javax.management.MBeanServer; import javax.management.MalformedObjectNameException;   import org.jboss.cache.aop.PojoCacheMBean; import org.jboss.mx.util.MBeanProxyExt; import org.jboss.mx.util.MBeanServerLocator;   public class CacheHelper { public static final CacheHelper INSTANCE = new CacheHelper();   private static PojoCacheMBean pojoCache;   public PojoCacheMBean getPojoCache() { return pojoCache; }   private CacheHelper() { try { 1.5.0/docs/api/javax/management/MBeanServer.html">MBeanServer server = MBeanServerLocator.locate(); pojoCache = (PojoCacheMBean) MBeanProxyExt.create(PojoCacheMBean.class, "jboss.cache:service=PojoCache", server); } catch (1.5.0/docs/api/javax/management/MalformedObjectNameException.html">MalformedObjectNameException e) { // log exception... } } }

   Note: This step is optional but it allows to not have duplicated code and to have only one instance of the PojoCache MBean in the application context.

3. Using PojoCache

   And that’s it! Give it a try.

   ^?View Code JAVA5

   // Puts Person object into cache management CacheHelper.INSTANCE.getPojoCache().putObject("/aop/person", person);   // Gets Person object from cache CacheHelper.INSTANCE.getPojoCache().getObject("/aop/person");

   Every time you change a Person property, cache will manage its replication or persistency automatically.
   As cited in the introduction, this is done on a per-field basis.

No MBean support

It’s possible to use PojoCache without using MBeans.
The examples available in the PojoCache User Documentation use the following strategy:

cache = new PojoCache();
PropertyConfigurator config = new PropertyConfigurator(); // configure tree cache.
config.configure(cache, "META-INF/replSync-service.xml"); // Search under the classpath
cache.start();
...
cache.stop();

Resources

• JBoss AOP
• JBoss Cache
• PojoCache User Documentation for Release 1.4.1 “Cayenne“

Note: For questions about JBoss technologies please use JBoss forums.

Related Posts

• Unit Testing JBoss 5 Services
• JBoss AS 5.0 is out!
• J2EE cache filter
• JBoss - Stacking Login Modules
• JBoss Seam 1.0 released

Internationalization, or i18n, is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a “locale”).

Adapting application to various languages is for me, as a Java and HTML developer, more than a common task. Usually the solution involves a set of supported locales, which is very often different from the system locale and/or browser configuration. Majority of such cases are covered by the scenario when user chooses particular language settings and the only place where the locale setting can be stored is the HTTP Session.

Support for this behavior is now handled by majority of frameworks; nevertheless there is still one HTML element that you can’t effectively change - the file upload form field.

And that’s not the only issue related to this element; it’s nearly completely inaccessible to CSS manipulation, making it impossible to style it as other form input fields (luckily there are some workarounds available - SWFUpload or Styling an input type=”file”).

To tackle the internationalization issues should be quite straightforward. However after discussion with the WHAT Working Group members (community focused on development of the HTML 5 specification) I’ve recognized their concerns about the styling of the upload field, mainly in regards to the security and privacy.

Following this, Ian Hickson - the editor and spokesman for the WHAT Working Group - came with the surprisingly easy suggestion how to address this problem. It seems like browsers should already handle this based on the lang=”" attribute:

It seems like browsers should do this already based on the lang=”" attribute. I recommend asking browser vendors to implement this.

And therefore I would like to endorse vendors to implement at least this behavior.

This way if user chooses the pt locale in his profile but the browser is configured only to support English (en), the developer can get the locale from user’s HTTP Session and propagate it through the attribute lang="pt" of the file upload field and have the button caption matching users preferences.

I would highly appreciate feedback on this topic, especially from the browser vendors willing to implement this feature.

Related Posts

• The Semantic Web and RDFa
• HTML 5 @media 2008
• Java and UTF-8 encoding
• Localization in ASP.NET 2.0
• How to build Multi-Language Web Sites with ASP.NET 2.0 and VS.Net 2005