search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.82k stars 2.69k forks source link

dev mode does not work with kogito quickstart #3288

Closed mswiderski closed 5 years ago

mswiderski commented 5 years ago

Describe the bug running using-kogito QuickStart in dev mode does not expose generated REST endpoints, while exact same code base works properly in jvm and native image modes. https://quarkus.io/guides/kogito-guide https://github.com/quarkusio/quarkus-quickstarts/tree/master/using-kogito

Expected behavior dev mode should expose /parsons endpoint as it is available in jvm and native image

Actual behavior 404 is returned when any of the /persons endpoints is invoked

To Reproduce Steps to reproduce the behavior:

  1. start using-kogito QuickStart in dev mode
  2. curl -X GET http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json'
  3. returns 404 while it should return 200

Configuration no properties needed

Environment (please complete the following information):

gsmet commented 5 years ago

@stuartwdouglas could it be related to some changes of yours recently merged?

mariofusco commented 5 years ago

@mswiderski @gsmet @stuartwdouglas I'm pretty sure the problem is related with this check https://github.com/quarkusio/quarkus/blob/master/extensions/kogito/deployment/src/main/java/io/quarkus/kogito/deployment/KogitoAssetsProcessor.java#L52

If I remove that return statement and let the method to be executed even during an hot reload everything works as expected. The problem is that we want to keep that return otherwise every hot reload will cause a full regeneration of all our artifacts instead of having only an incremental compilation as it has been implemented in KogitoCompilationProvider.

What is also changed (and I think that it is also related with the problem) is that before the BuildStep was invoked when I launched the dev mode and if I didn't change anything it wasn't invoked anymore (as expected). Now for some reason, when I attempt the first rest call, Quarkus believes that an hot reload is necessary and the BuildStep is called again even if I didn't make any change in my project. Then since that live reload check returns true it returns immediately but apparently this also makes our automatically generated rest endpoints unavailable.

@gsmet @stuartwdouglas Please let me know if I need to dig further into this or if I could do anything else to help investigating this issue.

stuartwdouglas commented 5 years ago

On Fri, 19 Jul 2019 at 10:45, Mario Fusco notifications@github.com wrote:

@mswiderski https://github.com/mswiderski @gsmet https://github.com/gsmet @stuartwdouglas https://github.com/stuartwdouglas I'm pretty sure the problem is related with this check https://github.com/quarkusio/quarkus/blob/master/extensions/kogito/deployment/src/main/java/io/quarkus/kogito/deployment/KogitoAssetsProcessor.java#L52

If I remove that return statement and let the method to be executed even during an hot reload everything works as expected. The problem is that we want to keep that return otherwise every hot reload will cause a full regeneration of all our artifacts instead of having only an incremental compilation as it has been implemented in KogitoCompilationProvider.

What is also changed (and I think that it is also related with the problem) is that before the BuildStep was invoked when I launched the dev mode and if I didn't change anything it wasn't invoked anymore (as expected). Now for some reason, when I attempt the first rest call, Quarkus believes that an hot reload is necessary and the BuildStep is called again even if I didn't make any change in my project. Then since that live reload check returns true it returns immediately but apparently this also makes our automatically generated rest endpoints unavailable.

@gsmet https://github.com/gsmet @stuartwdouglas https://github.com/stuartwdouglas Please let me know if I need to dig further into this or if I could do anything else to help investigating this issue.

So I think the issue is this commit: https://github.com/stuartwdouglas/quarkus/commit/fd78effb0328094f86ec9cf138e8c965f3506917

It is attempting to detect when source files are deleted and removes the corresponding class file, but in the kogito case it is causing problems because if has generated class files that do not have corresponding source files.

I won't have time to look at a fix till next week as I am travelling, so if anyone else wants to look at a solution feel free.

Stuart

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/3288?email_source=notifications&email_token=AACQG67ZRMVNSFXHJIWOY33QAHAPDA5CNFSM4IFFSUYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LVKXI#issuecomment-513234269, or mute the thread https://github.com/notifications/unsubscribe-auth/AACQG63WZZKBFBEVO4NXSZ3QAHAPDANCNFSM4IFFSUYA .

mswiderski commented 5 years ago

@gsmet @stuartwdouglas could you please have a look at PR https://github.com/quarkusio/quarkus/pull/3302 that proposes a fix for this issue?

machi1990 commented 5 years ago

Did #3302 fix this issue?

mswiderski commented 5 years ago

@machi1990 yes, it did fix it

machi1990 commented 5 years ago

@mswiderski thanks, I’ll close the issue then.