• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

刚刚把做完的项目从JDK5上移植到JDK1.4,事后整理一下,常常记记备忘录是个灰常好的习惯滴.呵.

Struts2.0默认的平台需求是:

• Servlet API 2.4
• JSP API 2.0
• Java 5

但是因为一些原因,我们必须使用JDK1.4来编译,所以只能应用Struts提供的J4,来进行一下移植了,说实话,还是挺好的,只需要简单的操作,便可以把JDK更改为1.4的了.原本我以为弄不好还得重新写代码呢,结果才发现,嗯,如此的简单.

好了,不废话了.

要想应用JDK1.4,使用的主要的是Struts2.0的发行包里提供的J4目录中的Retrotranslator.利用它可以将原JDK5的包转化成JDK1.4的.关于Retrotranstator的介绍,可以查看http://retrotranslator.sourceforge.net/,里面写的很详细.

在J4目录中,已经将Struts2.0基本的两个Jar文件转好了,分别是struts2-core-j4-2.0.9.jar和xwork-j4-2.0.4.jar.如果你的程序中还用到的其他的Jar包,可以通过脚本把Jar包转成J4版本的.我们的程序中用到了spring和sitemesh两个Plugin的Jar包,所以需要将这两个包转成J4的.

java -jar retrotranslator-transformer-1.2.2.jar -advanced -srcjar ../lib/struts2-sitemesh-plugin-2.0.9.jar -destjar struts2-sitemesh-plugin-j4-2.0.9.jar
java -jar retrotranslator-transformer-1.2.2.jar -advanced -srcjar ../lib/struts2-spring-plugin-2.0.9.jar -destjar struts2-spring-plugin-j4-2.0.9.jar

可以将它们写到一个Bat文件中,如果你用的是Windows的系统的话,使用Linux的用户可以存成sh文件.

执行Bat文件,将生成两个新的J4版本的包,struts2-sitemesh-plugin-j4-2.0.9.jar和struts2-spring-plugin-j4-2.0.9.jar.

将这四个Jar包放到WEB-INF/lib中,再将J4目录中的retrotranslator-transformer-1.2.2.jar, backport-util-concurrent-3.0.jar和retrotranslator-runtime-1.2.2.jar一起放到WEB-INF/lib下.

之后再把自己写的程序中所使用的JDK5的特性去掉,嗯,我们只用了Annotations等几个特性,所以改起来还是相当容易了.

至此,你的程序应该就可以在JDK1.4上运行了.

我使用的环境Tomcat5.0+jdk1.4.运行我修改后的程序,测试通过......

Over

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

JTA在处理分布式事务闻名已久，但是一直没有真正去玩过JTA，趁着这几天空闲，心血来潮想玩一把。经过一番周折，通过weblogic的JTA，并结合spring提供的简单配置，跑通了自己的第一个JTA事务。
记录一下，留个纪念，如果有朋友在实验中遇到同样的问题，也可以略加参考，希望对你有点帮助。

Step by Step
1. 安装Sqlserver 2000 + sp4

2. 在www.bea.com下载weblogic express 8.1。

3. 安装weblogic，并创建自己的domain实例，然后启动domain实例。

4. 浏览http://localhost:7001/console，如果出现管理页面，则安装已成功。

5. 进入管理页面后，选择Services Configurations - JDBC - Connection Pools，配置连接池。
选择创建一个新的连接池，Database Type选择MS Sql Server，然后在Database Driver中选择*BEA's MS Sql Server Driver (Type 4 XA)。注意，要真正使用JTA事务，必须选择带XA的驱动，以支持JTA事务的两阶段提交。
然后Continue，输入HOST，数据库名称，用户名和密码，Continue

6. 进入下一个页面后，测试一下是否配置正确，Test Driver Configuration，此时对于第一次使用JTA的朋友来说，一般是测试通不过的，weblogic可能会给出一些原因，比如：sp_xxx存储过程找不到、DTC是否已经开启啊、xa_open (0) returns -3之类的错误，解决办法如下：
sp_xxx存储过程找不到 - 在需要JTA事务的master数据库中运行%BEA_HOME%/weblogic81/server/lib/instjdbc.sql，并且复制sqljdbc.dll到%SQLSERVER_HOME%/MSSQL/Binn目录下。
DTC是否已经开启 - 在服务中，启动 Distributed Transaction Coordinator。
xa_open (0) returns -3 - 数据库用户名必须是系统管理员，如果还是不行，则修改注册表HKLM\Software\Microsoft\MSDTC\Security的XaTransactions，如果该值为0，说明现在不支持分布式事务，我们把它改成1，然后重起Sqlserver和DTC。
以上问题都解决了，如果看到测试通过，恭喜您，主要问题都解决了。

5. 配置Datasource，写好jndi名字，选择刚才配好的连接池。可以尝试配置多个不同的服务器和数据库，然后再程序里测试JTA。

6. 配置Spring

7. 部署war应用，测试得到，使用commonManagerTarget是不带分布式事务的，使用commonManager是带分布式事务的，成功！

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

I’ve recently switched from using JUnit 3.x to JUnit 4 for most new unit tests I write. One area that causes trouble is the use of JUnit 3.x based test base classes. Spring has a tree of helper classes based on junit.framework.TestCase that make writing tests that use an ApplicationContext, dependency injection or transactions easier. These base classes can autowire your test so that your member variables are initialized and ready to go, pointing to beans managed by Spring.

I wanted the functionality provided by these base classes but wanted to continue to write tests in the JUnit4 style. The two best features of JUnit 4 are the @BeforeClass/@AfterClass annotations and the ability to have multiple setUp and tearDown methods using @Before and @After. Switching back to JUnit 3 just to use the base class seemed unfortunate.

My first attempt was to extend my JUnit 4 test from Spring’s class, AbstractDependencyInjectionSpringContextTests. When JUnit runs, it inspects your class through reflection and decides if it’s a JUnit 3 or 4 class. It sees that since Spring’s class derives from junit.framework.TestCase and so runs it as a JUnit 3 test using org.junit.internal.runners.OldTestClassRunner.

You can circumvent JUnit’s decision about this test and force it to be run as a JUnit 4 test instead using the annotation RunWith((TestClassRunner.class). This forces JUnit to use the new test runner (TestClassRunner) even though the class derives from TestCase. I created a class called SpringManagedTests that derives from AbstractDependencyInjectionSpringContextTests and is annotated with RunWith. (My tests will extend SpringManagedTests).

Next, JUnit 4 only cares about annotations and won’t run the old setUp and tearDown methods defined by the Spring classes. To get around this, add methods with Before and After annotations to call setUp and tearDown.

@Before final public void callSetup() throws Exception {
  super.setUp();
}

@After public void callTearDown() throws Exception {
  super.tearDown();
}

All features of the base class are now available, and JUnit 4 annotated test methods run as you would expect. The final test base class is below. To use it, derive your test from SpringManagedTests and read the docs on AbstractDependencyInjectionSpringContextTests for information on having Spring wire members of your class. In my case I use field injection – I have member variables declared as protected with the field name matching the bean name. When the test runs the field are populated.

This technique could be used for other JUnit 3 based test frameworks as well. It’s not as clean as having a pure JUnit 4 implementation but works well until that happens.

import org.junit.After;
import org.junit.Before;
import org.junit.internal.runners.TestClassRunner;
import org.junit.runner.RunWith;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;

/**
 * A base class for tests that load a spring application context
 * and use dependency injection to populate fields in the test class.
 * Unlike AbstractDependencyInjectionSpringContextTests, this
 * class can be used as a base class for JUnit 4 tests.
 * @author dyoung
 */
// RunWith is required to force what would otherwise look like a JUnit 3.x test
// to run with the JUnit 4 test runner.
@RunWith(TestClassRunner.class)
public class SpringManagedTests extends AbstractDependencyInjectionSpringContextTests {

    // pass through to the junit 3 calls, which are not annotated
    @Before final public void callSetup() throws Exception {
        super.setUp();
    }

    @After public void callTearDown() throws Exception {
        super.tearDown();
    }
}




From : http://dmy999.com/article/21/adapting-a-springs-junit-3x-base-classes-to-junit-4

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

Introduction

Most enterprise applications rely on the database as the persistence mechanism. Integration tests for these applications require data in the database to run correctly. For integration tests to be repeatable, the tests should carry the test data they need with them and insert it before running the tests and delete it after the tests, since the data in the database can change with time.

DBUnit is a tool which provides this functionality.

This article will look at configuring integration tests using Spring and DBUnit so that test data is inserted into the database before every test. This article also looks at a utility to export/import test data in the database using DBunit.

It is assumed that the reader is familiar with the following concepts and tools:

• Unit testing and integration testing
• Spring 2 and JUnit 3.8
• XML
• General database concepts

Unit tests should run in isolation without relying on any other external dependency. Business layer classes should also be unit tested in isolation without relying on the database.

Tests which rely on another dependency (e.g. database) are integration tests. Testing Data Access Objects (DAOs) is integration testing as it tests the integration between database and the DAOs. Business layer classes which use DAOs also indirectly depend on the database.

This article deals with integration testing of DAOs and integration testing of business layer classes which use DAOs to read/write data.

See further reading links at the end for an interesting discussion of the unit tests, integration testing and DBUnit.

The test data could be managed manually in several ways:

The ideal approach is to:

• Export a subset of the data in the database to a flat file (XML preferred)
• Developers use this flat file as template and change the values some of the interesting values they want to change. This flat file now has the test data
• Before the integration tests run, the data in the flat file is inserted into the database
• After the integration tests run, the data is deleted from the database

DBunit

This is an offline task which is done before integration tests are written. The steps involved in exporting a subset of data in the database to XML are:

• Connect to the database
• Specify the SQL to run to retrieve the data
• Specify the location of the flat file(XML)
• Export the data

This is shown in the code below:

import java.io.FileOutputStream;
import java.sql.Connection;
import java.sql.DriverManager;
import org.dbunit.database.DatabaseConnection;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.database.QueryDataSet;
import org.dbunit.dataset.xml.FlatXmlWriter;

public class TestDBUnit
{
	public static void main(String[] args)
		throws Exception
	{
		//Connect to the database
		DriverManager.registerDriver(new net.sourceforge.jtds.jdbc.Driver());
		Connection conn = DriverManager.getConnection("URL_TO_CONNECT", "username", "password");

		IDatabaseConnection connection = new DatabaseConnection( conn );

		QueryDataSet partialDataSet = new QueryDataSet(connection);
		//Specify the SQL to run to retrieve the data
		partialDataSet.addTable("person", " SELECT * FROM person WHERE name='Test name' ");
		partialDataSet.addTable("address", " SELECT * FROM address WHERE addressid=1 ");

		//Specify the location of the flat file(XML)
		FlatXmlWriter datasetWriter = new FlatXmlWriter(new FileOutputStream("temp.xml"));

		//Export the data
	    datasetWriter.write( partialDataSet );
	}
}

The data in the 2 tables is shown below:

Table ‘Person’

The SQL to create this table on Microsoft SQL Server is ‘ create table person (personid int not null primary key identity , name varchar (20 ), dob datetime )’

Table ‘Address’

The SQL to create this table on Microsoft SQL Server is ‘ create table address (addressid int not null primary key identity , address varchar (20 ))‘.

The XML file produced by running the program above is shown below:

The developer can now edit the file or add new rows. This is now the test data and is ready to be inserted by DBUnit when the tests are run.

The export of data in the database to XML is an offline process which is done before (or during) writing integration tests.

The import of data from XML to database is done when the integration tests are run.

For a JUnit test, the test data is inserted in the ‘setUp’ method and removed in the ‘tearDown’ method as shown below:

public class DBUnitTests extends TestCase
{
	public void setUp()
	{
		System.out.println("In setup");
		Connection conn = null;
		try
		{
			DriverManager.registerDriver(new net.sourceforge.jtds.jdbc.Driver());
			conn = DriverManager.getConnection("URL", "username", "password");
			IDatabaseConnection connection = new DatabaseConnection( conn );
			DatabaseOperation.INSERT.execute(connection, new FlatXmlDataSet(new FileInputStream("temp.xml")));
			conn.close();
		}
		catch(Exception exc)
		{
			exc.printStackTrace();
		}
	}

	public void tearDown()
	{
		System.out.println("In tearDown");
		Connection conn = null;
		try
		{
			DriverManager.registerDriver(new net.sourceforge.jtds.jdbc.Driver());
			conn = DriverManager.getConnection("URL", "username", "password");
			IDatabaseConnection connection = new DatabaseConnection( conn );
		    DatabaseOperation.DELETE.execute(connection, new FlatXmlDataSet(new FileInputStream("temp.xml")));
		    conn.close();
		}
		catch(Exception exc)
		{
			exc.printStackTrace();
		}
	}

	public void testDBUnitImport1()
	{
		System.out.println("In testDBUnitImport1");
		//Run the test
	}

	public void testDBUnitImport2()
	{
		System.out.println("In testDBUnitImport2");
		//Run the test
	}
}

Note: The IdentityInsertOperation.INSERT operation is required for MS-SQL Server instead of DatabaseOperation.INSERT.

Enhance Junit tests using Spring and DBUnit

The code shown in section above has data access logic mixed in the integration test. This is common to all tests and can be moved to a super class. We also would need some mechanism to make it easier for integration tests to access DAO and service layer classes.

Spring provides support for both of these.

Spring provides ‘ AbstractTransactionalDataSourceSpringContextTests’ class which extends JUnit TestCase class. This class has ‘ onSetUpInTransaction’ and ‘ onTearDownInTransaction’ methods which run inside a transaction and can be used to insert test data. We can extend this class and override these 2 methods to insert and delete test data.

This is shown below:

public class AbstractTransactionalHibernateTests extends AbstractTransactionalDataSourceSpringContextTests
{
	private static String TEST_DATA_FILE = "dbunit-test-data.xml";

	protected void onSetUpInTransaction()
		throws Exception
	{
		logger.info("*** Inserting test data ***");
		//Use spring to get the datasource
		DataSource ds = this.jdbcTemplate.getDataSource();
		Connection conn = ds.getConnection();
		try
		{
			IDatabaseConnection connection = new DatabaseConnection( conn );
			DatabaseOperation.INSERT.execute(connection, new FlatXmlDataSet(new FileInputStream(TEST_DATA_FILE)));
		}
		finally
		{
			DataSourceUtils.releaseConnection(conn, ds);
			logger.info("*** Finished inserting test data ***");
		}
	}

	protected void onTearDownInTransaction()
		throws Exception
	{
		//Commit or rollback the transaction
		endTransaction();

		//Delete the data
		DataSource ds = this.jdbcTemplate.getDataSource();
		Connection conn = ds.getConnection();
		try
		{
			IDatabaseConnection connection = new DatabaseConnection( conn );
		    DatabaseOperation.DELETE.execute(connection, new FlatXmlDataSet(new FileInputStream(TEST_DATA_FILE)));
		}
		finally
		{
			DataSourceUtils.releaseConnection(conn, ds);
			logger.info("*** Finished removing test data ***");
		}
	}
}

Note:

• The test data is in file ‘dbunit-test-data.xml’ for the example above
• This class relies on spring to setup database connection
• The IdentityInsertOperation.INSERT is required for MS-SQL Server instead of DatabaseOperation.INSERT

The Spring provided class ‘ AbstractTransactionalDataSourceSpringContextTests’ extends JUnit ‘TestCase’ class. The developer writes integration tests by extending ‘ AbstractTransactionalDataSourceSpringContextTests’ class. All the features provided by JUnit are available to him.

If the integration tests extend the Spring-provided ‘ AbstractTransactionalDataSourceSpringContextTests’ class, then any Spring-managed beans defined in the integration tests are injected into the integration tests.

Here is a class which extends ‘ AbstractTransactionalDataSourceSpringContextTests’. We have overridden ‘ protected String[] getConfigLocations()’ to specify the location of Spring config files. For integration tests which extend ‘ AbstractTransactionalDataSourceSpringContextTests’ spring will inject Spring managed bean defined in the config files into the integration test. This class is shown below:

public class AbstractTransactionalHibernateTests extends AbstractTransactionalDataSourceSpringContextTests
{
    protected String[] getConfigLocations()
    {
        return new String[] {"classpath: springConfig.xml�};
    }
}

Sample Spring config file (springconfig.xml) is shown below:

An integration test is shown below:

public class TestDaoTests extends AbstractTransactionalHibernateTests
{
	private TestDao testDao = null;

	public void testGetUsingId()
	{
		//do something
	}

//Called by spring to inject the testDao
	public void setTestDao(TestDao testDao)
	{
		this.testDao = testDao;
	}
}

Summing up implementation details

A quick summary of what is discussed in the previous sections is shown below:

• Use DBUnit to export data from the database. This is done offline before or during writing integration tests. The XML file holds the test data and is stored in version control system along with source code. Developers use this as a template and modify this file as required to setup their test data.
• Write your own class ‘ AbstractTransactionalHibernateTests’ which extends Spring ‘ AbstractTransactionalDataSourceSpringContextTests’. Override ‘ onSetUpInTransaction’ and ‘ onTearDownInTransaction ’ to insert and delete test data held in the XML file. These 2 methods run within the context of a transaction. Also override ‘ protected String[] getConfigLocations()’ to specify the location of Spring config file
• Integration tests extend ‘ AbstractTransactionalHibernateTests’ class which we developed. Any Spring managed beans(DAOs or business layer classes) defined in the spring config are auto injected into the integration tests if there is a setter present for the bean.

Advantages and disadvantages of using Spring and DBUnit

• Simple, elegant and easy to implement.
• Test data is inserted during the test and removed after the test. So test data is always in a known state for every test and changes to test data when running a test won’t affect any other test.
• Dependencies injected automatically by Spring if they are defined in the Spring configuration file.
• Can be used for integration testing of DAOs and business layer classes
• Integration tests written by developers do not have to deal with inserting and deleting data. Test data is available to them at start of the test
• DBUnit provides facility to export subset of data in the database to XML. This is used as a template and developers can modify this XML file to setup their test data.

• Test data is inserted before each test. This is inefficient in some cases where the integration tests do not change the test data. It should be inserted once at the start of running the test suite and deleted once the test suite completes. This should be easier with Junit 4 and TestNG but is more difficult with Junit 3.8

Other tools

JUnit 4 introduces a more sophisticated JUnit unit test lifecycle. Any method in a POJO class can be marked as a JUnit test case method. Any method can be marked as a special method to run it once for the whole test suite (class scoped setup() using @BeforeClass annotation – no equivalent method in Junit 3.8), or for the test case(using @Before) or for the test methods(using @Test).

However the annotations used in Junit4 interfere with spring dependency injection and Spring cannot be used with Junit4.

The Gienah project ( http://code.google.com/p/gienah-testing/ ) provides a workaround but has not been tried by the author.

Also see another article at http://dmy999.com/article/21/adapting-a-springs-junit-3x-base-classes-to-junit-4 which deals with using Junit 4 and Spring.

TestNG provides sophisticated features such as parallel text execution, test classes as POJOs and annotations.

DBUnit should work just as well with TestNG. TestNG uses annotations in POJOs. Any method can be used as a test method ( by annotating it with @Test). TestNG gives the developer choice of inserting test data once for each test(using @BeforeMethod and @AfterMethod) or before each test case (using @BeforeClass and @AfterClass) or once per text execution (using @BeforeSuite and @AfterSuite).

See further reading section at the end for a ServerSide article on running Junit 3 tests in TestNG

Although the author has not tested it, Spring seems to work with TestNG annotations. Please see link in further reading section

Other resources required for integration tests

Integration tests could require other test data e.g. some service layer classes might be involved with processing of excel or csv files. On production system, binary files can be uploaded using a browser and processed by the service layer classes as byte arrays.

Binary files representing test data can be stored in version control system along with the test data. The disadvantage of this approach is this takes up space and they don’t belong in version control systems.

They can be stored in a file server and retrieved using FTP. The Apache commons-net library provides a FTP client which can be incorporated into a java application to retrieve a file from an FTP server. Apache commons-net library provides facility to read data in files on a FTP server into a byte array.

Conclusion

Unit testing is testing code in isolation without relying on any dependencies. Integration testing typically depends on presence of test data in the database.

Test data can be managed using DBUnit. Spring can be used with DBUnit to ensure test data is inserted into the database before every test and deleted after the test.

DBUnit also provides a facility to export a subset of data in the database to an XML flat file. This file is used by DBUnit to insert data before running each test.

JUnit 4 and TestNG provide a more sophisticated lifecycle. Test data can be inserted once at the start and deleted at the end. This makes running tests more efficient and is suitable for cases where the integration tests do not change the test data.

From : http://www.theserverside.com/tt/articles/article.tss?l=ManageTestDataSpringandDBunit

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

详见附件

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师