잊지 않겠습니다.

Gradle + yo deploy script

gradle을 이용한 build script 만들기 재미가 붙어, 이번에는 yo로 만든 web application을 auto-deploy를 지원하는 script를 한번 작성해봤습니다.

지원하는 시나리오는 다음과 같습니다.

  1. 이번에 작성한 2개의 public web과 mobile web을 모두 사용 가능
  2. 다음과 같은 process를 진행 가능해야지 됨
  • grunt build
  • svn에 새로 deploy할 web application의 압축본을 add & commit
  • ftp를 이용한 web application 배포

먼저, 여러 web application을 지원하기 위한 조건은 외부 parameter를 받는 방법이 가장 좋아서 target을 지정하기로 했습니다.

작성된 web aplication들의 구조는 다음과 같습니다.

.
├── admin-web
├── mobile-web
├── public-web
└── sample-web

여기서 sample-web의 경우에는 팀원들에게 같이 공유할 sample web application이기 때문에 배포 대상이 되지 못하고, admin, mobile, public의 경우에는 배포 대상이 될 수 있습니다. 간단히 이름을 기준으로 admin, mobile, public을 기준으로 삼고, 이를 parameter로 받으면 될 수 있다는 판단이 내려졌습니다.

이제 다음 조건들이 필요합니다.

  • grunt,svn 과 같은 command의 실행
  • grunt deploy가 된 후에 zip compress
  • ftp를 이용한 data copy

gradle을 이용한 command의 실행

기본적으로 gradle을 이용한 command는 type을 Exec로 잡아주면 처리가 가능합니다. 이와 같은 sub directory 내에서 실행되어야지 될 command는 workingDir 값을 지정해줘서 처리가 가능합니다. 다음은 grunt build를 하는 code입니다.

task build(type: Exec) {
    workingDir getWebDir()
    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        commandLine 'cmd', '/c', 'grunt', 'build'
    } else {
        commandLine 'grunt', 'build'
    }
    ext.output = {
        return standardOutput.toString()
    }
}

윈도우즈 계통과 linux/mac을 모두 지원하기 위해서 OS의 type을 설정해줘야지 됩니다. windows에서 cmd와 /c를 이용하는 것만을 주의하면 매우 간단한 코드입니다.

zip 파일 압축

zip 압축은 gradle에서 기본으로 제공하고 있는 Zip type을 이용하면 됩니다. zip type의 경우, from과 destinationDir만을 주의해서 처리하면 됩니다. 다음은 만들어진 distPath의 모든 내용을 yyyyMMddHHmm-hostname.zip 형식으로 압축을 하는 코드입니다.

task compressDist(type: Zip) {
    dependsOn 'build'

    from file(getDistPath())
    destinationDir file(deployPath)

    def now = new Date()
    def dateFormat = new SimpleDateFormat("yyyyMMddHHmm");
    def hostname = InetAddress.getLocalHost().getHostName().toLowerCase()

    filename = String.format("%s-%s.zip", dateFormat.format(now), hostname)
    archiveName filename
}

FTP 파일 전송

gradle은 자체적으로 FTP를 지원하지 않습니다. 다만 ant 를 지원하고 있기 때문에, ant의 FTP를 이용하면 됩니다. 그런데 ant ftp의 경우에는 send시에 hang이 걸리는 버그를 가지고 있습니다. passive mode를 true로 설정하는 것으로 hang이 걸리는 경우를 조금 덜 하게 할 수 있긴 하지만, 그래도 send에서 hang이 걸리는 것을 완벽하게 막지는 못합니다. 이 부분에 대해서는 좀 더 논의가 필요할 것 같습니다. 다음은 ftp 전송 코드입니다.

task 'upload' {
    dependsOn 'commitSvn'
    doLast {
        def remoteDir = getFtpPath()
        ant {
            taskdef(name: 'ftp', classname: 'org.apache.tools.ant.taskdefs.optional.net.FTP', classpath: configurations.ftpAntTask.asPath)
            ftp(action: 'mkdir', remotedir: remoteDir, server: ftpUrl, userid: ftpUsername, password: ftpPassword)
            ftp(action: 'delete', remotedir: remoteDir, server: ftpUrl, userid: ftpUsername, password: ftpPassword) {
                fileset() { include(name: '**/*') }
            }
            ftp(action: 'send', remotedir: remoteDir, verbose: true,
                    depends: true, binary: true, passive: true,
                    server: ftpUrl, userid: ftpUsername, password: ftpPassword) {
                fileset(dir: getDistPath()) {
                    include(name: '**/**/*')
                }
            }
        }
    }
}

각 build task에 대한 dependency를 추가하고, target argument를 받아서 처리하도록 코드 수정을 마져 완료한 최종 코드는 다음과 같습니다.

import org.apache.tools.ant.taskdefs.condition.Os

import java.text.SimpleDateFormat

configurations {
    ftpAntTask
}

repositories {
    mavenCentral()
}

dependencies {
    ftpAntTask("org.apache.ant:ant-commons-net:1.8.2") {
        module("commons-net:commons-net:1.4.1") {
            dependencies "oro:oro:2.0.8:jar"
        }
    }
}

def ftpUrl = '192.168.13.210'
def ftpUsername = 'ykyoon'
def ftpPassword = 'qwer12#$'
def filename = ''

def getDistPath() {
    return String.format('%s/dist', getWebDir())
}

def getWebDir() {
    return String.format('%s-web', project.target)
}

def getDeployPath() {
    return String.format('../deployed/%s-web/', project.target);
}

def getFtpPath() {
    return String.format('www-fms/%s', project.target);
}

task build(type: Exec) {
//    dependsOn 'upSvn'
    workingDir getWebDir()
    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        commandLine 'cmd', '/c', 'grunt', 'build'
    } else {
        commandLine 'grunt', 'build'
    }
    ext.output = {
        return standardOutput.toString()
    }
}

task compressDist(type: Zip) {
    dependsOn 'build'

    from file(getDistPath())
    destinationDir file(deployPath)

    def now = new Date()
    def dateFormat = new SimpleDateFormat("yyyyMMddHHmm");
    def hostname = InetAddress.getLocalHost().getHostName().toLowerCase()

    filename = String.format("%s-%s.zip", dateFormat.format(now), hostname)
    archiveName filename
}

task upSvn(type: Exec) {
    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        commandLine 'cmd', '/c', 'svn', 'up'
    } else {
        commandLine 'svn', 'up'
    }
    ext.output = {
        return standardOutput.toString()
    }
}

task addSvn(type: Exec) {
    dependsOn 'compressDist'

    String svnParam = getDeployPath() + filename
    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        commandLine 'cmd', '/c', 'svn', 'add', svnParam
    } else {
        commandLine 'svn', 'add', svnParam
    }
    ext.output = {
        return standardOutput.toString()
    }
}

task commitSvn(type: Exec) {
    dependsOn 'addSvn'
    String svnParam = getDeployPath() + filename
    String svnLog = '-mCommit file before deployed'

    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        commandLine 'cmd', '/c', 'svn', 'add', svnParam, svnLog
    } else {
        commandLine 'svn', 'commit', svnParam, svnLog
    }
    ext.output = {
        return standardOutput.toString()
    }
}

task 'upload' {
    dependsOn 'commitSvn'
    doLast {
        def remoteDir = getFtpPath()
        ant {
            taskdef(name: 'ftp', classname: 'org.apache.tools.ant.taskdefs.optional.net.FTP', classpath: configurations.ftpAntTask.asPath)
            ftp(action: 'mkdir', remotedir: remoteDir, server: ftpUrl, userid: ftpUsername, password: ftpPassword)
            ftp(action: 'delete', remotedir: remoteDir, server: ftpUrl, userid: ftpUsername, password: ftpPassword) {
                fileset() { include(name: '**/*') }
            }
            ftp(action: 'send', remotedir: remoteDir, verbose: true,
                    depends: true, binary: true, passive: true,
                    server: ftpUrl, userid: ftpUsername, password: ftpPassword) {
                fileset(dir: getDistPath()) {
                    include(name: '**/**/*')
                }
            }
        }
    }
}

task 'deploy' {
    dependsOn 'build'
    dependsOn 'upload'
    doLast {
        println 'grunt build and upload'
    }
}

task help << {
    println '--------- gradle web command help ----------------------'
    println 'gradle deploy -Ptarget=public : public web build'
    println 'gradle deploy -Ptarget=mobile : mobile web build'
    println '--------- end line -----------------------------------------'
}

모두들 즐거운 코딩 되세요. ^^

Posted by xyzlast Y2K
TAG gradle, Yo

HikariCP 소개

Java 2014.08.21 17:10

HikariCP

BoneCP를 재치고 놀라운 속도를 자랑하는 DB Connection Pool입니다. BoneCP의 경우, Hibernate 4.x 버젼에서의 지원이 조금 애매해진 경향이 있습니다. (최신 버젼의 Hibernate에서는 에러가 발생합니다.) 반면에 HikariCP의 경우에는 Hibernate와의 통합 jar가 나오는 등, 계속해서 밀어주고 있다는 느낌이 강하게 듭니다.

GitHub page

https://github.com/brettwooldridge/HikariCP

Hibernate + HikariCP

build.gradle에 다음 dependency들을 추가합니다.

    compile 'org.slf4j:slf4j-api:1.7.5'
    compile 'com.zaxxer:HikariCP:2.0.1'
    compile 'org.javassist:javassist:3.18.2-GA'

hibernate.cfg.xml 파일에 다음 항목을 추가합니다.

<property name="connection.provider_class">com.zaxxer.hikari.hibernate.HikariConnectionProvider</property>
<property name="hibernate.hikari.dataSourceClassName">com.mysql.jdbc.jdbc2.optional.MysqlDataSource</property>
<property name="hibernate.hikari.dataSource.url">jdbc:mysql://localhost/test</property>
<property name="hibernate.hikari.dataSource.user">root</property>
<property name="hibernate.hikari.dataSource.password">qwer12#$</property>
<property name="hibernate.hikari.dataSource.cachePrepStmts">true</property>
<property name="hibernate.hikari.dataSource.prepStmtCacheSize">250</property>
<property name="hibernate.hikari.dataSource.prepStmtCacheSqlLimit">2048</property>
<property name="hibernate.hikari.dataSource.useServerPrepStmts">true</property>

Spring + HikariCP

@Configuration을 이용해서 HikariCP를 사용하는 법은 다음과 같습니다.

DataSource를 이용하는 경우 (ex: mssql server)
    @Bean(destroyMethod = "shutdown")
    public DataSource dataSource() {
        HikariDataSource dataSource = new HikariDataSource();

        dataSource.setUsername(env.getProperty(CONNECT_USERNAME));
        dataSource.setPassword(env.getProperty(CONNECT_PASSWORD));

        dataSource.setDataSourceClassName("com.microsoft.sqlserver.jdbc.SQLServerDataSource");
        dataSource.addDataSourceProperty("url", env.getProperty(CONNECT_URL));

        int minConnection = Integer.parseInt(env.getProperty(CONNECT_MIN));
        dataSource.setMinimumIdle(minConnection);
        int maxConnection = Integer.parseInt(env.getProperty(CONNECT_MAX));
        dataSource.setMaximumPoolSize(maxConnection);

        return dataSource;
    }
Driver를 이용하는 경우 (ex: mssql server)
    @Bean(destroyMethod = "shutdown")
    public DataSource dataSource() {
        HikariDataSource dataSource = new HikariDataSource();

        dataSource.setUsername(env.getProperty(CONNECT_USERNAME));
        dataSource.setPassword(env.getProperty(CONNECT_PASSWORD));
        dataSource.setDriverClassName(env.getProperty(CONNECT_DRIVER));
        dataSource.setJdbcUrl(env.getProperty(CONNECT_URL));

        int minConnection = Integer.parseInt(env.getProperty(CONNECT_MIN));
        dataSource.setMinimumIdle(minConnection);
        int maxConnection = Integer.parseInt(env.getProperty(CONNECT_MAX));
        dataSource.setMaximumPoolSize(maxConnection);

        return dataSource;
    }

HikariCP property

HikariCP의 property 설정은 다음과 같습니다.

autoCommit (default : true)

connection이 종료되거나 pool에 반환될 때, connection에 속해있는 transaction을 commit 할지를 결정합니다.

readOnly (default : false)

database connection을 readOnly mode로 open합니다. 이 설정은 database에서 지원하지 않는다면 readOnly가 아닌 상태로 open되기 때문에, 지원되는 database 목록을 확인해보고 사용해야지 됩니다.

transactionIsolation (default : none)

java.sql.Connection 에 지정된 Transaction Isolation을 지정합니다. 지정된 Transaction Isoluation은 다음과 같습니다.

  • Connection.TRANSACTION_NONE : transaction을 지원하지 않습니다.
  • Connection.TRANSACTION_READ_UNCOMMITTED : transaction이 끝나지 않았을 때, 다른 transaction에서 값을 읽는 경우 commit되지 않은 값(dirty value)를 읽습니다.
  • Connection.TRANSACTION_READ_COMMITTED : transaction이 끝나지 않았을 때, 다른 transaction에서 값을 읽는 경우 변경되지 않은 값을 읽습니다.
  • Connection.TRANSACTION_REPEATABLE_READ : 같은 transaction내에서 값을 또다시 읽을 때, 변경되기 전의 값을 읽습니다. TRANSACTION_READ_UNCOMMITTED 와 같이 사용될 수 없습니다.
  • Connection.TRANSACTION_SERIALIZABLE : dirty read를 지원하고, non-repeatable read를 지원합니다.

기본값을 각 Driver vendor의 JDBCDriver에서 지원하는 Transaction Isoluation을 따라갑니다. (none으로 설정시.)

category (default : none)

connection에서 연결할 category를 결정합니다. 값이 설정되지 않는 경우, JDBC Driver에서 설정된 기본 category를 지정하게 됩니다.

connectionTimeout(default: 30000 - 30 seconds)

connection 연결시도시 timeout out값을 설정합니다. 이 시간내로 connection을 연결하는데 실패하면 SQLException을 발생합니다.

idleTimeout(default : 600000 - 10 minutes)

connection Pool에 의하여 확보된 connection의 maximum idle time을 결정합니다. connection Pool에 의하여 확보된 connection이 사용되지 않고, Pool에 의해서만 이 시간동안 관리된 경우, connection을 DB에 반환하게 됩니다. 값을 0으로 설정하는 경우, 확보된 connection을 절대 반환하지 않습니다.

maxLifetime(default : 1800000 - 30 minutes)

connection Pool에 의하여 확보된 connection의 최대 생명주기를 지정합니다. connection을 얻어낸지, 이 시간이상되면 최근에 사용하고 있던 connection일지라도, connection을 close시킵니다. 사용중에 있던 connection은 close 시키지 않습니다. (사용이 마쳐지면 바로 close 됩니다.) HikariCP에서는 이 값을 30~60 minutes 사이의 값을 설정하라고 강력권고합니다. 값을 0로 설정하는 경우 lifetime은 무제한이 됩니다.

leakDetectionThreshold (default : 0)

connectionPool에서 반환된 connection의 올바른 반환이 이루어졌는지를 확인하는 thread의 갯수를 지정합니다. 이 값을 0로 지정하는 경우, leak detection을 disable 시키게 됩니다. 만약에 또다른 connection pool을 사용하고 있다면, 다른 connection pool에서 만들어진 connection을 leak으로 판단하고 connection을 닫아버릴 수 있습니다.

jdbc4ConnectionTest (default : true)

connection을 맺은다음, Connection.isValid() method를 호출해서 connection이 정상적인지를 확인합니다. 이 property는 다음에 나올 connectionTestQuery에 매우 밀접한 영향을 받습니다.

connectionTestQuery (default : none)

Connection.isValid() method를 지원하지 않는 ‘legacy’ database를 위한 빠른 query를 지정합니다. (ex: VALUES 1) jdbc4ConnectionTest가 더 유용하기 때문에 사용하지 않는 것이 좋습니다.

connectionInitSql (default : none)

새로운 connection이 생성되고, Pool에 추가되기 전에 실행될 SQL query를 지정합니다.

dataSourceClassName (default : none)

JDBC driver에서 지원되는 dataSourceClassName을 지정합니다. 이 값은 driverClassName이 지정된 경우, 지정할 필요가 없습니다.

dataSource (default : none)

사용자가 만든 dataSource를 Pool에 의하여 wrapped하는 것을 원하는 경우, 이 값을 지정하여 사용합니다. HikariCP는 이 문자열을 이용해서 reflection을 통해 dataSource를 생성합니다. 이 값이 설정되는 경우, dataSourceClassName, driverClassName 과 같은 값들은 모두 무시 됩니다.

driverClassName

HikariCP에서 사용할 DriverClass를 지정합니다. 이 값이 지정되는 경우, jdbcUrl이 반드시 설정되어야지 됩니다.

jdbcUrl

jdbcUrl을 지정합니다. driverClassName이 지정된 경우, jdbcUrl을 반드시 지정해줘야지 됩니다.

minimumIdle (default : maximumPoolSize)

connection Pool에서 유지할 최소한의 connection 갯수를 지정합니다. HikariCP에서는 최고의 performance를 위해 maximumPoolSize와 minimumIdle값을 같은 값으로 지정해서 connection Pool의 크기를 fix하는 것을 강력하게 권장합니다.

# maximumPoolSize

connection Pool에서 사용할 최대 connection 갯수를 지정합니다. 이 부분은 운영환경과 개발환경에 매우 밀접하게 연결되는 부분으로, 많은 테스트 및 운영이 필요합니다.

username

Connection을 얻어내기 위해서 사용되는 인증 이름을 넣습니다.

password

username과 쌍이 되는 비밀번호를 지정합니다.

poolName (default : auto-generated)

logging과 JMX management에서 지정할 pool의 이름을 지정합니다.

registerMbeans (default : false)

JMX management Beans에 등록되는 될지 여부를 지정합니다.

Posted by xyzlast Y2K

Hibernate에서의 양방향 @OneToOne의 이용

Domain Model을 만들때, @OneToOne은 많은 의미를 갖습니다. Master-Detail 구조에서 Detail을 의미하기도 하고, Query를 만들어서 처리할 때, 많은 데이터를 한번에 읽기보다는 작은 데이터를 먼저 읽어서 표시하는데에 사용하는 등의 어찌보면 역정규화를 이용할 때 주로 사용됩니다. (개인적으로는 하나의 Big Table로 처리하는 것이 개발 상에서는 가장 편할 지도 모른다. 그런데 이렇게 하는 경우, Query를 사용해서 처리할 때 Query양이 많아지고 Table이 너무나 커져버리는 단점이 있습니다.) 또한, @OneToOne Relation은 Table을 이용한 BL의 확장에 큰 영향을 주게 됩니다. 새로운 BL Process가 생성되었을 때, 기존 Table을 변경하지 않는 방향으로 BL을 확장할 수 있기 때문에 현업에서는 자주 사용되는 방법입니다.

그런데, 여기에 문제가 있는 것이, 기본적으로 JPA에서는 @OneToOne은 모두 Early Loading으로만 처리가 가능하다는 점입니다. 이를 Lazy Loading으로 전환하기 위해서는 단방향처리만이 가능하게 처리해야지 됩니다. Parent에서 Key를 갖는 형식으로 말이지요.

그런데, 이와 같은 방법 역시 문제를 가지고 있습니다. 단방향처리만이 가능하다는 것은 기본적으로 처리하는 parent entity에서 FK를 가져야지 된다는 점입니다. Table 추가를 통한 Domain Logic의 확장에 있어서, 이는 기존 Table을 변경해야지 되는 큰 약점을 가지게 됩니다.

따라서, @OneToOne을 양방향으로 사용할 수 있는 방법을 반드시 제시할 수 있어야지 Domain Logic을 생성하는데 ORM을  사용하는 것이 될 수 있을 것입니다. 양방향(bidirection)으로 @OneToOne을 Lazy Loading으로 사용하기 위한 방법은 다음 3가지가 제시됩니다.

@OneToMany, @ManyToOne을 이용하는 방법

객체를 @OneToOne으로 사용하지 않고, Lazy Loading을 사용하기 위해서 다른 Relation으로 정의하고, Code상에서는 @OneToOne 처럼 사용하는 것입니다. 개인적으로 가장 싫어하는 방법입니다. 객체간의 관계를 객체만으로 명확히 보이는 ORM의 장점을 모두 무시하는 방법이라고 생각합니다. 또한 QueryDSL이나 HQL의 작성시에 매우 어렵게 되며, 생성되는 Query 역시 효율성이 떨어지는 Query를 생성하게 됩니다.

byte code instrument를 이용하는 방법

: 이는 CTW(compile time weaver)를 이용해서 처리하는 것입니다. Hibernate에서 제공하는 build time instrument를 이용해서 compile 시에 처리하는 방법입니다. 이에 대한 설명은 다음 Hibernate의 문서를 참고하는 것이 좋습니다. (ant 등 build Task가 별도로 필요합니다. ) -http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching-lazyproperties
: 이 부분에 대한 설명은 Hibernate 4.x 대에서 제거되었습니다. 4.x에서의 byte code instrument가 지원되는지는 추가 확인이 필요합니다.
: Proxy를 사용하지 않기 때문에 다음과 같은 NoProxy 설정이 필요합니다.

@OneToOne(fetch = FetchType.LAZY, optional = true) @LazyToOne(LazyToOneOption.NO_PROXY) @JoinColumn(name = "customerPetitId", nullable = true) private CustomerPetit customerPetit;
runtime byte code instrument를 이용하는 방법

: 이 방법은 LTW(load time weaver)를 이용해서 처리하는 방법입니다. 이 방법을 사용하기 위해서는 full-blown JEE environment에서 구성되어야지 됩니다. tomcat, jboss, jetty와 같은 JEE 환경에서만 사용이 가능하다는 단점을 갖습니다. (JUnit Test 환경에서는 동작하지 않습니다.)
: hibernate.ejb.use_class_enhancer 설정을 true로 해주는 것으로 설정이 가능합니다. 이 방법 역시 @LazyToOne(LazyToOneOption.NO_PROXY) annotation이 필요합니다.
: Spring 환경에서도 사용이 가능합니다. 단, Lazy Loading시의 performance 이슈는 해결되어야지 됩니다.

위 3가지 방법이 JBoss에서 문서화된 방법들입니다. 이러한 방법 이외에 다른 방법을 하나 더 소개하고자 합니다. 이 방법은 @OneToMany, @ManyToOne 방법과 같이 HQL의 변경을 가지고 오지도 않고, build 시에 새로운 task를 생성할 필요가 없으며, LTW와 같이 성능 저하나 환경을 따르지도 않습니다.

FieldHandler, FieldHandled를 이용한 Bi-Direction @OneToOne

이 방법은 Hibernate의 내부에 이미 구현된 FieldHandler를 사용하는 방법입니다. FieldHandler는 객체에 값을 주입할 때, Hibernate core에서 사용되는 객체입니다. 또한 Hibernate는 FieldHandled interface를 구현한 객체의 경우, Hibernate에서 load될 때, 자동으로 주입시켜주기 때문에 우리가 별도로 개발할 필요는 없습니다.

구현하기 위한 조건은 다음 2가지입니다.

  1. @LazyToOne(LazyToOneOption.NO_PROXY) annotation
  2. Entity 객체에 FieldHandled interface 구현

구현되는 코드는 다음과 같습니다. (양방향이기 때문에 Parent, Child Entity에 모두 구현해야지 됩니다.)

public class OperationResult extends AbstractInsertUpdateEntity implements Serializable, FieldHandled {
    @OneToOne(fetch = FetchType.LAZY, optional = true)
    @LazyToOne(LazyToOneOption.NO_PROXY)
    @JoinColumn(name = "operationId", nullable = true)
    private OperationPlan plan;

    public void setPlan(OperationPlan plan) {
        if(fieldHandler != null) {
            this.plan = (OperationPlan) fieldHandler.writeObject(this, "plan", this.plan, plan);
        } else {
            this.plan = plan;
        }
    }

    public OperationPlan getPlan() {
        if(fieldHandler != null) {
            this.plan = (OperationPlan) fieldHandler.readObject(this, "plan", plan);
        }
        return this.plan;
    }

    private FieldHandler fieldHandler;

    @Override
    public void setFieldHandler(FieldHandler handler) {
        this.fieldHandler = handler;
    }

    @Override
    public FieldHandler getFieldHandler() {
        return fieldHandler;
    }
}

이 구현자체는 byte instrument에서 compile/runtime 시에 동작하는 원리와 완전히 동일하게 동작합니다. byte code instrument를 이용한 compile/runtime 시의 동작이 위의 get/set method에 대한 AOP 동작을 주입하는 것이기 때문입니다.

개인적으로는 저는 이 방법을 추천합니다. 이 방법의 경우 다음과 같은 장점이 있습니다.

  1. @OneToMany, @ManyToOne과 같은 HQL을 변경시키는 Relation을 쓰지 않아도 됩니다.
  2. LTW와 같은 성능저하가 작습니다.
  3. CTW와 같이 build시에 따로 처리할 필요가 없습니다.

reference


Posted by xyzlast Y2K


티스토리 툴바