Hello!

I have raw implementation for (https://issues.apache.org/jira/browse/FINER
<https://issues.apache.org/jira/browse/FINERACT-724>FINERACT-724
<https://issues.apache.org/jira/browse/FINERACT-724>FINERACT-724
<https://issues.apache.org/jira/browse/FINERACT-724>ACT-724
<https://issues.apache.org/jira/browse/FINERACT-724> Upgrade Spring Boot,
Spring and Spring Security to their latest stable version).
This version compiles and all integration tests are passing.
But I have done quite horrible things for Spring5/OpenJpa integration.
OpenJpa is a pain, but as I understand we can't use Hibernate due to
license restrictions.
But why we can't use Eclipse link?
Also I would like propose to move from JAX-RS to Spring MVC.

Could you have a look?

Thanks,
Ivan


ср, 2 окт. 2019 г. в 10:08, Michael Vorburger <[email protected]>:

> On Wed, Oct 2, 2019 at 8:07 AM Ivan Bondarenko <[email protected]> wrote:
>
>> Hello Michael !
>>
>> Thank you, it was gradle daemon issue.
>> I use Intellig Idea and this IDE works with gradle daemon by default.
>>
>
> cool, glad we were able to solve that.
>
> I have one more question:
>>
>> Is there any reason for old version of tomcat in dev dependencies?
>>
>
> not really - you can certainly try to upgrade it - pull requests (which
> still pass ITs on Travis..) are certainly welcome. However, In terms of
> focusing energy, I personally would much rather welcome any contributions
> re. below to help us move off external WAR and Tomact and to full Spring
> Boot (with embedded Tomcat), if you know what I mean. Moving to a newer
> Tomcat version, but staying with the current model, and
> gradle-tomcat-plugin, is of more limited value, IMHO.
>
>
>> def tomcatVersion = '7.0.54'
>> while in prod
>> def tomcatVersion = '7.0.94'
>>
>> It is really interesting for me to help you with gradle-tomcat-plugin.
>> How can I join to you in this work?
>>
>
> read up on and start contributing (as in, send us Pull Requests..), or if
> needed ask more specific technical questions re. these open issues, in
> order of priority:
>
> 1. https://issues.apache.org/jira/browse/FINERACT-764 Run Integration
> Tests using Spring Boot IT support instead of on Tomcat started separately
> by gradle-tomcat-plugin
>
> 2. https://issues.apache.org/jira/browse/FINERACT-730 Fix failing gradle
> task bootRun & can't run simple Spring Boot java -jar (without Tomcat)
>
> 3. https://issues.apache.org/jira/browse/FINER
> <https://issues.apache.org/jira/browse/FINERACT-724>FINERACT-724
> <https://issues.apache.org/jira/browse/FINERACT-724>FINERACT-724
> <https://issues.apache.org/jira/browse/FINERACT-724>ACT-724
> <https://issues.apache.org/jira/browse/FINERACT-724> Upgrade Spring Boot,
> Spring and Spring Security to their latest stable version
>
> We are looking to working with you!
>
>
>> Best regards,
>> Ivan
>>
>>
>>
>>
>> вт, 1 окт. 2019 г. в 19:08, Michael Vorburger <[email protected]>:
>>
>>> On Tue, 1 Oct 2019, 17:58 Ivan Bondarenko, <[email protected]> wrote:
>>>
>>>> Hello!
>>>>
>>>> I'm trying to run integration tests locally.
>>>> And first time it fails on awaitSpringBootActuatorHealthyUp()
>>>> "/fineract-provider/health" returns 404.
>>>>
>>>
>>> You should check the log to see why..
>>>
>>> Next times tomcat fail to start with error:
>>>> *Caused by: java.lang.IllegalStateException: Illegal class loader
>>>> binding*
>>>>
>>>> (Full stack in attachment)
>>>>
>>>> I have searched for this problem and it looks like the issue in
>>>> embedded tomcat plugin.
>>>> (https://github.com/bmuschko/gradle-tomcat-plugin/issues/46)
>>>>
>>>
>>> This is strange - two separate./gradlew runs should be completely
>>> isolated.. the "next time" shouldn't be any different than the "first
>>> time". Are you using Gradle's daemon? Don't- it doesn't work for us, with
>>> the gradle-tomcat-plugin... Note that we disable it via
>>> https://github.com/apache/fineract/blob/develop/gradle.properties - how
>>> are you getting around that?? ;-)
>>>
>>> Could you advice me how to fix this issue?
>>>> Should I use `env=dev` for integrationTests?
>>>>
>>>
>>> Nope, not required.
>>>
>>> BTW we'd like to get rid of the gradle-tomcat-plugin all together. I've
>>> partial WIP re that; details available upon request. Would you have any
>>> interest in helping this project with that?
>>>
>>> Thanks,
>>>> Ivan
>>>>
>>>

Reply via email to