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.
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.
Use Hikari instead of Tomcat Connection Pool
- Created hikari connection pool bean
- Configured connection parameters to match hikari
- Removed tomcat-jdbc and dbcp
- Remove unused classes
- Add Hikari to logback
- update hikaridatasource bean
closes https://issues.apache.org/jira/browse/FINERACT-796
remove hikaricp import from gradle files
more specific bean config
- Set up datasource properties
- Cleanup unused classes
- Add hikari to logback
FINERACT-736: Api Docs were updated to include rates documentation
FINERACT-735: Integration test were created for rates creation, retrieval and update
Missing permission READ_RATE
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>
* Update AbstractPersistableCustom.java
Made AbstractPersistableCustom serializable to solve org.apache.openjpa.persistence.InvalidStateException
* Update AbstractPersistableCustom.java
removed space
* 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
