FINERACT-824: NullPointerException is thrown when submitting a loan account application with an existing externalId

[angelboxes]

Removed the second validation since realCause.getCause() is null if it is equal to realCause

Description

When I tried to create a new loan account with an already used external Id, a NullPointerException was thrown with no description of why the loan account creation failed. I removed a validation that returned a null value, this kind of validation was only used with integrity issues on loan accounts and added for some OpenJPA Integration Changes.

https://issues.apache.org/jira/browse/FINERACT-824

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Commit message starts with the issue number from https://issues.apache.org/jira/projects/FINERACT/. Ex: FINERACT-646 Pockets API.

• Coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions have been followed.

• API documentation at https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm has been updated with details of any API changes.

• Integration tests have been created/updated for verifying the changes made.

• All Integrations tests are passing with the new commits.

• Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the list.)

Our guidelines for code reviews is at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide

[vorburger]

@angelboxes I don't know much about this code, but it looks like someone thought that it would be useful to also check the cause... your FINERACT-824 indicates that this can lead to NPEs, so instead of just completely removing the getCause() related check, do you think it may be a good idea to check it like this (for both):

} else if (realCause.getMessage().contains("loan_externalid_UNIQUE") || (realCause.getCause() != null && realCause.getCause().getMessage().contains("loan_externalid_UNIQUE"))) {

Just a thought, as this would perhaps seem more prudent in case that extra check for the cause was there for a good reason. If you are totally confident that this cause is never set and always null, then this is also OK for me, but I thought it would be worth to clarify?

[angelboxes]

Yeah, actually that was my first approach to this issue however I saw that this is not the only place where unique values exceptions are thrown but this is the only place where such validation is done. and thought that it was one of those changes that worked when it was added but a different one made it useless and that maybe it wasn't needed,. Don't worry I will change it as you propose.

[vorburger]

LGTM. I'll merge this one when the build passed.