어쨌든 이렇게 글을 쓰게 된 이유는 이런 저런 경험을 겪으며 나도 나름 생각이 변화를 겪게 되었기 때문이다. 개발을 잘할 것이냐 일을 잘할 것이냐. 이런 문제를 맞닥드렸을 때 개발자는 어떤 답을 가지고 행동해야 할까. 명확히 짚고 넘어가야 할 것은 ‘일’의 범주는 개발을 포함하며 개발보다 훨씬 더 넓고 애매하고 사람마다 정의가 다르다는 점이다.

사람이 적은 회사에서는 개발보다는 ‘일’을 잘하는게 중요할 것이다. 사람이 적기 때문에 부서구분이 명확하지 않은 대신에 ‘일’의 정의, 쉽게 말해서 우리가 이런 일을 하는 이유와 목표가 공유되는데 좀 더 수월하기 때문이다. 작은 회사에서 ‘내가 맡은 일만 잘하면 돼’라는 생각은 그 생각 자체로 독이된다.

그러나 대기업, 아니 직원이 100명 이상만되어도(이 수치도 또한 애매하다.) 다른 상황이 될 수 있다. 철저히 분업화된 조직구조에서는 쓸데없이 회사 전체의 목표에 숟가락 얹을려고 하면 배가 산으로 갈 수 있다는 것이다. 이럴때는 분업 구조에서 주어진 목표를 정확히 하는게 전체 조직으로선 최선이라는 생각이 든다.

사실 나 스스로 뛰어난 개발자라 생각하지 않는다. 그래서 더 기획이나 서비스 영역쪽에 참여하고 싶고 ‘내가 만들어가는 서비스’에 좀 더 강하게 끌렸던 것 같다. 하지만 이젠 그래선 안되겠다는 생각이다. 그래봤자 좋은 소리 듣기 힘들고 노력한다 해도 성과가 나기 힘들다. 또 사람이 많다 보니 굳이 나 말고도 여기저기서 불협화음은 많이 생기기 마련이기 때문이다.

내가 발딛고 있는 곳이 어딘지 본 뒤에야 지평선을 보아야 한다. 내가 발디딘 곳은 3000명 규모의 조직안에서도 개발조직이다. 그렇다면 당연하게도 난 개발이라는 ‘일’에 최선을 다해야한다. 다른 것을 생각할 때 조심하지 않으면 월권이 되고 의견은 무시되거나 나만 힘들어지게 된다. 중요한건 어떻게 개발을 잘 하느냐이다.

결론은 굉장히 기운빠진 말이된다. ‘서비스가 어떻게 성공하든 말든 그건 중요하지 않아 나는 요구사항을 일정 안에 만족시키도록 개발만 잘하면 돼’라고 표현하면 개발만 잘하겠다라고 목표를 가진 사람도 기운이 빠지거나 반발을 할지 모른다. 그러나 ‘일’의 범주와 정의는 자신의 목표와도 관계가 있지만 주변 상황과도 깊은 관계가 있다. 큰 조직에서 개발을 잘해서 그 조직안에서 인정받는 개발자가 되려고 열심히 하는것도 굉장히 의미있는 일이라는 생각이다.

개발자는 할 수 있는 일이 참 많다. 대신에 부딪쳐야 할 벽도 많은 것 같다. 어쨌든 난 부딪혀 보는 것에 대해선 무엇이든 득이 될 것이라고 믿는다.

잔인한 4월도 다 지나갔고,
5월 초의 지긋지긋한 연휴도 끝나간다.

I sat upon the shore fishing,
with the arid plain behind me
Shall I at least set my lands in order?
(V. What the Thunder Said)

여름휴가를 다녀와서 찍은 사진을 플리커에 올리고 워드프레스로 보내기를 해봤다.

플리커, 딜리셔스 그리고 구글의 iGoogle, 노트북 그리고 블로깅을 하고 있는 워드프레스.. 이런 다양한 서비스들을 각각에 맞게 사용하려고는 하지만 통합하기가 나같은 Geek에게도 쉽지 않다.
개개의 서비스는 모두 특정 기능에 있어서는 정말 훌륭하다는 생각이 든다. 플리커의 Organizr, iGoogle의 다양한 widget들, 그리고 타 서비스가 따라가기 힘든 노트북의 검색기능과 딜리셔스의 소셜 태깅기능 등등.
하지만 나의 니즈를 충족시키기 힘든 면이 있다.

여러가지 아쉬운점이 있지만 일단 플리커 사진을 올리면서 부족하다고 느낀 Privacy 문제에 대해 얘기하자면,

우선, 그냥 가끔 웹서비스에 관한 내용을 올릴 뿐, 그에 관해 난 전문 블로거도 아니고 평범한 Life Logger이다. 일상을 낱낱이 모든 사람에게 공개할 수는 없으니 Life Logging에는 섬세한 권한 관리 기능이 필요하다. 하지만 외국 서비스들은 기본적으로 개방적인 기준으로 서비스를 만들어놓아서 권한 제한이 대부분 게시물에 대한 설정이 전부다. 반면에 싸이월드는 게시물뿐 아니라 메뉴, 폴더별로 공개 설정을 할 수 있으며 댓글, 스크랩 등도 다양한 권한 설정을 적용할 수 있다.
두번째로, 다양한 서비스들을 사용하면서 생기는 문제인데 바로 서비스들 간에 로그인 정보가 공유가 되지 않는다는 것이다. 결국 한쪽에서 프렌드공개로 된 컨텐츠는 연동된 쪽에서는 그냥 비공개로 되어버린다는 점이다. 문제상황을 쉽게 풀어쓰면 플리커에 프렌드공개로 올린 사진을 워드프레스로 보내면 그 사진은 그냥 비공개일 뿐이며 워드프레스에서 볼 수 없다는 얘기이다. 플리커의 프렌드가 워드프레스에서도 프렌드가 아닐테니 당연한 얘기겠지만 플리커로 친구들과 찍은 사진을 관리하고 워드프레스로 게시하고 싶은 사람에게는 아쉬운 일일 수밖에 없다.

극복방안.. 아무리 짱구를 굴려봐도 방법이 없다. -_-;
그냥 공개로 쓰거나 아니면…
플리커와 워드프레스, 딜리셔스, 노트북, iGoogle를 모두 제공하는 서비스를 만들거나.. 허허…

그나마 Facebook, MySpace가 사용자 정보까지 오픈API로 풀고 있다니 로그인, 인맥정보도 공유가 되길 기대해보지만 모든 서비스가 통합이 이뤄지는 일은 요원해 보인다.

단순히 Hibernate tool로 generate된 dao(Data Access Object) 코드에서 JNDI가 사용되기 때문에 generate된 코드를 수정없이 쓰려면 JNDI 환경을 먼저 설정해 주어야 했다.

JNDI 기본 패키지는 JDK 1.2부터 기본으로 포함되었다. 문제는 context 라이브러리다. 자신이 사용하고자 하는 Directory에 따라 라이브러리를 classpath에 넣어주어야 한다. 라이브러리는 다음 링크에서 다운 받을 수 있다.

http://java.sun.com/products/jndi/downloads/index.html

현재는 1.2.1의 경우 license agreement를 하고 들어가면 여러가지 Directory Service Provider에 해당하는 라이브러리가 나열된다. 이중에서 local file system을 JNDI를 통해 접근하려면 File System Service Provider를 지원하는 fscontext*.jar 가 있어야 한다.

라이브러리를 다운받고 classpath에 넣은 후에는 jndi.properties 파일을 작성해준다. jndi.properties 파일의 위치는 classpath 가장 상위 디렉토리 밑에 위치해야 한다. 예를 들어 classpath가 C:\classpath\ 라면 C:\classpath\jndi.properties 파일이 있어야 한다. (classpath가 여러개고 복수개의 jndi.properties 파일이 있다면…? 어떻게 되는지 나도 모르겠다. 그냥 여기에서 그렇게 하라고 나와 있으니깐.. -_-)

jndi.properties에는 다음과 같이 설정한다.

# context factory class
java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
# class 가 들어있는 디렉토리
java.naming.provider.url=file:///C:/workspace/project/bin
# 요건 뭔지 모르겠네..
com.sun.jndi.ldap.netscape.schemaBugs=true

그리고 Java 코드에서 다음과 같이 초기화와 동시에 인스턴스를 저장한다.

        InitialContext ctx = new InitialContext();
        try{
            Object fac = ctx.lookup("SessionFactory");
            if(fac == null){
                ctx.rebind("SessionFactory", sessionFactory);
            }
        }catch(NamingException ne){
            ctx.bind("SessionFactory", sessionFactory);
        }
        dao = new DailySearchByTypeHome();

rebind를 하는 이유는 잘은 모르겠지만 아마도 local file system이 서버가 아니기 때문에 process가 종료되면 저장된 인스턴스가 없어지기 때문에 JNDI에 SessionFactory란 이름이 존재하여도 인스턴스가 없어서 null로 반환되기 때문이다. 그래서 인스턴스를 다시 재등록하는 것이다.

저장된 인스턴스는 다음과 같이 꺼내쓸 수 있다.

        try {
            return (SessionFactory) new InitialContext().lookup("SessionFactory");
        }
        catch (Exception e) {
            log.error("Could not locate SessionFactory in JNDI", e);
            throw new IllegalStateException("Could not locate SessionFactory in JNDI");
        }

Bean Copy 포스트의 말미에서 얘기했듯이 특정 property를 변환하여 bean을 복사하는 방법에 대해서 알아보자.

내가 생각한 방법은 BeanUtils 또는 PropertyUtils의 describe 함수를 사용하여 original bean이 가지고 있는 properties의 Map 객체를 받은 후 Map에 있는 Object를 변경하고, BeanUtils 객체의 populate 함수를 사용하여 destination bean으로 복사를 하는 방법이다.

describe는 bean이 가지고 있는 모든 property를 Map으로 반환하는 함수이고, populate는 Map을 원하는 bean으로 복사하는 함수니까 얼핏 보면 간단할 것 같다.

그런데 내가 삽질한 부분은 BeanUtils와 PropertyUtils의 describe함수가 다르게 동작한다는 것이다.

BeanUtils API 문서를 보면 알겠지만 Map이 Generic으로 되어 있지 않다. BeanUtils.describe도 return type이 java.util.Map이고 PropertyUtils.describe도 마찬가지로 java.util.Map이다. 그래서 Map에 들어가 있는게 뭔지 모르겠다. 이게 뭥미…

공통적으로

두 함수의 모두 Map의 Key값으로 String 객체를 이용하며, property name이 된다. 예를 들어 bean에 setName함수와 getName함수가 있다면 “name”으로된 key가 있고 getName 함수의 return 값이 “name” key의 value로 들어간다.

PropertyUtils.describe(Object bean) 함수의 경우

return type은 Map<String, Object> 의 형태다. 즉, bean에 설정된 property의 객체 그대로를 Map에 담는다. 즉 bean에서 다음과 같이 선언되어 있다면

 public Name getName(){ ... }

맵에는 {“name”, Name instance} 형태로 저장이 된다는 얘기다.

BeanUtils.describe(Object bean)의 경우

java.util.Map<String, String> 형태다. 즉, 모든 property는 String.class에 설정된 Converter를 통해서 변환되어 Map에 담게 된다.

위와 같이 getName이 선언되어 있고 기본 ConvertUtils를 사용한다면 사용자가 직접 정의한 Name 객체에 대한 변환 로직이 당연히 없을 것이기 때문에, Object.toString함수를 이용하여 변환한다. 만약 Name 객체에서 toString함수를 Overriding했다면 그 함수를 실행해서 변환하게 되지만, 그마저도 구현하지 않았다면 Object.toString 함수를 그대로 사용하기 때문에 “name”에 대한 value는 Name 인스턴스의 hashCode가 String형태로 들어가게 된다.

결과적으로

아마도 BeanUtils의 String 변환은 출력에 사용될 경우 많은 곳에 쓰이겠지만, 난 변환된 bean을 로직에 사용하고자 하므로 PropertyUtils의 describe를 쓰는 것이 맞겠다. 그런데 일일이 Map에서 꺼내서 변환하면 귀찮으니까 ConvertUtils 스타일로 Convert하나 만들었다.

ConvertUtilsBean.java
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import org.insoul.util.Converter;

public class ConvertBeanUtil {
	static Map<String, Converter> converters = new HashMap<String, Converter>();

	public static Map<String, Object> convert(Map<String, Object> des) throws Exception{
		Iterator<String> property_names = des.keySet().iterator();
		while(property_names.hasNext()){
			String property_name = property_names.next();
			if(converters.containsKey(property_name)){
				Object new_value = converters.get(property_name)
					.convert(des.get(property_name));
				des.put(property_name, new_value);
			}
		}
		return des;
	}

	public static void register(String property_name, Converter conv){
		converters.put(property_name, conv);
	}

	public static void deregister(String property_name){
		converters.remove(property_name);
	}
}
    Converter.java
package org.insoul.util;

public interface Converter {
	public Object convert(Object obj) throws Exception;
}
    Implementation of Converter

import org.insoul.util.Converter;

public class ConverterSearchType implements Converter{
	public Object convert(Object obj) throws Exception{
		try{
			return ((String)obj).charAt(0);
		}catch(ClassCastException e){
			throw new Exception(&quot;Type conversion failed&quot;, e);
		}
	}
}
    Usage
ConvertBeanUtil.register("searchType", new ConvertSearchType());
Map<String, Object> des = PropertyUtils.describe(orignal_bean);
Map<String, Object> map = ConvertBeanUtil.convert(des);
BeanUtils.populate(newbean, map);

bean을 전혀 다른 bean(상속받은 것도 아니고 같은 패키지도 아닌 전혀 상관없는 bean)으로 복사를 하고 싶을 때가 있다. 일일이 복사를 하자니 노가다이고, 상속 같은 방법을 써보고도 싶지만 return type이 서로 다른 같은 이름이 있으면 상속이 안되는 등 귀찮은 작업이 될 여지가 많다. 이럴 때 Apache commons 의 BeanUtils를 사용한다.

이 패키지를 쓸 때, bean을 복사하는 방법에는 두가지 방법이 있다.

1. PropertyUtils를 사용하는 방법과
2. BeanUtils를 사용하는 방법

두 객체 모드 copyProperties 함수가 있으나 동작방식은 다르다.

공통적으로

같은 이름의 property에 대해서만 복사가 이루어진다.

당연하게도 destination에 setter가 없거나, original에서 getter가 없는 property에 대해서는 복사가 이루어지지 않는다.

1.의 경우

original bean과 destination bean의 모든 property는 동일한 객체여야 한다. 객체가 틀릴 경우 IllegalArgumentException이 발생한다.

즉, 두개의 bean이 같은 property에 대해서는 객채가 일치해야 한다.

또한 destination bean의 “age”라는 property의 setter가 int 형으로 parameter를 받고, original bean에서 “age”의 getter가 값을 Integer 객체로 return할 때, 만약 orignal bean의 “age”가 null이어도 IllegalArgumentException이 발생한다. 왜냐하면 destination의 setter function의 primitive type paramter가 null로 들어가기 때문이다.

따라서, 같은 property가 original bean은 primitive object, destination bean은 primitive type일 경우 original bean의 해당 property가 null이 된 상태에서 PropertyUtils.copyProperties 함수를 사용하지 않도록 주의해야 한다.

2. 의 경우

original bean의 getter가 return하는 객체와 destination bean의 setter는 parameter 객체는 동일할 필요가 없다. BeanUtils에서 적절하게 property type의 변환을 해주며, PropertyUtils에서 설명한 primitive type에 사용에 따른 Exception도 적절하게 처리해준다.

BeanUtils는 기본적으로 ConvertUtilsBean 에서 설정된 default 값을 가지고 변환이 이루어진다. 부적절한 변환일 경우 default 값으로 변환되며, String이 char로 변환될 경우 첫글자로 변환되는 식이다.

이러한 변환 과정이 구현에 따라 바뀔 필요가 발생할 떄도 있는데, 이는 ConvertUtilsBean으로 해결이 가능하다. ConvertUtilsBean에서 구현이 바뀌어야 할 type을 deregister 함수로 빼고 난 뒤, 새롭게 정의한 Converter를 해당 type으로 register함수를 이용하여 등록해주면 된다.

import org.apache.commons.beanutils.*;
public class Test {
	public static void main(String[] args){
		...
		ConvertUtilsBean cub = new ConvertUtilsBean();
		cub.deregister(Integer.class);
		cub.register(new IntConv(), Integer.class);
		cub.register(new IntConv(), Integer.TYPE);

		BeanUtilsBean bub = new BeanUtilsBean(cub, new PropertyUtilsBean());

		bub.copyProperties(destination, original);
		...
	}
}

class IntConv implements Converter{
	//	implemented method
	public Object convert(Class type, Object value){
		if(value == null){
			return 0;
		}else{
			if(value instanceof Integer){
				return value.intValue();
			}else if(value instanceof String){
				return -1;
			}else if(value instanceof AnotherObject){
				return someValue;
			}else...
		}
	}
}

여기서 중요한 것은 String -> Integer로 변환되는 것을 새롭게 정의하고 싶다면, String.class 에 정의된 Converter를 바꾸는게 아니고 Integer.class에 정의 된 Converter를 바꿔야 한다는 것이다. convert함수의 구현을 잘 보면 알겠지만 original의 다양한 객체에 대해서 대응하고 return 값은 int로 바꾸고 있다.

BeanUtilsBean의 생성자 parameter에 포함된 PropertyUtilsBean은 어따 써먹는지 잘 모르겠다. -_-

여기서 또 한발짝 나가면 특정 property만 변경해서 복사하고 싶을 때가 있다. 예를 들어 다른 int 속성은 안바꾸고 1980년을 29세로 바꾸고 싶은 경우. 이럴 때 내가 낸 해답은 describe함수를 쓰는 것이다.

이 역시 BeanUtils와 PropertyUtils 모두 가지고 있는 함수이지만 역시 동작 방식은 다르다. 다음 포스팅은 이에 대해서 다룬다.