[Mifos-developer] Patch for moratorium module....

11 views
Skip to first unread message

Saurabh Kumar

unread,
Oct 25, 2007, 9:31:32 AM10/25/07
to mifos-d...@lists.sourceforge.net

 

Hi All,

 

We are done with the coding of moratorium module. However there are still some open issues, which are not implemented.

Once we get clarification on the open issues, we will send the updated patch. I m attaching a document with the mail, which describes the approach we have followed as well as open issues.

 

We checked out latest code from SVN but the build is getting failed because of test suite failure.

After applying the patch send by Dion, the test suite executes successfully but some other functional issues are coming, like, we are unable to create center, when we try to create meeting details for center we get following error -

javax.servlet.ServletException: Unable to find a value for "id" in object of class "org.mifos.application.meeting.util.helpers.WeekDay" using operator "."

 

Can anyone throw some light on this problem?

 

We checked out Revision >> 12167

Thanks & Regards,

Saurabh Kumar • Developer • SunGard • Offshore Services • Divyasree Chambers, Langford Road, Bangalore 560025 India
Tel +91-80-2222-0501 • Mobile +91-9886945575 • Fax +91-80-2222-0511 • www.sungard.com

 

Approach for Moratorium module.doc
PatchForMoratorium.patch

Van Mittal-Henkle

unread,
Nov 5, 2007, 2:31:03 AM11/5/07
to Developer
Hi Saurabh,
 
Could you please update to revision 12171 (or later) and confirm whether this probem has been resolved.  If the you no longer see the issue, then please resubmit your patch.
 
thanks,
--Van

From: mifos-devel...@lists.sourceforge.net [mailto:mifos-devel...@lists.sourceforge.net] On Behalf Of Saurabh Kumar
Sent: Thursday, October 25, 2007 6:32 AM
To: mifos-d...@lists.sourceforge.net
Subject: [Mifos-developer] Patch for moratorium module....

Saurabh Kumar

unread,
Nov 5, 2007, 7:46:07 AM11/5/07
to Developer

 

Hi Van,

 

I have integrated the code with revision 12171.

 

The test suite is running fine, and there are no build errors.

 

Please find the patch attached with the mail.

 

Do let me know if there are any issues.

 

Thanks & Regards,

Saurabh Kumar • Developer • SunGard • Offshore Services • Divyasree Chambers, Langford Road, Bangalore 560025 India
Tel +91-80-2222-0501 • Mobile +91-9886945575 • Fax +91-80-2222-0511 • www.sungard.com

moratorium.patch

Saurabh Kumar

unread,
Nov 8, 2007, 12:45:28 AM11/8/07
to Developer

 

Hi All,

 

We have submitted patch for loan and moratorium module.

 

I was wondering whether they have been reviewed or not, it will be great if someone could review those patches and provide us comments on the same.

 

Thoughts and suggestions are welcomed.

Aliya Walji

unread,
Nov 8, 2007, 12:52:15 AM11/8/07
to Developer

Hi Saurabh,

 

Apologies for not responding to your email earlier this week with your patch.  Van is currently on vacation (and will be for the next few weeks), so we are a little bit behind in reviewing patches.  I will check in with the team and get back to you shortly with an idea of when we think we can have the patch reviewed and provide you with feedback.

 

Thanks,

 

Aliya

Aliya Walji

unread,
Nov 8, 2007, 2:52:00 PM11/8/07
to Developer

Hi Saurabh,

 

I checked in with the team and we have a developer, Tom Bostelmann, who will be reviewing your patch.  I just want to set expectations that he has a couple other patches to review first (from Mayank and Dion for Loan Defaults and Offsetting features) in addition to his regular development work.  But, I’m sure he’ll get you a response as soon as he can J

 

Thanks for checking in with us,

 

Aliya

 

Tom Bostelmann

unread,
Nov 8, 2007, 5:59:30 PM11/8/07
to Developer
Saurabh,
I'm having some trouble applying your patch.  There is a merge conflict in:

sql/latest-schema.sql

There are also several files that already exist, so I'm not sure why your patch is trying to add them:

Failed to apply patch for file src/org/mifos/application/moratorium/business/MoratoriumBO.hbm.xml: File MoratoriumBO.hbm.xml already exists
Failed to apply patch for file src/org/mifos/application/moratorium/business/MoratoriumBO.java: File MoratoriumBO.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/business/service/MoratoriumBusinessService.java: File MoratoriumBusinessService.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/exceptions/MoratoriumException.java: File MoratoriumException.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/persistence/MoratoriumPersistence.java: File MoratoriumPersistence.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/struts/action/MoratoriumAction.java: File MoratoriumAction.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/struts/actionforms/MoratoriumActionForm.java: File MoratoriumActionForm.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/util/resources/MoratoriumConstants.java: File MoratoriumConstants.java already exists
Failed to apply patch for file src/org/mifos/application/moratorium/util/resources/MoratoriumUIResources.properties: File MoratoriumUIResources.properties already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/applyBranchMoratoriumConfirm.jsp: File applyBranchMoratoriumConfirm.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/applyMoratorium.jsp: File applyMoratorium.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/applyMoratoriumConfirm.jsp: File applyMoratoriumConfirm.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/applyMoratoriumForBranch.jsp: File applyMoratoriumForBranch.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/configureBranchMoratorium.jsp: File configureBranchMoratorium.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/configureClientMoratorium.jsp: File configureClientMoratorium.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/configureMoratorium.jsp: File configureMoratorium.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/editMoratoriums.jsp: File editMoratoriums.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/editMoratoriumsPreview.jsp: File editMoratoriumsPreview.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/moratoriumSearchResults.jsp: File moratoriumSearchResults.jsp already exists
Failed to apply patch for file src/org/mifos/doc-root/application/moratorium/jsp/viewMoratoriums.jsp: File viewMoratoriums.jsp already exists
Failed to apply patch for file test/org/mifos/application/moratorium/business/service/TestMoratoriumBusinessService.java: File TestMoratoriumBusinessService.java already exists
Failed to apply patch for file test/org/mifos/application/moratorium/business/TestMoratoriumBO.java: File TestMoratoriumBO.java already exists
Failed to apply patch for file test/org/mifos/application/moratorium/persistence/TestMoratoriumPersistence.java: File TestMoratoriumPersistence.java already exists
Failed to apply patch for file test/org/mifos/application/moratorium/struts- config.xml: File struts-config.xml already exists
Failed to apply patch for file test/org/mifos/application/moratorium/struts/action/TestMoratoriumAction.java: File TestMoratoriumAction.java already exists
Failed to apply patch for file test/org/mifos/application/moratorium/struts/actionforms/TestMoratoriumActionForm.java: File TestMoratoriumActionForm.java already exists
Failed to apply patch for file test/org/mifos/application/moratorium/util/resources/MoratoriumUIResources.properties: File MoratoriumUIResources.properties already exists
Failed to apply patch for file test/org/mifos/application/moratorium/validation.xml: File validation.xml already exists
Failed to apply patch for file test/org/mifos/application/moratorium/validator-rules.xml: File validator-rules.xml already exists

Please make these corrections and re-submit the patch.  Thanks!
-Tom



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Saurabh Kumar

unread,
Nov 12, 2007, 5:47:58 AM11/12/07
to Developer

 

Hi Tom,

 

Thanks for reviewing the patch.

 

I m sending new patch, it contains code which is integrated with revision 12183.

 

Do let me know if there are still any issues.

 

Please note that the test suite in revision 12183 is getting failed (without our code.) After integrating our code, I have checked thoroughly and there are no issues because of our code.

Moratorium Patch.patch

Aliya Walji

unread,
Nov 12, 2007, 1:46:53 PM11/12/07
to Developer

Hi Saurabh,

 

When I look at the build server, revision 2183 does not seem to have any build issues or test failures.  You may want to investigate things on your side again if you are still experiencing test failures in the latest code.

 

Aliya

Saurabh Kumar

unread,
Nov 13, 2007, 2:00:20 AM11/13/07
to Developer

 

Hi Aliya,

 

I have checked the code and I feel there might me some configuration issue with date.

 

There is some problem with setting of FiscalWeekStartDay --

 

<testcase classname="org.mifos.framework.components.configuration.business.TestConfiguration" name="testAreaOfficeConfiguration" time="0.0">

    <failure message="expected:&lt;2&gt; but was:&lt;0&gt;" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: expected:&lt;2&gt; but was:&lt;0&gt;

            at org.mifos.framework.components.configuration.business.TestConfiguration.assertForMeetingConfig(TestConfiguration.java:86)

            at org.mifos.framework.components.configuration.business.TestConfiguration.testAreaOfficeConfiguration(TestConfiguration.java:52)

</failure>

  </testcase>

 

In above failure of assertion it is trying to get FiscalWeekStartDay, whose value is 0 instead of two.

 

<testcase classname="org.mifos.application.accounts.savings.business.TestSavingsBO" name="testCalculateInterest_IntCalcFreqTenDays_minbal" time="0.888">

    <failure message="expected:&lt;Sat Apr 01 00:00:00 IST 2006&gt; but was:&lt;Mon Apr 03 00:00:00 IST 2006&gt;" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: expected:&lt;Sat Apr 01 00:00:00 IST 2006&gt; but was:&lt;Mon Apr 03 00:00:00 IST 2006&gt;

            at org.mifos.application.accounts.savings.business.TestSavingsBO.testCalculateInterest_IntCalcFreqTenDays_minbal(TestSavingsBO.java:2390)

</failure>

  </testcase>

 

Any idea, what might be the problem??

 

For reference I m attaching the test suite report with mail.

TEST-org.mifos.application.ApplicationTestSuite.xml

Soham Dhakal

unread,
Nov 13, 2007, 6:31:11 AM11/13/07
to Developer
I am also getting similar failures (latest check out). I am running it on NPT (Nepali Time). I will change the time to pacific and run it again and see if it fares better (issues 1491) .. But some of the errors i am getting don't seem related to time zone.  Any thoughts?
 
OS - Win XP SP 2
Java - jdk1.6.0_02
 
 
p.s  pardon my ignorance but what is the best way to view these file.. i just want to see the errors instead of having to go through the lot

Sent: Tuesday, November 13, 2007 12:45 PM
Soham - TEST-org.mifos.application.ApplicationTestSuite.xml

Keith Pierce

unread,
Nov 13, 2007, 7:32:18 AM11/13/07
to Developer
I had the same problem, but all of the failures disappeared (even those seemingly unrelated to time zones) disappeared after changing to pacific time.

Keith Pierce

Aliya Walji

unread,
Nov 13, 2007, 11:50:18 AM11/13/07
to Developer

Hi Saurabh,

 

Currently, if I’m not mistaken, we have a bug where the test suite fails when the time zone is not set to Pacific timezone.  This may be what is causing the issue for you.  Can you try changing your system timezone to Pacific Time and running the test suite again?  Hopefully this will resolve your issue.

 

Thanks,

Adam Monsen

unread,
Nov 13, 2007, 11:58:34 AM11/13/07
to mifos-d...@lists.sourceforge.net
On Nov 13, 4:32 am, "Keith Pierce" <krp0...@gmail.com> wrote:
> I had the same problem, but all of the failures disappeared (even those
> seemingly unrelated to time zones) disappeared after changing to pacific
> time.
[...]

issue #1491 covers unit test problems encountered when running in
different timezones:

https://mifos.dev.java.net/issues/show_bug.cgi?id=1491

--
Adam Monsen

Keith Pierce

unread,
Nov 13, 2007, 2:47:16 PM11/13/07
to Developer
I am pretty new to the MifOS project, but would be willing to tackle this issue.

Keith Pierce

Aliya Walji

unread,
Nov 13, 2007, 5:50:00 PM11/13/07
to Developer

Hi Keith,

 

Welcome to the Mifos project!  We’d absolutely welcome any contributions you’d be willing to make in this area.  When you have some code you would like to submit, you can submit it in a patch which one of our developers can review.  The code submission process is detailed here:  http://mifos.org/developers/technical-orientation/code-submission-process-1

 

When you are ready to start working on this issue, you may want to update the bug in the issue tracker (set the status to ‘started’) and email the mailing list that you are working on it so that there are no duplicate efforts. 

 

If you have any questions along the way, feel free to email this list for guidance and we’ll be happy to help you out.

 

Thanks for your interest in contributing,

 

Aliya

 


Sent: Tuesday, November 13, 2007 11:47 AM
To: Developer

Tom Bostelmann

unread,
Nov 13, 2007, 7:52:43 PM11/13/07
to Developer
Another good option would be to fix the bug and submit a fix with the code :)

You can add this to your patch of you would like or you can submit the fix as a separate patch.

Aliya, is there an issue number associated with this?

On Nov 13, 2007 8:50 AM, Aliya Walji <awa...@grameenfoundation.org> wrote:

Hi Saurabh,

 

Currently, if I'm not mistaken, we have a bug where the test suite fails when the time zone is not set to Pacific timezone.  This may be what is causing the issue for you.  Can you try changing your system timezone to Pacific Time and running the test suite again?  Hopefully this will resolve your issue.

 

Thanks,

 

Aliya

 

From: mifos-devel...@lists.sourceforge.net [mailto:mifos-devel...@lists.sourceforge.net] On Behalf Of Saurabh Kumar
Sent: Monday, November 12, 2007 11:00 PM


To: Developer
Subject: Re: [Mifos-developer] Patch for moratorium module....

 

 

Hi Aliya,

 

I have checked the code and I feel there might me some configuration issue with date.

 

There is some problem with setting of FiscalWeekStartDay --

 

<testcase classname="org.mifos.framework.components.configuration.business.TestConfiguration" name="testAreaOfficeConfiguration" time="0.0">

    <failure message ="expected:&lt;2&gt; but was:&lt;0&gt;" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: expected:&lt;2&gt; but was:&lt;0&gt;

          at org.mifos.framework.components.configuration.business.TestConfiguration.assertForMeetingConfig(TestConfiguration.java:86)

          at org.mifos.framework.components.configuration.business.TestConfiguration.testAreaOfficeConfiguration(TestConfiguration.java:52)

</failure>

  </testcase>

 

In above failure of assertion it is trying to get FiscalWeekStartDay, whose value is 0 instead of two.

 

<testcase classname="org.mifos.application.accounts.savings.business.TestSavingsBO" name="testCalculateInterest_IntCalcFreqTenDays_minbal" time="0.888">

    <failure message ="expected:&lt;Sat Apr 01 00:00:00 IST 2006&gt; but was:&lt;Mon Apr 03 00:00:00 IST 2006&gt;" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: expected:&lt;Sat Apr 01 00:00:00 IST 2006&gt; but was:&lt;Mon Apr 03 00:00:00 IST 2006&gt;

Adam Monsen

unread,
Nov 13, 2007, 7:58:02 PM11/13/07
to Developer
On Nov 13, 2007 4:52 PM, Tom Bostelmann <tbost...@gmail.com> wrote:
Another good option would be to fix the bug and submit a fix with the code :)

You can add this to your patch of you would like or you can submit the fix as a separate patch.

Aliya, is there an issue number associated with this?

Saurabh Kumar

unread,
Nov 14, 2007, 4:27:38 AM11/14/07
to Developer

 

Hi Tom,

 

I tried by changing the timezone to Pacific and the testsuite passed successfully.

 

Please find the patch for moratorium module attached with the mail.

 

As far as the issue regarding failing of testsuite because of different timezones is concerned, I am looking into that. Will update you as soon as I crack the problem.

Moratorium Patch.patch

Keith Pierce

unread,
Nov 14, 2007, 11:27:37 AM11/14/07
to Developer
Saurabh, I just assigned issue 1491 (timezone problems with unit tests) to myself. I've already found some easily-fixed bugs. Let me know how you'd like to proceed: take over the issue, collaborate on it, or leave it to me so you can work on higher-priority issues. I am pretty new to MifOS, and this looked like a good place for me to start diving in.

Keith Pierce

Saurabh Kumar

unread,
Nov 15, 2007, 2:13:04 AM11/15/07
to Developer

 

Hi Keith,

 

You can go ahead with fixing of this issue.

 

I investigated this issue and I think I have found the cause of problem. I m listing the issues, which I think are creating the problem –

 

1)  In ConfigurationInitializer class we have a method createSystemConfiguration(), this method returns SystemConfiguration object.

For creating SystemConfiguration we have hardcoded the value for timeZone, I think we need to remove this hardcoding and instead of   that we need to get default time zone or user’s timezone.

 

2) Moreover if you check TestSavingsHelper class, we have a testcase testGetNextInterestCalculationDateEveryMonth() (which is getting    failed because of this problem); there we are calling two methods, namely getNextScheduleDate() & getDate(); getDate() is fine, but in getNextScheduleDate() method we are getting date from MeetingBO object, by calling getNextScheduleDateAfterRecurrence(). I think problem is there in MeetingBO. In MeetingBO we are creating instance of GregorianCalendar without specifying the timeZone. And in java if you don’t specify timeZone, your date will be interpreted using the the local default TimeZone. If the user has not configured it correctly in his OS, you may get Pacific Standard time or GMT, without warning.

Therefore, I think here we need to create instance of GregorianCalendar by specifying user’s timezone.

 

3) Also, in MeetingBO we are using one method from DateUtils class, namely getCalendarDate; in this method again we are creating instance of GregorianCalendar without specifying timeZone.

 

I feel the above mentioned issues are root cause of problem. Do let me know if I m wrong or if I can be of any help.

Tom Bostelmann

unread,
Nov 15, 2007, 2:57:53 AM11/15/07
to Developer
Keith, I would recommend sending us a patch with your changes.  This would be a good way of getting more acquainted with the development process.

Saurabh Kumar

unread,
Nov 15, 2007, 9:09:53 AM11/15/07
to Developer

 

Hi Tom,

 

Please find the patch for moratorium module.

 

I have merged our code with latest revision from svn, i.e.  revision 12192.

 

There were no build errors and the test suite passed successfully.

 

Do let me know if there are any issues.

 

Please ignore my previous patch because after I had sent my previous patch, revision 12192 was checked in; so I had to merge with the new revision.

Thanks & Regards,

Saurabh Kumar • Developer • SunGard • Offshore Services • Divyasree Chambers, Langford Road, Bangalore 560025 India
Tel +91-80-2222-0501 • Mobile +91-9886945575 • Fax +91-80-2222-0511 • www.sungard.com

-----Original Message-----
From: mifos-devel...@lists.sourceforge.net [mailto:mifos-devel...@lists.sourceforge.net] On Behalf Of Tom Bostelmann
Sent: Friday, November 09, 2007 4:30 AM

moratorium_patch.patch

Keith Pierce

unread,
Nov 15, 2007, 12:50:00 PM11/15/07
to Developer
I'll send the patch this afternoon, after updating my workspace and re-running unit tests.

Keith

Keith Pierce

unread,
Nov 15, 2007, 2:00:56 PM11/15/07
to Developer
Here is the patch for issue 1491. Before submitting, I updated the mifos project and re-ran all unit tests successfully.

Keith Pierce


patch-1491.txt

Tom Bostelmann

unread,
Nov 16, 2007, 6:34:42 PM11/16/07
to Developer
Saurabh,
Things look good so far.  You have good test coverage and all the tests are passing. 

However, there are couple things I need you to change:

1.) struts-config.xml - Please remove all instances of struts-config.xml from the 'test' source directory.  Your mock struts tests should run using the struts-config.xml from the 'src' dir.  Duplicating this code means you aren't actually testing the deployed code.

2.) validation.xml - for the same reason, we should remove this file from the 'test' directory.  it actually appears to not have any content in it?  why does this exist?

3.) validator-rules.xml - same as above.

4.) MoratoriumUIResources.properties - same as above - please use the equivalent from the 'src' directory.

Let me know if you have any questions on this.  Thanks a lot for your patience while we're short-staffed :P
-Tom

Tom Bostelmann

unread,
Nov 16, 2007, 7:45:01 PM11/16/07
to Developer
Looks great.  Thanks Keith!  The patch was committed and is in revision 12200.

Let me know if you have any questions.
-Tom

On Nov 15, 2007 11:00 AM, Keith Pierce < krp...@gmail.com> wrote:
Here is the patch for issue 1491. Before submitting, I updated the mifos project and re-ran all unit tests successfully.

Keith Pierce



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Saurabh Kumar

unread,
Nov 19, 2007, 2:41:57 AM11/19/07
to Developer

 

Hi Tom,

 

Thanks for reviewing the patch.

 

As far as duplicate files are concerned, I m following the existing design of mifos.

 

In existing design we are using separate struts-config (and other files) for testing purpose.

 

I have referred existing modules for that (for example holiday or other module).

Saurabh Kumar

unread,
Nov 19, 2007, 3:53:45 AM11/19/07
to Developer

 

Hi Tom,

 

Thanks for reviewing the patch.

 

As far as duplicate files are concerned, I m following the existing design of mifos.

 

In existing design we are using separate struts-config (and other files) for testing purpose.

 

I have referred existing modules for that (for example holiday or other module).

 

 

Thanks & Regards,

Tom Bostelmann

unread,
Nov 21, 2007, 4:31:49 AM11/21/07
to Developer
okay, i can see your point.  the problem, however, is that the existing design is defective.  you aren't actually testing the code that is deployed, which isn't a legitimate test.

i entered a defect for the rest of the code (see issue 1521).

i'd like you to at least fix the issue in the code that you submitted.

Saurabh Kumar

unread,
Nov 22, 2007, 6:10:37 AM11/22/07
to Developer

 

Hi Tom,

 

Are you referring to “CactusStrutsTestCase”, coz for testing deployed code we need to use “CactusStrutsTestCase” as base class for our testcases.

 

Even if we use same struts-config(validation.xml,etc), that won’t serve purpose of testing deployed code, coz “MockStrutsTestCase” uses a set of HttpServlet mock objects to simulate the container environment without requiring a running servlet engine.

 

“CactusStrutsTestCase” uses the “Cactus testing framework” to test Struts classes in the actual server container, allowing for a testing environment more in line with the actual deployment environment.

 

Tell me if I m wrong or if I m thinking in wrong direction.

 

Moreover if we try to point to struts-config in src directory it will give following error, which clearly states that we need to have struts-config file in the directory from which we are trying to run testcases.

 

servletunit.struts.ExceptionDuringTestError: A NullPointerException was thrown.  This may indicate an error in your ActionForm, or it may indicate that the Struts ActionServlet was unable to find struts config file.  TestCase is running from D:\latest code\mifos directory.  Context directory has not been set.  Try calling setContextDirectory() with a relative or absolute path.  struts config file must be found under the context directory, the directory the test case is running from, or in the classpath.

            at servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:303)

            at org.mifos.application.moratorium.struts.action.TestMoratoriumAction.testCreateForClient(TestMoratoriumAction.java:83)

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

            at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

            at java.lang.reflect.Method.invoke(Unknown Source)

            at junit.framework.TestCase.runTest(TestCase.java:168)

            at junit.framework.TestCase.runBare(TestCase.java:134)

            at junit.framework.TestResult$1.protect(TestResult.java:110)

            at junit.framework.TestResult.runProtected(TestResult.java:128)

            at junit.framework.TestResult.run(TestResult.java:113)

            at junit.framework.TestCase.run(TestCase.java:124)

            at junit.framework.TestSuite.runTest(TestSuite.java:232)

            at junit.framework.TestSuite.run(TestSuite.java:227)

            at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)

            at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)

            at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

------------

Root Cause:

------------

java.lang.NullPointerException

            at servletunit.struts.MockStrutsTestCase.getActionServlet(MockStrutsTestCase.java:231)

            at servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:290)

            at org.mifos.application.moratorium.struts.action.TestMoratoriumAction.testCreateForClient(TestMoratoriumAction.java:83)

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

            at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

            at java.lang.reflect.Method.invoke(Unknown Source)

            at junit.framework.TestCase.runTest(TestCase.java:168)

            at junit.framework.TestCase.runBare(TestCase.java:134)

            at junit.framework.TestResult$1.protect(TestResult.java:110)

            at junit.framework.TestResult.runProtected(TestResult.java:128)

            at junit.framework.TestResult.run(TestResult.java:113)

            at junit.framework.TestCase.run(TestCase.java:124)

            at junit.framework.TestSuite.runTest(TestSuite.java:232)

            at junit.framework.TestSuite.run(TestSuite.java:227)

            at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)

            at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)

            at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Tom Bostelmann

unread,
Dec 2, 2007, 7:32:53 PM12/2/07
to Developer
Apologies for not getting back to you earlier Saurabh.  I included responses to your questions inline...

Even if we use same struts-config(validation.xml,etc), that won't serve purpose of testing deployed code, coz "MockStrutsTestCase" uses a set of HttpServlet mock objects to simulate the container environment without requiring a running servlet engine.

I understand that it doesn't start up a servlet engine - it emulates one.  but i'm assuming that you created a struts-config/validation.xml because the emulator will also simulate the use of configuration files like struts-config and the validation configuration. 

If the testing framework that we're using uses a struts-config, it should use the one that's being deployed.

I'm trying to avoid having duplicate code.  A developer can come in and make changes to the struts-config in the main 'src' directory without updating the one in 'test'.  If that occurs we're no longer testing the correct configuration.
 

Moreover if we try to point to struts-config in src directory it will give following error, which clearly states that we need to have struts-config file in the directory from which we are trying to run testcases.

  

Yes, I know.  I need you to figure out how to fix this.

-Tom
 

servletunit.struts.ExceptionDuringTestError : A NullPointerException was thrown.  This may indicate an error in your ActionForm, or it may indicate that the Struts ActionServlet was unable to find struts config file.  TestCase is running from D:\latest code\mifos directory.  Context directory has not been set.  Try calling setContextDirectory() with a relative or absolute path.  struts config file must be found under the context directory, the directory the test case is running from, or in the classpath.

            at servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java :303)

            at org.mifos.application.moratorium.struts.action.TestMoratoriumAction.testCreateForClient (TestMoratoriumAction.java:83)

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

            at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

            at java.lang.reflect.Method.invoke(Unknown Source)

            at junit.framework.TestCase.runTest(TestCase.java:168)

            at junit.framework.TestCase.runBare(TestCase.java:134)

            at junit.framework.TestResult$1.protect(TestResult.java:110)

            at junit.framework.TestResult.runProtected(TestResult.java:128)

            at junit.framework.TestResult.run(TestResult.java:113)

            at junit.framework.TestCase.run(TestCase.java:124)

            at junit.framework.TestSuite.runTest(TestSuite.java:232)

            at junit.framework.TestSuite.run(TestSuite.java:227)

            at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java :76)

            at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)

            at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java :38)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:460)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:673)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:386)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196)

            at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196)

Saurabh Kumar

unread,
Dec 4, 2007, 8:07:14 AM12/4/07
to Developer

 

 

Hi Tom,

 

Thanks for your comments.

 

I got your point regarding one struts-config file.

 

In my previous mail, I had mentioned about Cactus for testing deployed code, do you want me to dig more on that???

 

Thanks & Regards,

Saurabh Kumar • Developer • SunGard • Offshore Services • Divyasree Chambers, Langford Road, Bangalore 560025 India
Tel +91-80-2222-0501 • Mobile +91-9886945575 • Fax +91-80-2222-0511 • www.sungard.com

-----Original Message-----
From: mifos-devel...@lists.sourceforge.net [mailto:mifos-devel...@lists.sourceforge.net] On Behalf Of Tom Bostelmann
Sent: Monday, December 03, 2007 6:03 AM
To: Developer
Subject: Re: [Mifos-developer] Patch for moratorium module....

 

Apologies for not getting back to you earlier Saurabh.  I included responses to your questions inline...

Even if we use same struts-config(validation.xml,etc), that won't serve purpose of testing deployed code, coz "MockStrutsTestCase" uses a set of HttpServlet mock objects to simulate the container environment without requiring a running servlet engine.

I understand that it doesn't start up a servlet engine - it emulates one.  but i'm assuming that you created a struts-config/validation.xml because the emulator will also simulate the use of configuration files like struts-config and the validation configuration. 

If the testing framework that we're using uses a struts-config, it should use the one that's being deployed.

I'm trying to avoid having duplicate code.  A developer can come in and make changes to the struts-config in the main 'src' directory without updating the one in 'test'.  If that occurs we're no longer testing the correct configuration.
 

 

Moreover if we try to point to struts-config in src directory it will give following error, which clearly states that we need to have struts-config file in the directory from which we are trying to run testcases.

  

Yes, I know.  I need you to figure out how to fix this.


-Tom
 

 

Hi Tom,

 

Are you referring to “CactusStrutsTestCase”, coz for testing deployed code we need to use “CactusStrutsTestCase” as base class for our testcases.

 

Even if we use same struts-config(validation.xml,etc), that won’t serve purpose of testing deployed code, coz “MockStrutsTestCase” uses a set of HttpServlet mock objects to simulate the container environment without requiring a running servlet engine.

 

“CactusStrutsTestCase” uses the “Cactus testing framework” to test Struts classes in the actual server container, allowing for a testing environment more in line with the actual deployment environment.

 

Tell me if I m wrong or if I m thinking in wrong direction.

 

Moreover if we try to point to struts-config in src directory it will give following error, which clearly states that we need to have struts-config file in the directory from which we are trying to run testcases.

 

servletunit.struts.ExceptionDuringTestError: A NullPointerException was thrown.  This may indicate an error in your ActionForm, or it may indicate that the Struts ActionServlet was unable to find struts config file.  TestCase is running from D:\latest code\mifos directory.  Context directory has not been set.  Try calling setContextDirectory() with a relative or absolute path.  struts config file must be found under the context directory, the directory the test case is running from, or in the classpath.

        at servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:303)

        at org.mifos.application.moratorium.struts.action.TestMoratoriumAction.testCreateForClient(TestMoratoriumAction.java:83)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

        at java.lang.reflect.Method.invoke(Unknown Source)

        at junit.framework.TestCase.runTest(TestCase.java:168)

        at junit.framework.TestCase.runBare(TestCase.java:134)

        at junit.framework.TestResult$1.protect(TestResult.java:110)

        at junit.framework.TestResult.runProtected(TestResult.java:128)

        at junit.framework.TestResult.run(TestResult.java:113)

        at junit.framework.TestCase.run(TestCase.java:124)

        at junit.framework.TestSuite.runTest(TestSuite.java:232)

        at junit.framework.TestSuite.run(TestSuite.java:227)

        at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)

        at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)

        at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

------------

Root Cause:

------------

java.lang.NullPointerException

        at servletunit.struts.MockStrutsTestCase.getActionServlet(MockStrutsTestCase.java:231)

        at servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:290)

        at org.mifos.application.moratorium.struts.action.TestMoratoriumAction.testCreateForClient(TestMoratoriumAction.java:83)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

        at java.lang.reflect.Method.invoke(Unknown Source)

        at junit.framework.TestCase.runTest(TestCase.java:168)

        at junit.framework.TestCase.runBare(TestCase.java:134)

        at junit.framework.TestResult$1.protect(TestResult.java:110)

        at junit.framework.TestResult.runProtected(TestResult.java:128)

        at junit.framework.TestResult.run(TestResult.java:113)

        at junit.framework.TestCase.run(TestCase.java:124)

        at junit.framework.TestSuite.runTest(TestSuite.java:232)

        at junit.framework.TestSuite.run(TestSuite.java:227)

        at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)

        at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)

        at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)

        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Van Mittal-Henkle

unread,
Dec 4, 2007, 12:11:44 PM12/4/07
to Developer
Hi Saurabh,
 
At this point, it would be good to first look for a solution within the existing test framework being used for Mifos before looking at other options like Cacuts.
 
Thanks,
--Van

Sent: Tuesday, December 04, 2007 5:07 AM

Tom Bostelmann

unread,
Dec 4, 2007, 2:25:46 PM12/4/07
to Developer
what Van said :)

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Saurabh Kumar

unread,
Dec 5, 2007, 7:18:39 AM12/5/07
to Developer

 

Hi Tom,

 

We have tried all the possible options for the problem but we are unable to find the solution.

 

We tried following options >>

1)       place the directory that contains struts-config in CLASSPATH

2)       used setConfigFile() to set the location of struts-config file

3)       provided absolute path for the struts-config file

 

Infact we are exhausted with all the options we had.

 

Can you give us some possible direction through which we can approach this problem or else I think someone else on community can take up this issue.

Reply all
Reply to author
Forward
0 new messages