[Mifos-developer] org.hibernate.InstantiationException: No default constructor for entity: org.mifos.application.collectionsheet.business.CollSheetCustBO

[Adam Monsen]

Udai, Van and I are working on currency denominated loan product work
on branches/cdlp. We ran into a strange error in build #13:
"org.hibernate.InstantiationException: No default constructor for
entity: org.mifos.application.collectionsheet.business.CollSheetCustBO".
There surely is a default constructor in that class (and we weren't
messing with the constructor) so we're a bit confused as to what might
cause this kind of error. Hibernate configuration? Concurrency
problem? Any ideas?

More details attached.

[Udai Gupta]

It seems like Hibernate(3.2) requires a public or protected default
constructor(i.e. with no args) to be defined explicitly when other
constructors are defined, defining a protected default constructor
resolves this issue (similar to AccountBO). Still I am not sure if its
a expected behavior or a bug in Hibernate because the occurrence of
failure due to this was quite random in builds.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

[Keith Woodlock]

Adam, Udai,

hibernate has always required persisted objects to implement no-arg
constructor as it uses reflection to instantiate objects..

The persistent class that was causing the problem is
CollSheetCustBO... having worked on the collection sheet, I know that
we dont use the concept of this when doing collection sheet creates or
saves (it still exists, the tables etc but it was somethink I
highlighted needed to be taken out but I think there was some talk of
reports using these tables etc) In any case, hibernate doesn't use
these as far as i know.. don't have code here and should check it
again.

default no-arg constructors aren't the only think that hibernate
pushes upon us:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/persistent-classes.html

[Udai Gupta]

Hi Keith,

CollSheetCustBO is being used by tests, probably the test can be removed or modify to not use this class if CollSheetCustBO is not used in main code anymore.

org.mifos.framework.components.batchjobs.helpers.CollectionSheetHelperIntegrationTest.clearCollectionSheets(CollectionSheetHelperIntegrationTest.java:157)
at org.mifos.framework.components.batchjobs.helpers.CollectionSheetHelperIntegrationTest.basicTest(CollectionSheetHelperIntegrationTest.java:152)
at
org.mifos.framework.components.batchjobs.helpers.CollectionSheetHelperIntegrationTest.testFiveDaysInAdvance(CollectionSheetHelperIntegrationTest.java:101)

The interesting thing about this issue is, We haven't explicitly hidden the default constructor(non-arg) in CollSheetCustBO. Hibernate should be able to access default constructor. Am I missing something here?

Also, this error was shown in some build, though I just saw this error on my box yesterday only.
Its still a puzzle to me why some build passed on hudson and my box this and showed no such error.

Udai

[John Woodlock]

I was having problems with this yesterday and having looked at the issue (thats about four of us now that have gone through pain with this) decided to follow Udai's no arg constructor advice emailed yesterday.  Anyhow, when I synchronised, you had already changed the class so thanks for that Udai.  It certainly resolved the issue for me.

Why was it intermittent... well it seems to depend on whether the test resulted in the creation of a row in coll_sheet_customer.  If row then problem.

That's all nice to know but as people have pointed out this (collection sheet reporting) functionality isn't currently used and I'm pretty sure the test doesnt quite work either (e.g. it tries to offset schedules by a number of days - it misses the "group" customer schedule and I can't see why that would be intentional.)

Van made this reply to Keith W a while ago http://groups.google.com.au/group/mifosdeveloper/msg/c2675c488be96004.

The speed aspect mentioned should be okay now.  If there is still a need to ship functionality to print collecion sheet reports I'd be happy to look at it with anyone who can hold up the functional requirements end.  I'd even be happy to see how GK currently do it and see how we could bring it or something like it back into mifos.


John

[Keith Woodlock]

Udai,

Having read through previous dicussion:
http://groups.google.com.au/group/mifosdeveloper/browse_thread/thread/e839128082feb8ae/c2675c488be96004?#c2675c488be96004

It appears that If its is only referenced in tests then the persistent
class and hibernate mappings for it are not used in the application
and should be removed. from the thread its seems there is an SQL
report that uses some of these tables (but the report must be
redundant as these tables arent populated by anything else in the
application? does the SQL in the report populate these tables as a
first step and then go and return a report?)

I never did add the information to the wiki as i said i would on the
thread which is my bad. It was a pity having went through the pain of
refactoring the collection sheet area and learning from it that we
didn't go back and

1 investigate any reports that may be executed in the area
2 remove the code/tables around this if possible
3 remove BatchJob task around this (that is never invoked)

This also bring me onto the rest of the BatchJobs that really need to
be looked at. I believe from the work done on collection sheet that we
identified that one or two of the batch jobs should not be needed...

I just wonder if more priority should be given to clearing up the
complexity/noise in the application around these areas above the
refactoring to 'pull out' APIs.

KeithW

[Udai Gupta]

> I just wonder if more priority should be given to clearing up the
> complexity/noise in the application around these areas above the
> refactoring to 'pull out' APIs.

API should definitely be more in priority.

@Cleanup
you have already put the deprecation on the classes which is enough for me. :)
We can remove the noise after confirming the use in reports as you
guys have already discussed.

My doubt about hibernate behavior was a generic concern. Its just a
co-incident that it occurred in this class.

I really appreciate your response and thanks for information :)

Cheers,

[Van Mittal-Henkle]

KeithW,

> This also bring me onto the rest of the BatchJobs that really need to
> be looked at. I believe from the work done on collection sheet that we
> identified that one or two of the batch jobs should not be needed...
>
> I just wonder if more priority should be given to clearing up the
> complexity/noise in the application around these areas above the
> refactoring to 'pull out' APIs.

We had some discussion relating to relative priority of the API work and
batch job work. In particular some time ago you had brought up the
possibility of eliminating the schedule generation batch job
(GenerateMeetingsForCustomerAndSavingsHelper/Task). We're in agreement
with you that taking on schedule generation should be prioritized ahead
of the loan creation API work.

As we discussed at some point before, this change would entail moving
from schedules generated by batch jobs and stored in the database to
dynamically generated schedules.

This would be a significant change which carries some risk, but there
are many potential benefits including:
* eliminating the GenerateMeetingsForCustomerAndSavingsHelper/Task batch
job (which would eliminate a number of existing and potential
scalability issues.
* eliminating the ReenerateScheduleHelper/Task that would no longer be
required since schedules would be dynamically generated.
* simplifying the code related to schedule generation. We should be
able to make this easier to understand, maintain and extend.

So what we propose is that you shift gears from the API work and as your
next work do a spike to:
* validate that the dynamic schedule generation approach should be
workable
* determine the total scope of work to complete this so that it can be
estimated and planned.

Some things to note:
* since schedule generation is so central to Mifos, these changes will
impact lots of code, so as with other work it would be good to create a
branch for this. We will need to carefully consider how this work would
be integrated back into trunk as it progresses in order to minimize
project risk.
* part of our ongoing refactoring work has been to move away from the
java Date/Calendar classes in favor of Joda Time Date/Time classes.
When doing this dynamic schedule work, one of the goals would be to do
all date/time manipulation using Joda Time.

Let me know how this sounds to you, Keith. If you're up for it then it
would be great to have a chance to discuss it further. There are also
several interesting design possibilities related to schedule generation
including introducing a rules engine to provide some flexibility and
configurability around this.

Cheers,
--Van

[Keith Woodlock]

Van,

This sounds good to me and I am happy to work on this before any loan
creation API work. I should able to start work within two weeks... as
you said we can discuss this further at another time.

just to clear up some points:

>> this change would entail moving
>> from schedules generated by batch jobs and stored in the database to
>> dynamically generated schedules.

I think the first step is a spike as you said to validate the
approach. The first step would be just to remove the batch jobs
responsible for generating the schedules... instead of this, the loan
API would be responsible for handling the addition of new schedules
(stored in database) when needed. I believe that it may be possible to
remove the need for schedules to be persisted and generated
dynamically but that would be a step too far for the first
refactoring.

After spiking this approach I can do an impact anlaysis and see places
that can be affected so the work can be estimated.

regards,
KeithW

[Ryan Whitney]

Keith, Van

I hope I'm not derailing the conversation too much but I wanted to bring up
something if you're going to be looking at the loan schedule code.

Not all MFI's have center meetings and so their loans aren't subject to
meeting schedules. As we know, repayment schedules are tied to meeting
schedules in mifos and while we've come up with a few workarounds for that
(ie, the Loan Schedule Independent of Meeting Schedule feature), they aren't
really full fledged features yet.

So it'd be good that while looking at the code what it might take to
decouple the two (and not that we should do work on it now, but maybe make
note for the future when we do have to do that).

And just to clarify, I'm not saying Mifos should totally decouple from the
meeting schedule, just that Mifos should support both models. (and
decoupling should also be done for fees as well).

Ryan

--
Ryan Whitney
Mifos Technical Program Manager
rwhi...@grameenfoundation.org
Mifos - Technology that Empowers Microfinance (www.mifos.org)
Our mission is to enable the poor, especially the poorest, to create a world
without poverty.
<http://grameenfoundation.org/take-action/ingenuity-fund-challenge/>
P please consider the environment before printing this e-mail.

[Keith Woodlock]

Ryan,

Thanks for the heads up. I think when we go back to doing the API
refactoring for loan creation we will be able to approach the
refactoring with this as a consideration..

KeithW