'java'에 해당되는 글 3건

  1. 2010.11.23 [JAVA] DWR
  2. 2010.11.02 [JAVA] 이클립스 설정
  3. 2010.11.02 [JAVA] Spring2.5 + ibatis

[JAVA] DWR

개발/java 2010. 11. 23. 23:18
<!-- DWR Setting -->
<servlet>
   <servlet-name>dwr</servlet-name>
   <!-- display-name>DWR Servlet</display-name -->
   <!-- description>Direct Web Remoter Servlet</description -->
   <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
   <!-- This should NEVER be present in live -->
   <init-param>
     <param-name>debug</param-name>
     <param-value>true</param-value>
   </init-param>
   <!-- By default DWR creates application scope objects when they are first
   used. This creates them when the app-server is started -->
   <init-param>
     <param-name>initApplicationScopeCreatorsAtStartup</param-name>
     <param-value>true</param-value>
   </init-param>
   <!-- WARNING: allowing JSON-RPC connections bypasses much of the security
   protection that DWR gives you. Take this out if security is important -->
   <init-param>
     <param-name>jsonRpcEnabled</param-name>
     <param-value>true</param-value>
   </init-param>
   <!-- WARNING: allowing JSONP connections bypasses much of the security
   protection that DWR gives you. Take this out if security is important -->
   <init-param>
     <param-name>jsonpEnabled</param-name>
     <param-value>true</param-value>
   </init-param>
   <!-- data: URLs are good for small images, but are slower, and could OOM for
   larger images. Leave this out (or keep 'false') for anything but small images -->
   <init-param>
     <param-name>preferDataUrlSchema</param-name>
     <param-value>false</param-value>
   </init-param>
   <!-- This enables full streaming mode. It's probably better to leave this
   out if you are running across the Internet -->
   <init-param>
     <param-name>maxWaitAfterWrite</param-name>
     <param-value>-1</param-value>
   </init-param>
   <!--
   For more information on these parameters, see:
   - http://getahead.org/dwr/server/servlet
   - http://getahead.org/dwr/reverse-ajax/configuration
   -->
   <load-on-startup>1</load-on-startup>
  </servlet>
 
<servlet-mapping>
<servlet-name>dwr</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
Posted by 나랑살자
,

vi /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini

showsplash org.eclipse.platform
--launcher.XXMaxPermSize 512m
-vmargs
-Xms40m
-Xmx512m
-XX:MaxPermSize=512m
-Xms40m
-Xmx512m

Posted by 나랑살자
,

12.5. iBATIS SQL Maps

The iBATIS support in the Spring Framework much resembles the JDBC / Hibernate support in that it supports the same template style programming and just as with JDBC or Hibernate, the iBATIS support works with Spring's exception hierarchy and let's you enjoy the all IoC features Spring has.

Transaction management can be handled through Spring's standard facilities. There are no special transaction strategies for iBATIS, as there is no special transactional resource involved other than a JDBCConnection. Hence, Spring's standard JDBC DataSourceTransactionManager orJtaTransactionManager are perfectly sufficient.

Note

Spring does actually support both iBatis 1.x and 2.x. However, only support for iBatis 2.x is actually shipped with the core Spring distribution. The iBatis 1.x support classes were moved to the Spring Modules project as of Spring 2.0, and you are directed there for documentation.

12.5.1. Setting up the SqlMapClient

If we want to map the previous Account class with iBATIS 2.x we need to create the following SQL map'Account.xml':

<sqlMap namespace="Account">

 

  <resultMap id="result" class="examples.Account">

    <result property="name" column="NAME" columnIndex="1"/>

    <result property="email" column="EMAIL" columnIndex="2"/>

  </resultMap>

 

  <select id="getAccountByEmail" resultMap="result">

    select ACCOUNT.NAME, ACCOUNT.EMAIL

    from ACCOUNT

    where ACCOUNT.EMAIL = #value#

  </select>

 

  <insert id="insertAccount">

    insert into ACCOUNT (NAME, EMAIL) values (#name#, #email#)

  </insert>

 

</sqlMap>

The configuration file for iBATIS 2 looks like this:

<sqlMapConfig>

 

  <sqlMap resource="example/Account.xml"/>

 

</sqlMapConfig>

Remember that iBATIS loads resources from the class path, so be sure to add the 'Account.xml' file to the class path.

We can use the SqlMapClientFactoryBean in the Spring container. Note that with iBATIS SQL Maps 2.x, the JDBC DataSource is usually specified on the SqlMapClientFactoryBean, which enables lazy loading.

<beans>

 

  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

    <property name="driverClassName" value="${jdbc.driverClassName}"/>

    <property name="url" value="${jdbc.url}"/>

    <property name="username" value="${jdbc.username}"/>

    <property name="password" value="${jdbc.password}"/>

  </bean>

 

  <bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">

    <property name="configLocation" value="WEB-INF/sqlmap-config.xml"/>

    <property name="dataSource" ref="dataSource"/>

  </bean>

 

</beans>

12.5.2. Using SqlMapClientTemplate and SqlMapClientDaoSupport

The SqlMapClientDaoSupport class offers a supporting class similar to the SqlMapDaoSupport. We extend it to implement our DAO:

public class SqlMapAccountDao extends SqlMapClientDaoSupport implements AccountDao {

 

    public Account getAccount(String email) throws DataAccessException {

        return (Account) getSqlMapClientTemplate().queryForObject("getAccountByEmail", email);

    }

 

    public void insertAccount(Account account) throws DataAccessException {

        getSqlMapClientTemplate().update("insertAccount", account);

    }

}

In the DAO, we use the pre-configured SqlMapClientTemplate to execute the queries, after setting up the SqlMapAccountDao in the application context and wiring it with our SqlMapClient instance:

<beans>

 

  <bean id="accountDao" class="example.SqlMapAccountDao">

    <property name="sqlMapClient" ref="sqlMapClient"/>

  </bean>

 

</beans>

Note that a SqlMapTemplate instance could also be created manually, passing in the SqlMapClient as constructor argument. The SqlMapClientDaoSupport base class simply pre-initializes aSqlMapClientTemplate instance for us.

The SqlMapClientTemplate also offers a generic execute method, taking a customSqlMapClientCallback implementation as argument. This can, for example, be used for batching:

public class SqlMapAccountDao extends SqlMapClientDaoSupport implements AccountDao {

 

    public void insertAccount(Account account) throws DataAccessException {

        getSqlMapClientTemplate().execute(new SqlMapClientCallback() {

            public Object doInSqlMapClient(SqlMapExecutor executor) throws SQLException {

                executor.startBatch();

                executor.update("insertAccount", account);

                executor.update("insertAddress", account.getAddress());

                executor.executeBatch();

            }

        });

    }

}

In general, any combination of operations offered by the native SqlMapExecutor API can be used in such a callback. Any SQLException thrown will automatically get converted to Spring's genericDataAccessException hierarchy.

12.5.3. Implementing DAOs based on plain iBATIS API

DAOs can also be written against plain iBATIS API, without any Spring dependencies, directly using an injected SqlMapClient. A corresponding DAO implementation looks like as follows:

public class SqlMapAccountDao implements AccountDao {

       

    private SqlMapClient sqlMapClient;

   

    public void setSqlMapClient(SqlMapClient sqlMapClient) {

        this.sqlMapClient = sqlMapClient;

    }

 

    public Account getAccount(String email) {

        try {

            return (Account) this.sqlMapClient.queryForObject("getAccountByEmail", email);

        }

        catch (SQLException ex) {

            throw new MyDaoException(ex);

        }

    }

 

    public void insertAccount(Account account) throws DataAccessException {

        try {

            this.sqlMapClient.update("insertAccount", account);

        }

        catch (SQLException ex) {

            throw new MyDaoException(ex);

        }

    }

}

In such a scenario, the SQLException thrown by the iBATIS API needs to be handled in a custom fashion: usually, wrapping it in your own application-specific DAO exception. Wiring in the application context would still look like before, due to the fact that the plain iBATIS-based DAO still follows the Dependency Injection pattern:

<beans>

 

  <bean id="accountDao" class="example.SqlMapAccountDao">

    <property name="sqlMapClient" ref="sqlMapClient"/>

  </bean>

 

</beans>

Posted by 나랑살자
,