This recently introduced new test (FINERACT-926) would locally pass, but
then fail on the next run, because another test in the same class would
modify job state to be inactive. It now sets the first jobs state as it
requires it to be, and properly awaits the expected outcome.
* minor clean-up in existing JsonSerializer implementations (FINERACT-926)
* centralize registration of GSON type adapters (FINERACT-926)
* add java.util.Date ISO-8601 GSON type adapter (FINERACT-926)
This file is created by the Tomcat embedded by Spring Boot
when running "java -jar build/libs/fineract-provider.jar",
having it on .gitignore avoids anyone commiting it by mistake.
This does NOT, yet, fix FINERACT-922, but it splits the old test into
new smaller test methods, which (hopefully) should always pass, except
for the last one.
This makes it much easier and more secure to use it "rootless",
e.g. with https://podman.io's podman-compose instead (Moby) Docker.
Also includes minor README improvements useful for beginners.
Note that it is NOT enabled by default, which should be OK for the ASF.
The main point here is just to clearly document it for end-users.
I've obviously tried out what's documented, and can confirm it works.
Indirectly related to FINERACT-762 - not sure if strictly required,
but seems like a good idea anyway at this opportunity, so why not.
As originally on https://github.com/apache/fineract/pull/638/files
This environment variable is actually never used. The port of a Tenant
DB instead appears to be read from schemaServerPort of the
tenant_server_connections table.
These are the default values, from jdbc.properties, only added for
clarity and to make it obvious that they need to be changed e.g. for
FINERACT-762.
The different formats and naming conventions are a little bit of a mess,
but changing them now leads to backwards incompatibility, so for now
let's leave as is; possible clean up later in FINERACT-889.
We can use environment variables instead of system properties.
We originally had to use system properties and could not use environment
variables, because these used to read by Tomcat, but since the switch
to Hikari in FINERACT-796 these are read by Spring Boot instead of
Tomcat, so we can now use system properties.
This both "looks nicer" and is useful e.g. for FINERACT-881.
Also adds a new assertion for a clearer failure message than the
confusing low-level technical ArrayIndexOutOfBoundsException for
whenever this test will be re-activated later.
Adds a new assertion for a hopefully clearer failure message than the
confusing low-level technical ArrayIndexOutOfBoundsException we
regularly hit on Travis CI.
Similar to https://github.com/apache/fineract/pull/764
see https://jira.spring.io/browse/DATAJPA-622
Even though we don't use Hibernate, copying this annotation from the
original class in Spring Data seems prudent - just in case. It should
not cause any harm or side effects on OpenJPA.
instead of the NoSuchElementException from Optional.get(), we're now
throwing an UnsupportedOperationException which includes the details of
the missing object. (This kind of detailed exception was already thrown
in two existing places in the same code after a null check, but it never
reached there, because the Optional.get() failed earlier. Another
option would have been to return null for an absent Optional, but this
is better.)
The other unrelated changes are automatic clean up actions (in Eclipse).
As per the great analysis by Manthan Surkar (@thesmallstar) in the
original PR https://github.com/apache/fineract/pull/723, the cause of
the FINERACT-808 bug was that "the backend would treat "UPDATE" and
similar strings as SQL injection".
The root cause of that was that (IMHO..) how Fineract does SQL injection
is more of a workaround (blacklisting some keywords and some heuristic
checks) then how this really should be done (by using JDBC Prepared
statements with arguments for all external data, instead inlined SQL).
This also lays the foundation for more like this in FINERACT-854.
* Allow customizing Tenants DB JDBC uid/pwd/driver (FINERACT-806)
Added Java system properties for username and password to docker-compose
Modified sever.xml to get username and password
* Fixes for customizing Tenants DB JDBC uid/pwd/driver (FINERACT-806)
* Use random MYSQL_ROOT_PASSWORD in docker-compose.yml (FINERACT-806)
This provides future non-regression testing that the the customized
MySQL password is actually really used, and it doesn't just work because
"mysql" is still hard-coded anywhere.
Co-authored-by: Yemdjih Kaze Nasser <kaze.nasser@outlook.com>
This speeds up e.g. "podman-compose build" for me from 5m to 4m.
BEFORE:
real 5m29.884s
user 4m17.643s
sys 2m57.567s
AFTER:
real 4m19.458s
user 3m13.815s
sys 2m 3.095s
* Minor manually done fix up of fineractdev-eclipse-preferences.epf file
This in theory should not change anything about the conventions,
it's just a first manual clean up of this very old file here.
The few extra new lines are what I found when exporting Preferences.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* fineractdev-eclipse-preferences.epf imported and re-exported in Eclipse.
This in theory should not change anything about the conventions, as
presumably Eclipse during an Import and re-Export of an EPF just adds
new settings, and perhaps removes old settings. I've not actually made
any manual changes in Preferences in this step.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* fineractdev-eclipse-preferences.epf "import" in line with Checkstyle
The non-import related Code Formatter settings may need further tuning;
this will be done in future changes; the focus in this round is on
import.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* Use Eclipse's Source > Organize Import to re-order all import statements
This uses the fineractdev-eclipse-preferences.epf from the previous
commit, which just so happens ;) to exactly match the expected import
rules which the next commit is going to enforce using Checkstyle.
This is of course not specific to only Eclipse per se; other IDEs can
be similarly configured to match these coding conventions; I just happen
to have used Eclipse.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* Activate and Enforce all Checkstyle import related new checks
and update the README to explain Checkstyle, and the availability of the
Eclipse Preferences configuration file which matches the import
code format conventions which are now enforced.
Contributions for a similar preferences file for other IDEs welcome! ;)
Related to https://issues.apache.org/jira/browse/FINERACT-821
Thanks to prior work for SpotBugs, this passes without requiring any
code adjustments. (Fineract had a nubmer of problems in this space
before the SpotBugs work.)
Enabling this helps to ensure non-regression so that no new equals() and
hashCode() related bugs creep in. (This does overlap a little bit with
SpotBugs, but the build time overhead to run the extra check is
completely negligible, so it seems worth having this. If only just in
case SpotBugs for whatever reason in the future would get deactivated
again.)
This has been removed in a20f76d686,
and it's confusing to look for what that means, e.g. while code
reviewing proposed "bump" changes to the used versions of
spring.gradle:dependency-management-plugin and
springframework.boot:spring-boot-gradle-plugin.
based upon code review of changes made by @awasum in previous commit:
- fix clear contains() GC_UNRELATED_TYPES bug in Loan
- fix clear equals() EC_UNRELATED_TYPES bug in Loan
- fix more equals() & hashCode() in...
* Charge
* TrialBalance
* LoanProductBorrowerCycleVariations
* LoanProductProvisioningEntry
- fix AccountingConstants to avoid using @FindBugsSuppressWarnings
- fix SelfLoansDataValidator instead of @FindBugsSuppressWarnings
- minor clean up in build.gradle (spotbugs has replaced findbugs)
PS: This change originally included also fixing the missing hashCode()
and equals() in ShareAccountCharge, but that turned out to be non
trivial, see FINERACT-827, and is thus not yet fixed by this.
This fixed bugs introduced in edc9e030e1
(in https://github.com/apache/fineract/pull/648) which for FINERACT-773
actually broke things more instead of adding the intended feature, cauz:
1. FINERACT_DEFAULT_TENANTDB_HOSTNAME and FINERACT_DEFAULT_TENANTDB_PORT
were meant to be OS Environment Variables, not Java System properties
and so need to be read via System.getenv() not System.getProperty(),
duh!
2. The Travis CI test which was meant to ensure non-regression for this
broke in that same change, because the "|| docker logs" introduced at
the same time would always pass (EITHER because "http" passed OR
if not then "docker logs" would return 0), duh again!
Both were dumb, not sure what I was thinking when I had hacked this.. ;)
SpotBugs didn't like the original version, and the initial changes made
for SpotBugs satisfied SpotBugs, but the class was still pretty weird.
This change makes it follow the regular standard builder pattern.
@awasum changed this in the SpotBugs related work, but this seems both
wrong, and, for me, makes this test now fail instead of pass (even
though for him it passed on the original PR...).
Probably related to https://issues.apache.org/jira/browse/FINERACT-820;
note that my current local time as I'm testing this is Sunday, and it
WORKS with; I'm now confused when FINERACT-820 affects us and when not.
Or perhaps this has nothing at all to do with that.
Michael Vorburger