SAP Human Resources (HR) SIM Files [Closed as links are Dead]

SIMs Can Only Be Viewed Using SAP iTutor Software!

ERP – SAP Human Resources (HR) SIM Files

Balanced Scorecard
Benefits: Domestic Partner Handling As Of R/3 Enterprise
Benefits: Enrollment Employee Self-Service In SAP EP 5.0
Change Employee Form Of Address
Employee Turnover Management
Form Of Address
Human Resources Executive
Objective Setting And Appraisals
Organization Structure
Time Management: Management Of Family And Medical Leave
Time Management: Message Processing In The Time Managers Workplace
Time Management: Time Managers Workplace
Web Cockpit Department Manager
Web Cockpit Human Resource Analyst (With Navigation)
Web Cockpit With Selection

Ant within Eclipse: switching JDKs and finding tools.jar – is not on the classpath.

I've been doing quite a lot of work creating new Ant build processes and grokking Eclipse (installing and reinstalling on different machines), and this is a problem that keeps recurring. This morning I cleaned up vast amounts of garbage on my main Windows machine, garbage left over from old J2SDK installs (I had FOUR–when will Sun fix the install problem?) and I reinstalled JDK 1.4.2_03 and then tried running everything again within Eclipse (v3.0 M7). Needless to say, Ant was running fine before, after I had pointed to tools.jar but now that I had changed JDKs it wasn't guaranteed that it would run–and it didn't. While it is possible that this is so well known that people do it without thinking, it certainly isn't clearly documented, and it's a situation that people will probably find regularly doing a clean install of Eclipse and the JDK on a machine, or when upgrading JDKs after the settings have been done long ago–and forgotten. 🙂

First, the situation. On restart, Eclipse correctly detected the new JRE (clearly from the registry entries created by the JDK/JRE install) to the one the JSDK installs in C:\Program Files\Java\… but it's better to change the pointer to the JRE within the JDK IMO. Even then, Ant doesn't work. The error message you get is for Ant:

[javac] BUILD FAILED: [build file location here]
Unable to find a javac compiler; is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Of course, JAVA_HOME is pointing to the right location, in both the OS environment and within Eclipse (This variable can be set within Eclipse through Window > Preferences > Java > Classpath Variables).

So how to fix the Ant build problem?

I found various solutions searching, for example running Eclipse with "eclipse -vm [JDKPATH]\bin" but that didn't quite satisfy me (I wanted something that could be configured within the environment). Other solutions to the problem where even more esoteric.

The best solution I've found (after a little bit of digging through Eclipse's options) is to edit Ant's runtime properties. Go to Window > Preferences > Ant > Runtime. Choose the Classpath tab. Select the Global Properties node in the tree and click Add External JARs. Select tools.jar from your JDK directory (e.g., j2sdk1.4.2_03\lib\tools.jar). Click Apply and OK, and you should be on your way. Not too hard when you know what to do. Now if this could only be done automatically by Eclipse on install…

SEVERE: Error reading tld listeners java.lang.NullPointerException

SEVERE: Error reading tld listeners java.lang.NullPointerException, the error appears to come from log4j.

I came across this error when reloading a context in Tomcat 5.5.23.

The solution appeared to be to remove commons-logging from WEB-INF/lib of my web app. I’d only added it because Jakarta’s HttpClient insisted on it.

Once again, when in doubt, blame commons-logging.

Testing Your Controllers

One of the reasons for setting up this page was I wanted to write something somewhere about the new testing techniques I've been using over the past few days. I'm working on a Java web application, using a fairly standard MVC structure. Working on an XP team, I've always felt a little uneasy about not having a good way to build controllers test first. Typically in past projects I've tested controllers indirectly by using tools like HttpUnit to interact with the web front end, and exercise the view and controller components together. This approach has a number of drawbacks. In the case of a failure, it is difficult to determine whether the bug is in the view or the controller (or even the model). It is also necessary to develop the view and the controller in tandem, as one cannot be tested without the other. On my current project, we are using Spring to provide the MVC framework. This allows us to make use of some of the other facilities provided by Spring to enhance our testing. Spring provides support for unit testing controllers independently. This has a number of advantages:

  • We can develop controllers test-first.
  • Breakages in the unit tests point explicitly to problems in the controller, rather than problems in one of the combination of Model, View and Controller.
  • We can run the unit test outside of the container, meaning that we do not have to deploy within each code/test cycle.
  • The tests themselves run faster.
  • We can develop and test all of our controller code before developing any of the view components.
  • We can develop and test all of our controller code before creating the Spring application-context.xml, which makes the requirements for the contents of this file much clearer.

The difficulty we had had with unit testing controllers previously was that the methods in their public interface tended to take an HttpServletRequest and HttpServletResponse as parameters, and operate on these. When running a unit test, such objects are not normally to hand, and are difficult to construct. Spring aids this situation by providing the classes MockHttpServletRequest and MockHttpServletResponse in spring-mock.jar (note that these classes are not part of the core Spring jar). Here is an example of how we can use them in a JUnit test case.

import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.mock.web.MockHttpServletResponse;
import org.springframework.web.servlet.ModelAndView;

public MyControllerTest extends TestCase {

public void testGettingIndexPage() throws Exception {

MyController controller = new MyController();

MockHttpServletRequest request = new MockHttpServletRequest();
MockHttpServletResponse response = new MockHttpServletRequest();


ModelAndView modelAndView = controller.handleRequest(request, response);

assertEquals("Should get index page", modelAndView.getViewName(), "index.jsp");

This test shows that we intend our controller to respond to requests on the base url to display index.jsp. By writing the test first, we can see what we need to implement in our controller. To make this test pass requires only a very simple controller (which will be a subclass of one of the Spring MVC controllers).

import org.springframework.web.servlet.mvc.AbstractController;

public class MyController extends AbstractController {

private String indexView;

public void setIndexView(String viewName) { indexView = viewName; }
public String getIndexView() { return indexView; }

public ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) {
return new ModelAndView(getIndexView());

To make things a bit more interesting, we can add a test that passes in some parameters on the request, and expects an appropriate response, for example passing in a search query and expecting a results page back. Adding to our test case, we can write:

     public void testSearching() throws Exception {          MyController controller = new MyController();         controller.setSearchResultsView("results.jsp");         MockHttpServletRequest request = new MockHttpServletRequest();         MockHttpServletResponse response = new MockHttpServletResponse();         request.setMethod("GET");          request.addParameter("query","testing");          ModelAndView modelAndView = controller.handleRequest(request, response);          assertEquals("Should get results page", modelAndView.getViewName(), "results.jsp");             }

Again the intention of the test is pretty clear (we can now see that our testcase might benefit from factoring some common setup into a setup method, but we'll leave that for now), and again, we don't need to add much to our controller to make it pass.


public class MyController extends AbstractController {

// in addition to the fields and accessors from before…
private String searchResultsView;

public void setResultsView(String viewName) { searchResultsView = viewName; }
public String getSearchResultsView() { return searchResultsView; }

public ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) {

String query = request.getParameter("query");
if ( query != null ) {
// perform the search
return new ModelAndView(getSearchResultsView());
} else {
return new ModelAndView(getIndexView());

This shows a couple of very simple iterations of writing tests and implementation for a controller, you can go a lot further, making both the tests and the implementation more sophisticated. The main point is that we have built and tested the controller in a way that allows quick iteration, promotes clarity and good test coverage, and does not require a view component to be written to do so.

Unit Testing with Junit, Spring and Hibernate – Part 2

This is a continuation from my previous post on Spring and MockStrutsTestCase and focus on testing Hibernate DAO’s. As I mentioned in the previous post, Spring framework provides a nifty base class (AbstractTransactionalDataSourceSpringContextTests) that provides automatic transaction rollback, exposing a JDBC template to interact with the DB and auto wiring of beans.

Lets take a simple DAO class that save a User object to the database:

public class UserDaoImpl extends HibernateDaoSupport implements UserDao {
  public void save(User user) {

Now in order to test this you would write a test class as below extending from AbstractTransactionalDataSourceSpringContextTests class.

public class UserDaoTest extends AbstractTransactionalDataSourceSpringContextTests {
  private UserDao userDao;
  private SessionFactory sessionFactory = null;

  protected String[] getConfigLocations() {
      return new String[]{"test-spring-config.xml"};

   * Spring will automatically inject UserDao object on startup
   * @param userDao
  public void setUserDao(UserDao userDao) {
      this.userDao = userDao;

   * Spring will automatically inject the Hibernate session factory on startup
   * @param sessionFactory
  public void setSessionFactory(SessionFactory sessionFactory) {
      this.sessionFactory = sessionFactory;

   * Test the save method
  public void testSave(){
      String query = "select count(*) from user where first_name = 'Firstname'";
      int count = jdbcTemplate.queryForInt(query);
      assertEquals("A user already exists in the DB", 0, count);

      User user = new User();


      // flush the session so we can get the record using JDBC template
      SessionFactoryUtils.getSession(sessionFactory, false).flush();

      count = jdbcTemplate.queryForInt(query);
      assertEquals("User was not found in the DB", 1, count);

The test class has to implement the protected String[] getConfigLocations() method from the base class and return a String array of Spring config files which will be used to initialize the Spring context.

UserDao and SessionFactory properties are defined with the setter methods and the base class will take care of injecting them automatically from the Spring context. Auto wiring will not work if there are multiple objects implementing the same interface. In such a case you can remove the setter method and retrieve the object using the exposed applicationContext as below.

   * Overridden method from base class which gets called automatically
  protected void onSetUpBeforeTransaction() throws Exception {
      userDao = (UserDao) applicationContext.getBean("userDao");

The base class also exposes a JDBC template object (jdbcTemplate) that can be used to query data or setup test data in the database. Note that you need to have a data source and a transaction manager defined in your Spring config in order to use the AbstractTransactionalDataSourceSpringContextTests base class. The data source defined in the config file will be bound to the exposed JDBC template.

In the testSave method first we verify there is no record in the User table where first name equals to ‘Firstname’ using the jdbc template object. Then we call the save method on the UserDao passing it a User object.

Now we simple verify there is a record in the table where first name equals to ‘Firstname’. Before running the query we flush the current Hibernate session to make sure jdbcTemplate can see the newly added record.

Thats it and when the testSave method exits the current transaction will be rolled back and the record inserted to the User table will not be saved. This is great as your test database will always be at a know state at the start and end of a test method.

The spring config file will like below (test-spring-config.xml) :


    <bean name="userDao" class="com.dao.UserDaoImpl">
       <property name="sessionFactory">
           <ref bean="sessionFactory"/>

    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
       <property name="dataSource">
           <ref bean="dataSource"/>
       <property name="mappingResources">
       <property name="hibernateProperties">
               <prop key="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</prop>
               <prop key="hibernate.dialect">org.hibernate.dialect.OracleDialect</prop>

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
       <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
       <property name="url" value="jdbc:oracle:thin:@localhost:1521:ORCL" />
       <property name="username" value="test" />
       <property name="password" value="test" />

    <bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
       <property name="sessionFactory"><ref local="sessionFactory"/></property>


Achieve Automatic Transaction Rollback with MockStrutsTestCase and Spring

Spring provides a convenience base class (AbstractTransactionalDataSourceSpringContextTests which extends the TestCase class from Junit) to automatically rollback any updates made to the database at the end of a test method. This works great when integration testing Service and DAO beans but it wont help when integration testing the Struts layer with MockStrutsTestCase.

Spring does not provide a class such as AbstractTransactionalDataSourceSpringContextTests that extends from the MockStrutsTestCase. This might be due to practical issues with the way Spring context initialization works when using MockStrutsTestCase. I tried achieving the transaction rollback in the same way as was done in the AbstractTransactionalDataSourceSpringContextTests class but it didn’t work out as the application code started a new transaction and commited as usual without using the transaction I started in my own subclass of MockStrutsTestCase.

Another option left for me was to go down to the Transaction Manager level and achieve the rollbacks there. The application uses Hibernate at the DAO level and it was using HibernateTransactionManager as the transaction manager implementation when running test cases . Therefore I had to write a new class extending from HibernateTransactionManager which overrides the doCommit() method. The overridden method will call doRollback() method in the super class. This would rollback the current running transaction even if the declarative transaction handling code in Spring calls doCommit on the transaction manager.

package;import org.springframework.orm.hibernate3.HibernateTransactionManager;

public class HibernateRollbackTxnManager extends HibernateTransactionManager {


  * doCommit method that calls the doRollback method of the super class.



 protected void doCommit(DefaultTransactionStatus txnStatus) {




Finally override the default transaction manager in your test spring bean configuration with the rollback only implementation.

  <bean id="txnManager" class="">

      <property name="sessionFactory"><ref local="sessionFactory"></property>


The same strategy would work with other transaction managers such as DataSourceTransactionManager too.