xpj's knowledge base » Java

Compressing content using a servlet filter

xpj — Wed, 03 Nov 2010 10:24:22 +0000

One year and little bit more I was gzipping Spring remoting requests and responses. Now is time to gzip web application

The simplest solution is to use filter in your web.xml. I found implementation in ehcache called net.sf.ehcache.constructs.web.filter.GzipFilter


 gzip
 net.sf.ehcache.constructs.web.filter.GzipFilter



 gzip
 /*

Spring remoting with gzip compression

xpj — Mon, 29 Jun 2009 14:48:49 +0000

GZip compression is well known standard, used almost everywhere. Modern web servers are able to communicate with modern browsers and this communication can be automatically gzipped. But if you are unsure, if your communication is compressed, you can use your own.

With the Spring HTTP remoting it’s so easy as to implement extensions for existing classes.

package cz.xpj.expee.spring.remoting.httpinvoker;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;

import org.springframework.remoting.httpinvoker.SimpleHttpInvokerRequestExecutor;

/**
 * Extension of {@link SimpleHttpInvokerRequestExecutor} for gzip compression
 * @author xpj
 */
public class GZIPSimpleHttpInvokerRequestExecutor extends SimpleHttpInvokerRequestExecutor {

 /**
 * @see org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor#decorateInputStream(java.io.InputStream)
 */
 @Override
 protected InputStream decorateInputStream(InputStream is) throws IOException {
 return new GZIPInputStream(is);
 }

 /**
 * @see org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor#decorateOutputStream(java.io.OutputStream)
 */
 @Override
 protected OutputStream decorateOutputStream(OutputStream os) throws IOException {
 return new GZIPOutputStream(os);
 }

}

And the other side of your communication…

package cz.xpj.expee.spring.remoting.httpinvoker;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter;

/**
 * Extension of {@link HttpInvokerServiceExporter} for gzip compression
 * @author xpj
 */
public class GZIPHttpInvokerServiceExporter extends HttpInvokerServiceExporter {

 /**
 * @see org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter#decorateInputStream(javax.servlet.http.HttpServletRequest, java.io.InputStream)
 */
 @Override
 protected InputStream decorateInputStream(HttpServletRequest request, InputStream inputStream) throws IOException {
new GZIPInputStream(inputStream);
}

/**
* @see org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter#decorateOutputStream(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, java.io.OutputStream)
*/
@Override
protected OutputStream decorateOutputStream(HttpServletRequest request, HttpServletResponse response, OutputStream outputStream) throws IOException {
return new GZIPOutputStream(outputStream);
}

}

I tested this communication on some artificial data, and the results were really nice

Sended (List with # of longs)	Without GZIP [bytes]	With GZIP [bytes]
1000	20328	2741
2000	40328	5235
3000	60328	7852

I know, this is not so good example, but with different data (some entities etc.) we are still better than without compression

How stop embedded ActiveMQ in Spring

xpj — Tue, 09 Jun 2009 14:34:17 +0000

Today I ran into problems with embedded ActiveMQ broker in Spring Framework. The goal is to run local application, which uses Spring context to start AMQ and after this application is finished, AMQ should stop.

My setup of spring context xml is following (I’m using the amq schema and this is only the needed part).

And the app looks like this:

context = new ClassPathXmlApplicationContext("client-local-context.xml");

 ComputingStarterService computingStarterService = (ComputingService)context.getBean("computingStarterService");
 computingStarterService.start("Test");

And the problem is, that the main part of application stops, but the AMQ is still running. I tried a lot of things and the only working thing is to use

context.close();

I don’t know if there is another way to stop embedded AMQ. How it works eg. in JUnit tests?

JTable with fixed columns

xpj — Fri, 05 Jun 2009 12:18:23 +0000

JTable with fixed columns is really problem. There is no “one-and-the-only-right” solution for fixing one or two columns while leaving others scrollable.

There are two solutions for this problem.

Two tables solution

This solution uses two tables, one for fixed columns and other for the rest. This solution is described in nice article Fixed Column Table and the same solution is used in JXTable from xframe project.

This solution works nice, but there is one small UI (maybe more visual) problem. Scrollbar is visible only on the part of table, which is scrollable.

Two tables solution

Another solution

“Another” solution is described in Freezable JTables (are they extreme?). This solution uses custom component, which is exactly the same size like the fixed columns and the fixed columns are painted into this component. And everything looks like the JTable supports fixed columns.

The problem with this solution is, that the fixed columns are “image” You can find some difficulties when you moved with scrollbar and tried to doubleclick on some cell in the fixed column. You will edit another cell, hidden under this “image”

Another solution

I will continue with searching

Difference between jee:jndi-lookup and JndiObjectFactoryBean?

xpj — Thu, 04 Jun 2009 12:18:02 +0000

I found slight difference between usage of and definition of beans using JndiObjectFactoryBean.

Following configuration works well on local Jetty, but doesn’t work deployed on WebLogic server. But with this configuration, everything is fine. Little bit strange

Configuring Jetty with ActiveMQ and JNDI xpj — Thu, 04 Jun 2009 08:54:23 +0000 For development of Message Driven POJOs (see cute tutorial on Spring blogs) I need some testing environment with running JMS server. As I’m using Maven and his Jetty plugin, I found following solution. Configuring Jetty For configuring Jetty with JNDI, we need to place some configuration options into its configuration files. There are three options: jetty.xml WEB-INF/jetty-env.xml context xml file For me, the most easiest way is to use the jetty-env.xml in WEB-INF directory. So I created this file: jms/connectionFactory tcp://localhost:61616 jms/requestQueue requestQueue jms/replyQueue replyQueue Next step is to setup resources in web.xml file to use this JNDI resources. Connection Factory jms/connectionFactory javax.jms.QueueConnectionFactory Container jms/requestQueue javax.jms.Queue jms/replyQueue javax.jms.Queue Configuring Spring context.xml The hardest stuff is behind us Just now, we can use the jee schema for configuring beans. Running Don’t forget to start your ActiveMQ server and than just fire up maven jetty:run. But it will work better, if you use following snippet in your pom file org.mortbay.jetty maven-jetty-plugin 6.1.10 10 foo 9999 start-jetty process-test-classes run 0 true stop-jetty test stop org.apache.activemq activemq-core 5.2.0 org.apache.xbean xbean-spring 2.8