[jira] [Commented] (FINERACT-959) Tighten javac compilerArgs, turn more warnings into errors (and fix related problems)
[
https://issues.apache.org/jira/browse/FINERACT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110971#comment-17110971
]
Michael Vorburger commented on FINERACT-959:
[~Percy Ashu] is adding -Xlint:cast in
https://github.com/apache/fineract/pull/908/files
> Tighten javac compilerArgs, turn more warnings into errors (and fix related
> problems)
> -
>
> Key: FINERACT-959
> URL: https://issues.apache.org/jira/browse/FINERACT-959
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
> Labels: quality, technical
>
> In the context of FINERACT-828, I just noticed that
> org.apache.fineract.notification.domain.Notification.setActor(Long) has an
> obvious bug (which I'm fixing in a PR related to FINERACT-828).
> Eclipse pointed out that particular problem - as 1 out of 888 Warnings! :P
> One thing that IMHO would be interesting and valuable in overall context of
> our ongoing code quality efforts under the umbrella of FINERACT-712 would be
> to not only (also!) increasingly engage 3rd-party Java code quality tools (as
> we already are, very much ongoing... [~Manthan] GSOC), but also leverage what
> javac can do for us!
> Something neat [~ptuomola] did in FINERACT-846 as part of our switch to Java
> 11 was to enable {{'-Xlint:unchecked'}} and {{deprecation}} warnings (search
> for this in our {{build.gradle}}). Can we turn more javac warnings into
> errors - and fix respective problems?
> [~natashan] (Outreachy, like GSOC) perhaps this is something you'd like to
> dig into?
> PS: There is also the theoretical possibility to run Eclipse's Java Compiler
> (JDT) headlessly on the build - JUST because it sometimes has more feedback
> about code than javac. http://www.lastnpe.org does this for null analysis.
> (This is much more involved than just standard {{javac}}, so we should start
> there.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-603) GSIM and GLIM support
[ https://issues.apache.org/jira/browse/FINERACT-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111077#comment-17111077 ] Francis Guchie commented on FINERACT-603: - [~awasum], the UI is not yet done, i am waiting on [~npawar] to get this done > GSIM and GLIM support > - > > Key: FINERACT-603 > URL: https://issues.apache.org/jira/browse/FINERACT-603 > Project: Apache Fineract > Issue Type: New Feature > Components: Loan, Savings >Affects Versions: 1.1.0 >Reporter: Ed Cable >Assignee: Rahul Pawar >Priority: Major > Labels: gsoc, p1 > Fix For: 1.4.0 > > Attachments: Use Case for GLIM.docx > > > Support for Group Loans with Individual Monitoring and Group Savings with > Individual Monitoring added by Nikhil Pawar with use cases and support from > iDT Labs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-932) Parent Issue for Error Logs seeing during "normal" usage (e.g. on fineract.dev)
[ https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Natasha Natarajan reassigned FINERACT-932: -- Assignee: Natasha Natarajan > Parent Issue for Error Logs seeing during "normal" usage (e.g. on > fineract.dev) > --- > > Key: FINERACT-932 > URL: https://issues.apache.org/jira/browse/FINERACT-932 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Michael Vorburger >Assignee: Natasha Natarajan >Priority: Major > > I'm seeing a number of exceptions in the logs of > [https://www.fineract.dev|https://www.fineract.dev/], and at least some if > not most of them, to me, seem like things that probably should not be logged > as errors. > IMHO, a log.error() should only be used to indicate something "broken" (e.g. > can't connect to a database), but not, typically, for something like a > missing field problem in an incoming JSON? That's "normal", and already > signaled to the client through an expected response. An "operator" can't > typically "do something" about those kinds of errors. > We can also think of some special cases, e.g. the log.error we currently for > FINERACT-726, which may be useful to help people more easily see that > widespread problem, during transitioning. But perhaps log warn or even info > instead of error would be more appropriate than error for such things? > Perhaps what I'm outlining here should be documented on the README in a > (succinct) "Log Policy" kind of section? > I'll create dedicated linked issues for each such exception I'm seeing, for > analysis by others interested. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-932) Parent Issue for Error Logs seeing during "normal" usage (e.g. on fineract.dev)
[ https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Natasha Natarajan reassigned FINERACT-932: -- Assignee: (was: Natasha Natarajan) > Parent Issue for Error Logs seeing during "normal" usage (e.g. on > fineract.dev) > --- > > Key: FINERACT-932 > URL: https://issues.apache.org/jira/browse/FINERACT-932 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Michael Vorburger >Priority: Major > > I'm seeing a number of exceptions in the logs of > [https://www.fineract.dev|https://www.fineract.dev/], and at least some if > not most of them, to me, seem like things that probably should not be logged > as errors. > IMHO, a log.error() should only be used to indicate something "broken" (e.g. > can't connect to a database), but not, typically, for something like a > missing field problem in an incoming JSON? That's "normal", and already > signaled to the client through an expected response. An "operator" can't > typically "do something" about those kinds of errors. > We can also think of some special cases, e.g. the log.error we currently for > FINERACT-726, which may be useful to help people more easily see that > widespread problem, during transitioning. But perhaps log warn or even info > instead of error would be more appropriate than error for such things? > Perhaps what I'm outlining here should be documented on the README in a > (succinct) "Log Policy" kind of section? > I'll create dedicated linked issues for each such exception I'm seeing, for > analysis by others interested. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-933) ArrayIndexOutOfBoundsException at ClientPersonImportHandler
[
https://issues.apache.org/jira/browse/FINERACT-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Natasha Natarajan reassigned FINERACT-933:
--
Assignee: Natasha Natarajan
> ArrayIndexOutOfBoundsException at ClientPersonImportHandler
> ---
>
> Key: FINERACT-933
> URL: https://issues.apache.org/jira/browse/FINERACT-933
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Natasha Natarajan
>Priority: Major
>
> See FINERACT-932 for general background, and determine if this error log can
> and should be "fixed", or if this represents a condition that shouldn't be
> logged as an error (or conclude that this is a totally valid error log that
> is useful, any why):
> {code}java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.readClient(ClientPersonImportHandler.java:149)
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.readExcelFile(ClientPersonImportHandler.java:75)
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.process(ClientPersonImportHandler.java:64)
> at
> org.apache.fineract.infrastructure.bulkimport.service.BulkImportEventListener.onApplicationEvent(BulkImportEventListener.java:143)
> at
> org.apache.fineract.infrastructure.bulkimport.service.BulkImportEventListener.onApplicationEvent(BulkImportEventListener.java:47)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.lambda$multicastEvent$0(SimpleApplicationEventMulticaster.java:136)
> at java.lang.Thread.run (Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-932) Parent Issue for Error Logs seeing during "normal" usage (e.g. on fineract.dev)
[ https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Natasha Natarajan updated FINERACT-932: --- Description: I'm seeing a number of exceptions in the logs of [https://www.fineract.dev|https://www.fineract.dev/], and at least some if not most of them, to me, seem like things that probably should not be logged as errors. IMHO, a log.error() should only be used to indicate something "broken" (e.g. can't connect to a database), but not, typically, for something like a missing field problem in an incoming JSON? That's "normal", and already signaled to th e client through an expected response. An "operator" can't typically "do something" about those kinds of errors. We can also think of some special cases, e.g. the log.error we currently for FINERACT-726, which may be useful to help people more easily see that widespread problem, during transitioning. But perhaps log warn or even info instead of error would be more appropriate than error for such things? Perhaps what I'm outlining here should be documented on the README in a (succinct) "Log Policy" kind of section? I'll create dedicated linked issues for each such exception I'm seeing, for analysis by others interested. was: I'm seeing a number of exceptions in the logs of [https://www.fineract.dev|https://www.fineract.dev/], and at least some if not most of them, to me, seem like things that probably should not be logged as errors. IMHO, a log.error() should only be used to indicate something "broken" (e.g. can't connect to a database), but not, typically, for something like a missing field problem in an incoming JSON? That's "normal", and already signaled to the client through an expected response. An "operator" can't typically "do something" about those kinds of errors. We can also think of some special cases, e.g. the log.error we currently for FINERACT-726, which may be useful to help people more easily see that widespread problem, during transitioning. But perhaps log warn or even info instead of error would be more appropriate than error for such things? Perhaps what I'm outlining here should be documented on the README in a (succinct) "Log Policy" kind of section? I'll create dedicated linked issues for each such exception I'm seeing, for analysis by others interested. > Parent Issue for Error Logs seeing during "normal" usage (e.g. on > fineract.dev) > --- > > Key: FINERACT-932 > URL: https://issues.apache.org/jira/browse/FINERACT-932 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Michael Vorburger >Priority: Major > > I'm seeing a number of exceptions in the logs of > [https://www.fineract.dev|https://www.fineract.dev/], and at least some if > not most of them, to me, seem like things that probably should not be logged > as errors. > IMHO, a log.error() should only be used to indicate something "broken" (e.g. > can't connect to a database), but not, typically, for something like a > missing field problem in an incoming JSON? That's "normal", and already > signaled to th e client through an expected response. An "operator" can't > typically "do something" about those kinds of errors. > We can also think of some special cases, e.g. the log.error we currently for > FINERACT-726, which may be useful to help people more easily see that > widespread problem, during transitioning. But perhaps log warn or even info > instead of error would be more appropriate than error for such things? > Perhaps what I'm outlining here should be documented on the README in a > (succinct) "Log Policy" kind of section? > I'll create dedicated linked issues for each such exception I'm seeing, for > analysis by others interested. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-909) Remove Tomcat Welcome Default App from Fineract Container
[
https://issues.apache.org/jira/browse/FINERACT-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111432#comment-17111432
]
Petri Tuomola commented on FINERACT-909:
This probably will not be required after FINERACT-830, as we will then no
longer be using the Bitnami Tomcat image as a base
> Remove Tomcat Welcome Default App from Fineract Container
> -
>
> Key: FINERACT-909
> URL: https://issues.apache.org/jira/browse/FINERACT-909
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
>
> The Fineract Container currently includes the the Tomcat Welcome Default App
> (the usual same old, with that welcome page, it can currently be seen e.g. on
> [https://demo.fineract.dev|https://demo.fineract.dev/]).
> This is so so because it's in that Bitnami Base Image we currently use. It's
> a bit confusing when using the container, is totally unnecessary, eats a bit
> of memory, and bloats the container size (slightly).
> It should be a trivial to yank it with an appropriate {{RUN rm ...}} in the
> Dockerfile.
> FINERACT-730 will eventually change the deployment model and container, but
> until we (finally...) do that, and because that's a bit more work whereas
> this is be a quick low hanging fruit, we should still do this if anyone is
> wiling to pick this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FINERACT-909) Remove Tomcat Welcome Default App from Fineract Container
[
https://issues.apache.org/jira/browse/FINERACT-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger closed FINERACT-909.
--
Resolution: Duplicate
> Remove Tomcat Welcome Default App from Fineract Container
> -
>
> Key: FINERACT-909
> URL: https://issues.apache.org/jira/browse/FINERACT-909
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
>
> The Fineract Container currently includes the the Tomcat Welcome Default App
> (the usual same old, with that welcome page, it can currently be seen e.g. on
> [https://demo.fineract.dev|https://demo.fineract.dev/]).
> This is so so because it's in that Bitnami Base Image we currently use. It's
> a bit confusing when using the container, is totally unnecessary, eats a bit
> of memory, and bloats the container size (slightly).
> It should be a trivial to yank it with an appropriate {{RUN rm ...}} in the
> Dockerfile.
> FINERACT-730 will eventually change the deployment model and container, but
> until we (finally...) do that, and because that's a bit more work whereas
> this is be a quick low hanging fruit, we should still do this if anyone is
> wiling to pick this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-909) Remove Tomcat Welcome Default App from Fineract Container
[
https://issues.apache.org/jira/browse/FINERACT-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-909:
---
Fix Version/s: 1.4.0
> Remove Tomcat Welcome Default App from Fineract Container
> -
>
> Key: FINERACT-909
> URL: https://issues.apache.org/jira/browse/FINERACT-909
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> The Fineract Container currently includes the the Tomcat Welcome Default App
> (the usual same old, with that welcome page, it can currently be seen e.g. on
> [https://demo.fineract.dev|https://demo.fineract.dev/]).
> This is so so because it's in that Bitnami Base Image we currently use. It's
> a bit confusing when using the container, is totally unnecessary, eats a bit
> of memory, and bloats the container size (slightly).
> It should be a trivial to yank it with an appropriate {{RUN rm ...}} in the
> Dockerfile.
> FINERACT-730 will eventually change the deployment model and container, but
> until we (finally...) do that, and because that's a bit more work whereas
> this is be a quick low hanging fruit, we should still do this if anyone is
> wiling to pick this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (FINERACT-909) Remove Tomcat Welcome Default App from Fineract Container
[
https://issues.apache.org/jira/browse/FINERACT-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger reopened FINERACT-909:
Assignee: Michael Vorburger
> Remove Tomcat Welcome Default App from Fineract Container
> -
>
> Key: FINERACT-909
> URL: https://issues.apache.org/jira/browse/FINERACT-909
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
>
> The Fineract Container currently includes the the Tomcat Welcome Default App
> (the usual same old, with that welcome page, it can currently be seen e.g. on
> [https://demo.fineract.dev|https://demo.fineract.dev/]).
> This is so so because it's in that Bitnami Base Image we currently use. It's
> a bit confusing when using the container, is totally unnecessary, eats a bit
> of memory, and bloats the container size (slightly).
> It should be a trivial to yank it with an appropriate {{RUN rm ...}} in the
> Dockerfile.
> FINERACT-730 will eventually change the deployment model and container, but
> until we (finally...) do that, and because that's a bit more work whereas
> this is be a quick low hanging fruit, we should still do this if anyone is
> wiling to pick this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FINERACT-909) Remove Tomcat Welcome Default App from Fineract Container
[
https://issues.apache.org/jira/browse/FINERACT-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger closed FINERACT-909.
--
Resolution: Duplicate
> Remove Tomcat Welcome Default App from Fineract Container
> -
>
> Key: FINERACT-909
> URL: https://issues.apache.org/jira/browse/FINERACT-909
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> The Fineract Container currently includes the the Tomcat Welcome Default App
> (the usual same old, with that welcome page, it can currently be seen e.g. on
> [https://demo.fineract.dev|https://demo.fineract.dev/]).
> This is so so because it's in that Bitnami Base Image we currently use. It's
> a bit confusing when using the container, is totally unnecessary, eats a bit
> of memory, and bloats the container size (slightly).
> It should be a trivial to yank it with an appropriate {{RUN rm ...}} in the
> Dockerfile.
> FINERACT-730 will eventually change the deployment model and container, but
> until we (finally...) do that, and because that's a bit more work whereas
> this is be a quick low hanging fruit, we should still do this if anyone is
> wiling to pick this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-962) Use Renovate for Fineract
[ https://issues.apache.org/jira/browse/FINERACT-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111515#comment-17111515 ] Michael Vorburger commented on FINERACT-962: I want to wait with enabling this until we're done with FINERACT-963, otherwise it will just a number of PRs we already know we need to do. > Use Renovate for Fineract > -- > > Key: FINERACT-962 > URL: https://issues.apache.org/jira/browse/FINERACT-962 > Project: Apache Fineract > Issue Type: Sub-task > Components: Build >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Labels: dependencies, tech-debt, technical > > https://renovate.whitesourcesoftware.com > Based solely on comparing the initial list on > https://github.com/vorburger/fineract/pull/2 VS > https://github.com/vorburger/fineract/pulls?q=is%3Apr+author%3Aapp%2Fdependabot-preview+, > Renovate and Dependabot seem to find similar results. It could still be fun > to run them both? > INFRA-19586 explains that ASF can't accept the Renovate GitHub App. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-963) Upgrade about 15 of our 3rd-party libraries to their latest versions
[ https://issues.apache.org/jira/browse/FINERACT-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111518#comment-17111518 ] Michael Vorburger commented on FINERACT-963: https://github.com/apache/fineract/pull/910 proposes new doc how to go about these upgrades. > Upgrade about 15 of our 3rd-party libraries to their latest versions > > > Key: FINERACT-963 > URL: https://issues.apache.org/jira/browse/FINERACT-963 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.4.0 > > > Using FINERACT-961, I'm doing a "bulk" upgrade of our 3rd-party libraries. > The approach I've used was to simply raise PRs for every proposal from > Dependabot. > We'll review and merge those that are green. I'll close those that are red - > and create linked issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-962) Use Renovate for Fineract
[ https://issues.apache.org/jira/browse/FINERACT-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111519#comment-17111519 ] Michael Vorburger commented on FINERACT-962: https://github.com/apache/fineract/pull/910 proposes new doc how to go about these upgrades. > Use Renovate for Fineract > -- > > Key: FINERACT-962 > URL: https://issues.apache.org/jira/browse/FINERACT-962 > Project: Apache Fineract > Issue Type: Sub-task > Components: Build >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Labels: dependencies, tech-debt, technical > > https://renovate.whitesourcesoftware.com > Based solely on comparing the initial list on > https://github.com/vorburger/fineract/pull/2 VS > https://github.com/vorburger/fineract/pulls?q=is%3Apr+author%3Aapp%2Fdependabot-preview+, > Renovate and Dependabot seem to find similar results. It could still be fun > to run them both? > INFRA-19586 explains that ASF can't accept the Renovate GitHub App. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-953) Upgrade ical4j from ancient version 1.0.7 to current 3.0.18
[ https://issues.apache.org/jira/browse/FINERACT-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111527#comment-17111527 ] Michael Vorburger commented on FINERACT-953: https://github.com/apache/fineract/pull/907 https://github.com/apache/fineract/pull/911 > Upgrade ical4j from ancient version 1.0.7 to current 3.0.18 > --- > > Key: FINERACT-953 > URL: https://issues.apache.org/jira/browse/FINERACT-953 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Reporter: Michael Vorburger >Assignee: Natasha Natarajan >Priority: Critical > Labels: technical > > Note that package names have changed and will need to be bulk replaced. > Note that ical4j:1.0.7 depended on commons-lang:2.6, which was in mixed use > in Fineract, but with FINERACT-954 isn't anymore (or shouldn't be; replace > any occurrences that crept back in when working on this). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-933) ArrayIndexOutOfBoundsException at ClientPersonImportHandler
[
https://issues.apache.org/jira/browse/FINERACT-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-933:
---
Fix Version/s: 1.4.0
> ArrayIndexOutOfBoundsException at ClientPersonImportHandler
> ---
>
> Key: FINERACT-933
> URL: https://issues.apache.org/jira/browse/FINERACT-933
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Natasha Natarajan
>Priority: Major
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background, and determine if this error log can
> and should be "fixed", or if this represents a condition that shouldn't be
> logged as an error (or conclude that this is a totally valid error log that
> is useful, any why):
> {code}java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.readClient(ClientPersonImportHandler.java:149)
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.readExcelFile(ClientPersonImportHandler.java:75)
> at
> org.apache.fineract.infrastructure.bulkimport.importhandler.client.ClientPersonImportHandler.process(ClientPersonImportHandler.java:64)
> at
> org.apache.fineract.infrastructure.bulkimport.service.BulkImportEventListener.onApplicationEvent(BulkImportEventListener.java:143)
> at
> org.apache.fineract.infrastructure.bulkimport.service.BulkImportEventListener.onApplicationEvent(BulkImportEventListener.java:47)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.lambda$multicastEvent$0(SimpleApplicationEventMulticaster.java:136)
> at java.lang.Thread.run (Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FINERACT-983) /actuator/info is empty in container
[
https://issues.apache.org/jira/browse/FINERACT-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger resolved FINERACT-983.
Resolution: Fixed
> /actuator/info is empty in container
>
>
> Key: FINERACT-983
> URL: https://issues.apache.org/jira/browse/FINERACT-983
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> [https://demo.fineract.dev/fineract-provider/actuator/info] is empty -
> FINERACT-883 does not work there. It does work locally though. The difference
> is that Fineract.dev uses the container. The /actuator/info is empty in the
> container.
> It's because the .git/** doesn't get copied into the container. We should
> {{ADD}} it, I guess?
> FINERACT-911 is an indirectly related problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-975) /tmp needs to be writeable in container
[
https://issues.apache.org/jira/browse/FINERACT-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-975:
---
Fix Version/s: 1.4.0
> /tmp needs to be writeable in container
> ---
>
> Key: FINERACT-975
> URL: https://issues.apache.org/jira/browse/FINERACT-975
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background. This error log can and should be
> "fixed":
> {noformat}java.nio.file.AccessDeniedException:
> /opt/bitnami/tomcat/temp/MIME5202211049703909640.tmp
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:90)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:111)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:116)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:219)
> at java.nio.file.Files.newByteChannel (Files.java:370)
> at java.nio.file.Files.createFile (Files.java:647)
> at java.nio.file.TempFileHelper.create (TempFileHelper.java:137)
> at java.nio.file.TempFileHelper.createTempFile
> (TempFileHelper.java:160)
> at java.nio.file.Files.createTempFile (Files.java:912)
> at org.jvnet.mimepull.MemoryData.createTempFile (MemoryData.java:100)
> at org.jvnet.mimepull.MemoryData.createNext (MemoryData.java:70)
> at org.jvnet.mimepull.Chunk.createNext (Chunk.java:34)
> at org.jvnet.mimepull.DataHead.addBody (DataHead.java:57)
> at org.jvnet.mimepull.MIMEPart.addBody (MIMEPart.java:214)
> at org.jvnet.mimepull.MIMEMessage.makeProgress (MIMEMessage.java:242)
> at org.jvnet.mimepull.MIMEMessage.parseAll (MIMEMessage.java:160)
> at org.jvnet.mimepull.MIMEMessage.getAttachments (MIMEMessage.java:86)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readMultiPart
> (MultiPartReaderClientSide.java:205)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderServerSide.readMultiPart
> (MultiPartReaderServerSide.java:80)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:158)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:85)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:490)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:555)
> at
> com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider$FormDataInjectableValuesProvider.getInjectableValues
> (FormDataMultiPartDispatchProvider.java:122)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$EntityParamInInvoker.getParams
> (AbstractResourceMethodDispatchProvider.java:153)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch
> (AbstractResourceMethodDispatchProvider.java:183)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch
> (ResourceJavaMethodDispatcher.java:75)
> at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept
> (HttpMethodRule.java:302)
> at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept
> (ResourceClassRule.java:108)
> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept
> (RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept
> (RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1542)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1473)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1419)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1409)
> at com.sun.jersey.spi.container.servlet.WebComponent.service
> (WebComponent.java:409)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:558)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:733)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:741)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:231)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilt
[jira] [Updated] (FINERACT-975) /tmp needs to be writeable in container
[
https://issues.apache.org/jira/browse/FINERACT-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-975:
---
Affects Version/s: 1.4.0
> /tmp needs to be writeable in container
> ---
>
> Key: FINERACT-975
> URL: https://issues.apache.org/jira/browse/FINERACT-975
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background. This error log can and should be
> "fixed":
> {noformat}java.nio.file.AccessDeniedException:
> /opt/bitnami/tomcat/temp/MIME5202211049703909640.tmp
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:90)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:111)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:116)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:219)
> at java.nio.file.Files.newByteChannel (Files.java:370)
> at java.nio.file.Files.createFile (Files.java:647)
> at java.nio.file.TempFileHelper.create (TempFileHelper.java:137)
> at java.nio.file.TempFileHelper.createTempFile
> (TempFileHelper.java:160)
> at java.nio.file.Files.createTempFile (Files.java:912)
> at org.jvnet.mimepull.MemoryData.createTempFile (MemoryData.java:100)
> at org.jvnet.mimepull.MemoryData.createNext (MemoryData.java:70)
> at org.jvnet.mimepull.Chunk.createNext (Chunk.java:34)
> at org.jvnet.mimepull.DataHead.addBody (DataHead.java:57)
> at org.jvnet.mimepull.MIMEPart.addBody (MIMEPart.java:214)
> at org.jvnet.mimepull.MIMEMessage.makeProgress (MIMEMessage.java:242)
> at org.jvnet.mimepull.MIMEMessage.parseAll (MIMEMessage.java:160)
> at org.jvnet.mimepull.MIMEMessage.getAttachments (MIMEMessage.java:86)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readMultiPart
> (MultiPartReaderClientSide.java:205)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderServerSide.readMultiPart
> (MultiPartReaderServerSide.java:80)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:158)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:85)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:490)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:555)
> at
> com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider$FormDataInjectableValuesProvider.getInjectableValues
> (FormDataMultiPartDispatchProvider.java:122)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$EntityParamInInvoker.getParams
> (AbstractResourceMethodDispatchProvider.java:153)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch
> (AbstractResourceMethodDispatchProvider.java:183)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch
> (ResourceJavaMethodDispatcher.java:75)
> at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept
> (HttpMethodRule.java:302)
> at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept
> (ResourceClassRule.java:108)
> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept
> (RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept
> (RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1542)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1473)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1419)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1409)
> at com.sun.jersey.spi.container.servlet.WebComponent.service
> (WebComponent.java:409)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:558)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:733)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:741)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:231)
> at org.apache.catalina.core.ApplicationFilterC
[jira] [Closed] (FINERACT-975) /tmp needs to be writeable in container
[
https://issues.apache.org/jira/browse/FINERACT-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger closed FINERACT-975.
--
Resolution: Duplicate
> /tmp needs to be writeable in container
> ---
>
> Key: FINERACT-975
> URL: https://issues.apache.org/jira/browse/FINERACT-975
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background. This error log can and should be
> "fixed":
> {noformat}java.nio.file.AccessDeniedException:
> /opt/bitnami/tomcat/temp/MIME5202211049703909640.tmp
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:90)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:111)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:116)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:219)
> at java.nio.file.Files.newByteChannel (Files.java:370)
> at java.nio.file.Files.createFile (Files.java:647)
> at java.nio.file.TempFileHelper.create (TempFileHelper.java:137)
> at java.nio.file.TempFileHelper.createTempFile
> (TempFileHelper.java:160)
> at java.nio.file.Files.createTempFile (Files.java:912)
> at org.jvnet.mimepull.MemoryData.createTempFile (MemoryData.java:100)
> at org.jvnet.mimepull.MemoryData.createNext (MemoryData.java:70)
> at org.jvnet.mimepull.Chunk.createNext (Chunk.java:34)
> at org.jvnet.mimepull.DataHead.addBody (DataHead.java:57)
> at org.jvnet.mimepull.MIMEPart.addBody (MIMEPart.java:214)
> at org.jvnet.mimepull.MIMEMessage.makeProgress (MIMEMessage.java:242)
> at org.jvnet.mimepull.MIMEMessage.parseAll (MIMEMessage.java:160)
> at org.jvnet.mimepull.MIMEMessage.getAttachments (MIMEMessage.java:86)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readMultiPart
> (MultiPartReaderClientSide.java:205)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderServerSide.readMultiPart
> (MultiPartReaderServerSide.java:80)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:158)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:85)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:490)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:555)
> at
> com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider$FormDataInjectableValuesProvider.getInjectableValues
> (FormDataMultiPartDispatchProvider.java:122)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$EntityParamInInvoker.getParams
> (AbstractResourceMethodDispatchProvider.java:153)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch
> (AbstractResourceMethodDispatchProvider.java:183)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch
> (ResourceJavaMethodDispatcher.java:75)
> at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept
> (HttpMethodRule.java:302)
> at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept
> (ResourceClassRule.java:108)
> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept
> (RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept
> (RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1542)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1473)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1419)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1409)
> at com.sun.jersey.spi.container.servlet.WebComponent.service
> (WebComponent.java:409)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:558)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:733)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:741)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:231)
> at org.apa
[jira] [Assigned] (FINERACT-975) /tmp needs to be writeable in container
[
https://issues.apache.org/jira/browse/FINERACT-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger reassigned FINERACT-975:
--
Assignee: Michael Vorburger
> /tmp needs to be writeable in container
> ---
>
> Key: FINERACT-975
> URL: https://issues.apache.org/jira/browse/FINERACT-975
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background. This error log can and should be
> "fixed":
> {noformat}java.nio.file.AccessDeniedException:
> /opt/bitnami/tomcat/temp/MIME5202211049703909640.tmp
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:90)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:111)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:116)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:219)
> at java.nio.file.Files.newByteChannel (Files.java:370)
> at java.nio.file.Files.createFile (Files.java:647)
> at java.nio.file.TempFileHelper.create (TempFileHelper.java:137)
> at java.nio.file.TempFileHelper.createTempFile
> (TempFileHelper.java:160)
> at java.nio.file.Files.createTempFile (Files.java:912)
> at org.jvnet.mimepull.MemoryData.createTempFile (MemoryData.java:100)
> at org.jvnet.mimepull.MemoryData.createNext (MemoryData.java:70)
> at org.jvnet.mimepull.Chunk.createNext (Chunk.java:34)
> at org.jvnet.mimepull.DataHead.addBody (DataHead.java:57)
> at org.jvnet.mimepull.MIMEPart.addBody (MIMEPart.java:214)
> at org.jvnet.mimepull.MIMEMessage.makeProgress (MIMEMessage.java:242)
> at org.jvnet.mimepull.MIMEMessage.parseAll (MIMEMessage.java:160)
> at org.jvnet.mimepull.MIMEMessage.getAttachments (MIMEMessage.java:86)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readMultiPart
> (MultiPartReaderClientSide.java:205)
> at
> com.sun.jersey.multipart.impl.MultiPartReaderServerSide.readMultiPart
> (MultiPartReaderServerSide.java:80)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:158)
> at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom
> (MultiPartReaderClientSide.java:85)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:490)
> at com.sun.jersey.spi.container.ContainerRequest.getEntity
> (ContainerRequest.java:555)
> at
> com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider$FormDataInjectableValuesProvider.getInjectableValues
> (FormDataMultiPartDispatchProvider.java:122)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$EntityParamInInvoker.getParams
> (AbstractResourceMethodDispatchProvider.java:153)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch
> (AbstractResourceMethodDispatchProvider.java:183)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch
> (ResourceJavaMethodDispatcher.java:75)
> at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept
> (HttpMethodRule.java:302)
> at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept
> (ResourceClassRule.java:108)
> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept
> (RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept
> (RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1542)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest
> (WebApplicationImpl.java:1473)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1419)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
> (WebApplicationImpl.java:1409)
> at com.sun.jersey.spi.container.servlet.WebComponent.service
> (WebComponent.java:409)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:558)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:733)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:741)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:231)
>
[jira] [Updated] (FINERACT-959) Tighten javac compilerArgs, turn more warnings into errors (and fix related problems)
[
https://issues.apache.org/jira/browse/FINERACT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-959:
---
Fix Version/s: 1.4.0
> Tighten javac compilerArgs, turn more warnings into errors (and fix related
> problems)
> -
>
> Key: FINERACT-959
> URL: https://issues.apache.org/jira/browse/FINERACT-959
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
> Labels: quality, technical
> Fix For: 1.4.0
>
>
> In the context of FINERACT-828, I just noticed that
> org.apache.fineract.notification.domain.Notification.setActor(Long) has an
> obvious bug (which I'm fixing in a PR related to FINERACT-828).
> Eclipse pointed out that particular problem - as 1 out of 888 Warnings! :P
> One thing that IMHO would be interesting and valuable in overall context of
> our ongoing code quality efforts under the umbrella of FINERACT-712 would be
> to not only (also!) increasingly engage 3rd-party Java code quality tools (as
> we already are, very much ongoing... [~Manthan] GSOC), but also leverage what
> javac can do for us!
> Something neat [~ptuomola] did in FINERACT-846 as part of our switch to Java
> 11 was to enable {{'-Xlint:unchecked'}} and {{deprecation}} warnings (search
> for this in our {{build.gradle}}). Can we turn more javac warnings into
> errors - and fix respective problems?
> [~natashan] (Outreachy, like GSOC) perhaps this is something you'd like to
> dig into?
> PS: There is also the theoretical possibility to run Eclipse's Java Compiler
> (JDT) headlessly on the build - JUST because it sometimes has more feedback
> about code than javac. http://www.lastnpe.org does this for null analysis.
> (This is much more involved than just standard {{javac}}, so we should start
> there.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-725) Measure unit test code coverage
[ https://issues.apache.org/jira/browse/FINERACT-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-725: --- Summary: Measure unit test code coverage (was: Measure current code coverage) > Measure unit test code coverage > --- > > Key: FINERACT-725 > URL: https://issues.apache.org/jira/browse/FINERACT-725 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Vishwas Babu A J >Assignee: Manthan Surkar >Priority: Major > Labels: beginner, starter > Fix For: 1.4.0 > > > Integrate a plugin like > [https://docs.gradle.org/current/userguide/jacoco_plugin.html] and generate > the code coverage report for running integration tests on Fineract. > Using this report, we can quickly determine which package have low code > coverage and work on remediating the same -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-985) Measure integration test code coverage
Michael Vorburger created FINERACT-985: -- Summary: Measure integration test code coverage Key: FINERACT-985 URL: https://issues.apache.org/jira/browse/FINERACT-985 Project: Apache Fineract Issue Type: Improvement Reporter: Michael Vorburger I just realized (this wasn't clear at least to me before) that FINERACT-725 only added code coverage for unit tests. In Fineract that's certainly of some but ultimately more limited value - because the project has very few unit tests, but relies more on integration tests... The goal of this new issue to make it possible to have integration test coverage as well. Jacoco is easy to set up for unit tests, but for integration tests, we would need to instrument the WAR which the Gradle Cargo plugin deploys into Tomcat - which is a little more challenging... (or we change how we do integration tests all together). [~Manthan] [~ptuomola] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time
[ https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111600#comment-17111600 ] Michael Vorburger commented on FINERACT-713: FINERACT-985 to measure integration test code coverage would be required first for more here. > Improve code-coverage to at-least 50% and reduce execution time > --- > > Key: FINERACT-713 > URL: https://issues.apache.org/jira/browse/FINERACT-713 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Vishwas Babu A J >Priority: Major > Labels: gsoc2019 > Original Estimate: 336h > Remaining Estimate: 336h > > While Fineract has integration tests, they currently cover very limited > scenarios and code coverage is very low. > Enable gradle plugins to report the current code coverage and add new > Integration tests to ensure that code coverage, esp in critical packages like > loans, savings, and accounting is at-least 50%. Once the packages with low > code coverage have been identified, we could take the help of [~santoshmath] > to collect manual test cases covering these packages and go about automating > the same. > Also, the existing tests are run sequentially and take around 23 minutes to > complete on [https://travis-ci.org/apache/fineract.] Along with improving > code coverage, we would also have to determine which tests can be run in > parallel and enable parallelization to ensure the total time taken is still > reasonable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-725) Measure unit test code coverage
[ https://issues.apache.org/jira/browse/FINERACT-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111599#comment-17111599 ] Michael Vorburger commented on FINERACT-725: Doc for this is on https://github.com/apache/fineract#code-coverage-reports, BUT this was unit tests only - new FINERACT-985 for missing ITs! > Measure unit test code coverage > --- > > Key: FINERACT-725 > URL: https://issues.apache.org/jira/browse/FINERACT-725 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Vishwas Babu A J >Assignee: Manthan Surkar >Priority: Major > Labels: beginner, starter > Fix For: 1.4.0 > > > Integrate a plugin like > [https://docs.gradle.org/current/userguide/jacoco_plugin.html] and generate > the code coverage report for running integration tests on Fineract. > Using this report, we can quickly determine which package have low code > coverage and work on remediating the same -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-964) Bump json-path from 0.9.1 to 2.4.0
[ https://issues.apache.org/jira/browse/FINERACT-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger reassigned FINERACT-964: -- Assignee: Yemdjih Kaze Nasser (was: Michael Vorburger) > Bump json-path from 0.9.1 to 2.4.0 > -- > > Key: FINERACT-964 > URL: https://issues.apache.org/jira/browse/FINERACT-964 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Critical > Fix For: 1.4.0 > > > FINERACT-963 proposed https://github.com/apache/fineract/pull/866 and it > failed because of package changes, but they may be easy to fix. I'm going > through this "in bulk" so won't have a closer look, but I'm hoping one of our > GSOC students will take this issue on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FINERACT-964) Bump json-path from 0.9.1 to 2.4.0
[ https://issues.apache.org/jira/browse/FINERACT-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger resolved FINERACT-964. Resolution: Fixed > Bump json-path from 0.9.1 to 2.4.0 > -- > > Key: FINERACT-964 > URL: https://issues.apache.org/jira/browse/FINERACT-964 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Critical > Fix For: 1.4.0 > > > FINERACT-963 proposed https://github.com/apache/fineract/pull/866 and it > failed because of package changes, but they may be easy to fix. I'm going > through this "in bulk" so won't have a closer look, but I'm hoping one of our > GSOC students will take this issue on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-964) Bump json-path from 0.9.1 to 2.4.0
[ https://issues.apache.org/jira/browse/FINERACT-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger reassigned FINERACT-964: -- Assignee: Michael Vorburger (was: Yemdjih Kaze Nasser) > Bump json-path from 0.9.1 to 2.4.0 > -- > > Key: FINERACT-964 > URL: https://issues.apache.org/jira/browse/FINERACT-964 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Critical > Fix For: 1.4.0 > > > FINERACT-963 proposed https://github.com/apache/fineract/pull/866 and it > failed because of package changes, but they may be easy to fix. I'm going > through this "in bulk" so won't have a closer look, but I'm hoping one of our > GSOC students will take this issue on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-985) Measure integration test code coverage
[ https://issues.apache.org/jira/browse/FINERACT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111635#comment-17111635 ] Manthan Surkar commented on FINERACT-985: - Hello [~vorburger], I would like to pick this up. Just to make sure [~Percy Ashu] (github-percyashu) is this part of your GSoC (I happen to read your project abstract)? If it is if you are not immediately into it can I pick this? > Measure integration test code coverage > -- > > Key: FINERACT-985 > URL: https://issues.apache.org/jira/browse/FINERACT-985 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Priority: Major > > I just realized (this wasn't clear at least to me before) that FINERACT-725 > only added code coverage for unit tests. In Fineract that's certainly of some > but ultimately more limited value - because the project has very few unit > tests, but relies more on integration tests... > The goal of this new issue to make it possible to have integration test > coverage as well. > Jacoco is easy to set up for unit tests, but for integration tests, we would > need to instrument the WAR which the Gradle Cargo plugin deploys into Tomcat > - which is a little more challenging... (or we change how we do integration > tests all together). > [~Manthan] [~ptuomola] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-978) java.lang.reflect.InvocationTargetException at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) Caused by: java.lang.IllegalStateException: Lo
[
https://issues.apache.org/jira/browse/FINERACT-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111727#comment-17111727
]
Petri Tuomola commented on FINERACT-978:
[~vorburger] - is there an easy way to reproduce this? Happy to take a look,
but I wasn't able to get this error message when running locally...
> java.lang.reflect.InvocationTargetException at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) Caused
> by: java.lang.IllegalStateException: Logback configuration error detected:
> -
>
> Key: FINERACT-978
> URL: https://issues.apache.org/jira/browse/FINERACT-978
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
>
> See FINERACT-932 for general background:
> {noformat}Exception in thread "main"
> java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
> at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
> at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
> at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
> Caused by: java.lang.IllegalStateException: Logback configuration error
> detected:{noformat}
> This error log smells like some Java 11 related issue in Logback?
> [~ptuomola] thought this may interest you or you may know more about this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-985) Measure integration test code coverage
[ https://issues.apache.org/jira/browse/FINERACT-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111810#comment-17111810 ] Percy Ashu commented on FINERACT-985: - [~Manthan] yeah think looking at https://issues.apache.org/jira/browse/FINERACT-865. > Measure integration test code coverage > -- > > Key: FINERACT-985 > URL: https://issues.apache.org/jira/browse/FINERACT-985 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Priority: Major > > I just realized (this wasn't clear at least to me before) that FINERACT-725 > only added code coverage for unit tests. In Fineract that's certainly of some > but ultimately more limited value - because the project has very few unit > tests, but relies more on integration tests... > The goal of this new issue to make it possible to have integration test > coverage as well. > Jacoco is easy to set up for unit tests, but for integration tests, we would > need to instrument the WAR which the Gradle Cargo plugin deploys into Tomcat > - which is a little more challenging... (or we change how we do integration > tests all together). > [~Manthan] [~ptuomola] -- This message was sent by Atlassian Jira (v8.3.4#803005)
