Jun 3, 2008

Moved to Python

Unfortunately for Java community, I'm the next one to leave it.
I'm no longer J2EE fellow, and I'm really happy with Python, excelent language and platforn that just do the job without any buzz around it.

Dec 17, 2007

Amazon has opened SimpleDB service

Now you can easily outsource your database hosting. One more step to enabling infrastructures that are completely build using SaS approach.
Good analysis of the topic is here

Jul 9, 2007

Choosing scripting language (Bash vs Perl vs Python vs Ruby)

Not Java but definitely Enterprise.

Like many other companies one day we faced the problem when bash was not enough for facilitating work of our product. We started investigation about what language to use to use in addition to simple bash scripts.

As you see Python is a winner due to the simplest syntax and good experience of using it in Google and Amazon.

Hope this helps to make scripting in our company more consistent.

Jul 8, 2007

Accessing properties loaded via Spring PropertyPlaceholderConfigurer from JSP


The problem is defined here
I have configured some properties files for the application using the PropertyPlaceholderConfigurer. How can I access these properties in JSP?

We have faced the same problem when we quite often need access from JSP to some configurable parameter. Usually we did the same way as described in the forum thread by having specific beans that were configured by PropertyPlaceholderConfigurer. But with the time they began look like some pretty wrong approach, when we had properties that are not connected to each other in one place and clear understanding that it is a workaround that need to be eliminated.


Idea was very simple, read all properties configured by PropertyPlaceholderConfigurer and put them to some attribute of the ServletContext, thus getting them accessible via 'application' scope from JSP. However it looks simple but there is no ability to extract resolved properties from PropertyPlaceholderConfigurer, I spend quite time to read code and understand what to do.


The simples way I found is extending it with own class that will do the job of exposing properties to the outside.
package com.sonopia.sonoportal.web.util;

import java.util.Collections;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Properties;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;

* Bean that should be used instead of the {@link PropertyPlaceholderConfigurer} if you want to have
* access to the resolved properties not obly from the Spring context. e.g. from JSP or so. More
* details about usage here http://wiki.sonopia.com/x/GmQ
* @author Mykola Palienko
public class ExposablePropertyPaceholderConfigurer extends PropertyPlaceholderConfigurer {

private Map<String, String> resolvedProps;

protected void processProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
Properties props) throws BeansException {
super.processProperties(beanFactoryToProcess, props);
resolvedProps = new HashMap<String, String>();
for (Object key : props.keySet()) {
String keyStr = key.toString();
resolvedProps.put(keyStr, parseStringValue(props.getProperty(keyStr), props,
new HashSet()));

public Map<String, String> getResolvedProps() {
return Collections.unmodifiableMap(resolvedProps);


and configuring it in the Spring context declaration xml file in your project

    <bean id="propertyConfigurer" class="com.sonopia.sonoportal.web.util.ExposablePropertyPaceholderConfigurer">
<property name="locations">

The good thing here is that we also resolve ANT style properties like ${dbname} etc.

Then we need to expose that properties to the ServletContext, this job usually is done by implementing ServletContextListener.

* Copyright 2005-2006 Sonopia Corporation
package com.sonopia.sonoportal.web.listener;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

import com.sonopia.sonoportal.web.util.ExposablePropertyPaceholderConfigurer;

* Listener that exposes properties configured by {@link ExposablePropertyPaceholderConfigurer} to
* the web application context.
* More details about usage here http://wiki.sonopia.com/x/GmQ
* @author Mykola Palienko
public class ConfigPropertiesExposerListener implements ServletContextListener {

public static final String DEFAULT_PROPERTIES_BEAN_NAME = "propertyConfigurer";

public static final String DEFAULT_CONTEXT_PROPERTY = "configProperties";

private String propertiesBeanName = DEFAULT_PROPERTIES_BEAN_NAME;

private String contextProperty = DEFAULT_CONTEXT_PROPERTY;

public void contextDestroyed(ServletContextEvent sce) {

public void contextInitialized(ServletContextEvent sce) {
// TODO add ability to configure non default values via serveltContexParams
ServletContext servletContext = sce.getServletContext();
WebApplicationContext context = WebApplicationContextUtils
ExposablePropertyPaceholderConfigurer configurer =
(ExposablePropertyPaceholderConfigurer) context.getBean(propertiesBeanName);
sce.getServletContext().setAttribute(contextProperty, configurer.getResolvedProps());


and add several lines to the web.xml



Having all above done accessing any property from JSP is not harder than


The snippet above will print out website.hostname property configured by ExposablePropertyPaceholderConfigurer

Jun 16, 2007

Formatting date to client timezone

Unlike a locale information that is passed by browsers via HTTP header, there is no straightforward way to retrieve the information about client timezone offset.
I also have not found any ready-to-use solutions to workaround this in web and one day when we've been posted the bug that our SMS sending times appears to be in the server timezone. I've found the solution.
The idea is pretty easy, the only way you can pass client timezone to the server is by calculating it using

var tzo = new Date().getTimezoneOffset();        

Next step - you need to pass it to the server, there is a number of ways to do it but they all have one drawback, you cannot format dates from the just loaded page, since script executes on the client. Anyway the options are: Cookie and AJAX. Cookie is easier and seems that AJAX is overkill here, that is why I've chosen cookie way.

The whole code on the client looks like
<c:if test="${sessionScope['sonoportal.timezoneOffset'] == null}">
<!--Setting TZ offset-->
<script type="text/javascript">
var tzo = new Date().getTimezoneOffset();
document.cookie = "timezoneOffset=" + escape(tzo * (-1));

We've also added the condition not to send cookie if we already have info about user timezone offset in the HttpSession.

Now we need to process the timezone on server and set it to the session. In our application we are using standard JSTL fmt:formatDate for formatting dates and times. Fortunately you can set default timezone in the user's HttpSession scope and it will be used authomatically. Here is the code for a Filter that do the job:

package com.sonopia.sonoportal.web.filter;

import java.io.IOException;
import java.util.TimeZone;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.jsp.jstl.core.Config;

import org.apache.commons.lang.time.DateUtils;

* @author Mykola Paliyenko
public class SetTimezoneOffsetFilter implements Filter {

public static final String PROPERTY_TIMEZONE_OFFEST = "sonoportal.timezoneOffset";

public static final String COOKIE_NAME = "timezoneOffset";

public void destroy() {

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;
if (req.getSession().getAttribute(PROPERTY_TIMEZONE_OFFEST) == null) {
if (req.getCookies() != null) {
for (Cookie cookie : req.getCookies()) {
if (COOKIE_NAME.equals(cookie.getName())) {
int timezoneOffsetMinutes = Integer.parseInt(cookie.getValue());
TimeZone timeZone = TimeZone.getTimeZone("GMT");
(int) (timezoneOffsetMinutes * DateUtils.MILLIS_PER_MINUTE));
Config.set(req.getSession(), Config.FMT_TIME_ZONE, timeZone);
PROPERTY_TIMEZONE_OFFEST, timezoneOffsetMinutes);
// removing cookie, Sun sucks as usual in their API
chain.doFilter(request, response);

public void init(FilterConfig config) throws ServletException {


Note that we are removing cookies once we get the timezone offset to reduce client/server traffic since otherwise it get send with every single request.
What remains? Declaring filter web.xml file

Thats all. Now your site is one of a little set of sites that care about user's time zone.


- First served page in session will show the server times.
- If user changing timezone within session it will not be tracked by server. It is a very minor issue but still
- Additional global filter for the application

Getting started

This blog is about building feature rich application based on Java open source frameworks, problems and solution related to it. Creating our product day by day from prototype to the live system, from 4 developers to 30+, we get valuable experience that might be useful to share with community.