${sessionScope['org.springframework.web.servlet.i18n.SessionLocaleResolver.LOCALE']}Wednesday, April 22, 2009
How to Get Spring MVC Locale via EL
For some stupid reason, today I just needed to get the current Locale which is determined by the Spring's org.springframework.web.servlet.i18n.SessionLocaleResolver class via EL. Well, as the name implies this Resolver stores the current Locale in Http Session and you can access it with the following EL expression.
Monday, April 6, 2009
How to Connect Catalina MBean
In order to connect Catalina MBean, first you should start Tomcat with the following JVM arguments.
After container is started, run jconsole.exe in JDK's bin folder to open JConsole New Connection dialog. To connect, choose Remote Process, enter localhost:4444 to the field, and press Connect. If you open the MBeans tab, you will see the Catalina MBean on the left panel.
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=4444 (could be anything)
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
After container is started, run jconsole.exe in JDK's bin folder to open JConsole New Connection dialog. To connect, choose Remote Process, enter localhost:4444 to the field, and press Connect. If you open the MBeans tab, you will see the Catalina MBean on the left panel.
Wednesday, March 4, 2009
How to skip tests in Maven
We all had the moment, that we desperately needed to skip our tests in Maven. Well, there are two ways to skip test executions in Maven:
One is to the use maven.test.skip.exec parameter:
This is really hard to remember and it is even deprecated; so I suggest you the following:
One is to the use maven.test.skip.exec parameter:
mvn ... -Dmaven.test.skip.exec=true
This is really hard to remember and it is even deprecated; so I suggest you the following:
mvn ... -DskipTests
Friday, December 19, 2008
How to Exclude Web Resources in Maven 2
According to the maven-war-plugin documentation, Web resources can be excluded according to the following syntax.
However, this syntax does not seem to be working. After investigating the source code, I realized that in fact this plugin expects an excludes element containing a comma separated list of patterns. Following is a sample that I have used successfully in one of my projects to exclude static content. You should also notice that, patterns are relative to the src/main/webapp folder.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>src/main/webapp</directory>
<excludes>
<exclude>css/**</exclude>
<exclude>images/**</exclude>
<exclude>js/**</exclude>
</excludes>
</resource>
</webResources>
</configuration>
</plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>src/main/webapp</directory>
<excludes>
<exclude>css/**</exclude>
<exclude>images/**</exclude>
<exclude>js/**</exclude>
</excludes>
</resource>
</webResources>
</configuration>
</plugin>
However, this syntax does not seem to be working. After investigating the source code, I realized that in fact this plugin expects an excludes element containing a comma separated list of patterns. Following is a sample that I have used successfully in one of my projects to exclude static content. You should also notice that, patterns are relative to the src/main/webapp folder.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<excludes>css/**,images/**,js/**</excludes>
</configuration>
</plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<excludes>css/**,images/**,js/**</excludes>
</configuration>
</plugin>
Wednesday, August 6, 2008
To be, or not to be auto-wired, that is the question.
If properly used, Spring's auto-wire feature might be really handy and it can reduce the volume of your configuration files. It is possible to auto-wire beans by their types or names; but my favorite is auto-wiring by name. You can find more information about this feature here. But now, I want to emphasize one big disadvantage of auto-wiring.
Consider that we are developing an application that will store users and their authorities (roles). In this application, there will be two Data Access Objects (DAO) to deal with User and Authority entity classes, and a service class that depends on these two DAO classes.
In this scenario without using the auto-wire feature our configuration file will look like:
However, when the auto-wire feature is enabled, configuration file will be as simple as:
Although the XML file is way more simple, the dependency information between the beans is lost. In my opinion, it is very good to have such a place listing all the dependency between the beans clearly. By looking at this simple configuration file I cannot say that the User Service depends on User DAO and Authority DAO. When the auto-wire feature is enabled, the only way to learn this information is to inspect all the Java classes.
Consider that we are developing an application that will store users and their authorities (roles). In this application, there will be two Data Access Objects (DAO) to deal with User and Authority entity classes, and a service class that depends on these two DAO classes.
In this scenario without using the auto-wire feature our configuration file will look like:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<!-- DAO Beans -->
<bean id="userDao"
class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />
<bean id="authorityDao"
class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />
<!-- Service Beans -->
<bean id="userService"
class="org.hoydaa.autowire.service.impl.UserServiceImpl"
p:userDao-ref="userDao"
p:authorityDao-ref="authorityDao" />
</beans>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<!-- DAO Beans -->
<bean id="userDao"
class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />
<bean id="authorityDao"
class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />
<!-- Service Beans -->
<bean id="userService"
class="org.hoydaa.autowire.service.impl.UserServiceImpl"
p:userDao-ref="userDao"
p:authorityDao-ref="authorityDao" />
</beans>
However, when the auto-wire feature is enabled, configuration file will be as simple as:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"
default-autowire="byName">
<!-- DAO Beans -->
<bean id="userDao"
class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />
<bean id="authorityDao"
class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />
<!-- Service Beans -->
<bean id="userService"
class="org.hoydaa.autowire.service.impl.UserServiceImpl" />
</beans>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"
default-autowire="byName">
<!-- DAO Beans -->
<bean id="userDao"
class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />
<bean id="authorityDao"
class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />
<!-- Service Beans -->
<bean id="userService"
class="org.hoydaa.autowire.service.impl.UserServiceImpl" />
</beans>
Although the XML file is way more simple, the dependency information between the beans is lost. In my opinion, it is very good to have such a place listing all the dependency between the beans clearly. By looking at this simple configuration file I cannot say that the User Service depends on User DAO and Authority DAO. When the auto-wire feature is enabled, the only way to learn this information is to inspect all the Java classes.
Saturday, May 3, 2008
JSTL 1.2 with Tomcat 6
The new Tomcat 6 does not come with JSTL 1.2 pre-installed. If you are going to use JSTL in a Web application then you should manually add this support by putting the required library (jstl-1.2.jar) to the lib folder of Tomcat. You can download the latest version of JSTL from here.
If you are managing your project with Maven, you should also apply these extra steps.
1. Add this repository element either into pom.xml/<project>/<repositories>, or into conf/settings.xml/<profiles>/<profile>/<repositories>.
2. Add this dependency element into pom.xml/<project>/<dependencies>.
If you are managing your project with Maven, you should also apply these extra steps.
1. Add this repository element either into pom.xml/<project>/<repositories>, or into conf/settings.xml/<profiles>/<profile>/<repositories>.
<repository>
<id>java.net</id>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
<id>java.net</id>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
2. Add this dependency element into pom.xml/<project>/<dependencies>.
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
Tuesday, April 22, 2008
Handling Animated GIFs with GWT
GWT provides an interesting mechanism to deal with images called image bundle. "An image bundle is a composition of many images into a single image, along with an interface for accessing the individual images from within the composite." However this creative approach has a problem. When you use an animated GIF in a page, you just see a normal image with no animation. If you really need an animated GIF, then you should use the com.google.gwt.user.client.ui.Image class. Below is an example snippet demonstrating the use of com.google.gwt.user.client.ui.Image class. For this example, assume that there is a an animated GIF named ajax-loader.gif inside the public folder of your application.
package org.hoydaa.gwtimage.client;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Image;
import com.google.gwt.user.client.ui.RootPanel;
public class GWTImage implements EntryPoint {
public void onModuleLoad() {
Image image = new Image("ajax-loader.gif");
RootPanel.get().add(image);
}
}
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Image;
import com.google.gwt.user.client.ui.RootPanel;
public class GWTImage implements EntryPoint {
public void onModuleLoad() {
Image image = new Image("ajax-loader.gif");
RootPanel.get().add(image);
}
}
Subscribe to:
Comments (Atom)