My blog has moved!

You will be automatically redirected to the new address. If that does not occur, visit
http://utku-utkan.appspot.com/
and update your bookmarks.

Pages

Wednesday, July 27, 2011

Monday, July 18, 2011

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.

${sessionScope['org.springframework.web.servlet.i18n.SessionLocaleResolver.LOCALE']}

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.

-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:

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.

<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>

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:

<?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>


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>


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.