Debug quarkus for a (big) web app with IDE and live-reload.. a nightmare

[Antoine D]

Hi All,

Searching in all discutions, I realise that it seems that I'm the only one to use Quarkus for a web app, because I'd like to use it instead of SpringBoot for instance.

The problem: live reload and the restarts of the app.

Live-reload is great... until:

- you have the HMI that is polling and you want to control when the rebuild should be done: any changes in a file will triger the restart of the app

- you want to do tiny modifications duing debug and be able to go back in the stack keeping the context, like Netbeans or Eclipse does.

Set the password and url live-reload has no effect as I'm in localhost (i think).

I'd like to use the full IDE build functionnality (Eclipse uses its personal builder, and Netbeans uses maven) to reload the class after a tiny modification like I love to do when I develop a Java application.

So I created a @QuarkusMain, and starts my app with this Main class, but live-reload is still active, and it's a real nigthmare to debug (need to play with terminals + IDE + remote debug etc..)

So, does anyone tried to use Quarlus as a java app that contains a server? Like you would use a Main class with SpringBoot, or Netty or Vertx ?

Or Quarkus is really not done for that and I should use SpringBoot?

Thans a lot for your answers!

[Guillaume Smet]

A lot of us are using Quarkus to develop web apps.

But yes, if your UI is polling, you will reload things, not sure what we can do about it.

As for keeping the context and avoid restarting your app if not required, you can use `quarkus.live-reload.instrumentation=true`.

But reading you, I think you just want to avoid live reload altogether and just start your app in debug without using quarkus:dev.

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/f91a0d17-3766-4b2e-a9e4-953682bfd967n%40googlegroups.com.

[Georgios Andrianakis]

On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet <guillau...@gmail.com> wrote:

A lot of us are using Quarkus to develop web apps.

But yes, if your UI is polling, you will reload things, not sure what we can do about it.

As for keeping the context and avoid restarting your app if not required, you can use `quarkus.live-reload.instrumentation=true`.

But reading you, I think you just want to avoid live reload altogether and just start your app in debug without using quarkus:dev.

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

We have heard this before although TBH I don't really see the point as this could easily be some kind of script that builds the application and then just runs the jar, right?

On Thu, Apr 29, 2021 at 5:23 PM Antoine D <irii...@gmail.com> wrote:

Hi All,

Searching in all discutions, I realise that it seems that I'm the only one to use Quarkus for a web app, because I'd like to use it instead of SpringBoot for instance.

The problem: live reload and the restarts of the app.

Live-reload is great... until:

- you have the HMI that is polling and you want to control when the rebuild should be done: any changes in a file will triger the restart of the app

- you want to do tiny modifications duing debug and be able to go back in the stack keeping the context, like Netbeans or Eclipse does.

Set the password and url live-reload has no effect as I'm in localhost (i think).

I'd like to use the full IDE build functionnality (Eclipse uses its personal builder, and Netbeans uses maven) to reload the class after a tiny modification like I love to do when I develop a Java application.

So I created a @QuarkusMain, and starts my app with this Main class, but live-reload is still active, and it's a real nigthmare to debug (need to play with terminals + IDE + remote debug etc..)

So, does anyone tried to use Quarlus as a java app that contains a server? Like you would use a Main class with SpringBoot, or Netty or Vertx ?

Or Quarkus is really not done for that and I should use SpringBoot?

Thans a lot for your answers!

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/f91a0d17-3766-4b2e-a9e4-953682bfd967n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com.

[Georgios Andrianakis]

Can you clarify what exactly you mean here?

Or Quarkus is really not done for that and I should use SpringBoot?

Thans a lot for your answers!

[Jason Greene]

TBH I think instrumentation mode fits this use case. You want small changes to not restart, bug changes have to restart. 

I do think we should look at resurrecting it as the default at some point. 

We could also do a pause like we are doing in continuous testing, so in the console he can disable live reloading during the debug session (just hit ‘p’ in the console)  and then just reenable after completing.

On Apr 29, 2021, at 10:35 AM, Guillaume Smet <guillau...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com.

[William Burke]

On Thu, Apr 29, 2021 at 11:41 AM Georgios Andrianakis <gand...@redhat.com> wrote:

On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet <guillau...@gmail.com> wrote:

A lot of us are using Quarkus to develop web apps.

But yes, if your UI is polling, you will reload things, not sure what we can do about it.

As for keeping the context and avoid restarting your app if not required, you can use `quarkus.live-reload.instrumentation=true`.

But reading you, I think you just want to avoid live reload altogether and just start your app in debug without using quarkus:dev.

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

We have heard this before although TBH I don't really see the point as this could easily be some kind of script that builds the application and then just runs the jar, right?

Is it even possible to run Quarkus directly from a vanilla IDE?  Would the IDE understand that it needs to run the quarkus plugin?

A Quarkus:run doesn't sound useful as you can just do java -jar target/artifact.jar (easy enough to remember!), but a quarkus:debug does sound useful maybe?  Or is it just as trivial?  Apologies, I never use any of these features as I'm a debug from a right click on a @Test kind of guy.

[Guillaume Smet]

On Thu, Apr 29, 2021 at 5:41 PM Georgios Andrianakis <gand...@redhat.com> wrote:

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

We have heard this before although TBH I don't really see the point as this could easily be some kind of script that builds the application and then just runs the jar, right?

Sure we can have N users writing their own scripts or provide it ourselves :).

It does look to me like something we would want. Could be useful for people having polling problems as the OP or dev mode CL issues. Or just to test your application in something that is more production like.

[Georgios Andrianakis]

On Thu, Apr 29, 2021, 18:58 William Burke <bbu...@redhat.com> wrote:

On Thu, Apr 29, 2021 at 11:41 AM Georgios Andrianakis <gand...@redhat.com> wrote:

On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet <guillau...@gmail.com> wrote:

A lot of us are using Quarkus to develop web apps.

But yes, if your UI is polling, you will reload things, not sure what we can do about it.

As for keeping the context and avoid restarting your app if not required, you can use `quarkus.live-reload.instrumentation=true`.

But reading you, I think you just want to avoid live reload altogether and just start your app in debug without using quarkus:dev.

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

We have heard this before although TBH I don't really see the point as this could easily be some kind of script that builds the application and then just runs the jar, right?

Is it even possible to run Quarkus directly from a vanilla IDE?  Would the IDE understand that it needs to run the quarkus plugin?

You can easily make IDEA do this by have it run the jar and make the maven goal a prerequisite.

Then you also get debug capabilities out of the box

[Guillaume Smet]

On Thu, Apr 29, 2021 at 5:43 PM Jason Greene <jason....@redhat.com> wrote:

TBH I think instrumentation mode fits this use case. You want small changes to not restart, bug changes have to restart. 

I do think we should look at resurrecting it as the default at some point.

It does partially address the issue but it does not really resolve the issue the OP has with polling.

Instrumentation will work in some cases but not all of them and if your UI is polling every second, I can see how dev mode could be painful.

[Jason Greene]

On Apr 29, 2021, at 11:04 AM, Guillaume Smet <guillau...@gmail.com> wrote:



One other improvement we could do (in addition to supporting pausing) is detect and ignore XHR polling (e.g look for X-Requested-With: XmlHttpRequest)

-Jason

[Stuart Douglas]

That might break a lot of non polling SPA's where the interaction with quarkus is all JavaScript initiated.

Now we have an interactive console I can just provide an option to turn it off, and do manual reload on keypress.

Stuart

-Jason

[Jason Greene]

On Apr 29, 2021, at 5:33 PM, Stuart Douglas <sdou...@redhat.com> wrote:

On Fri, 30 Apr 2021, 2:28 am Jason Greene, <jason....@redhat.com> wrote:

On Apr 29, 2021, at 11:04 AM, Guillaume Smet <guillau...@gmail.com> wrote:



On Thu, Apr 29, 2021 at 5:43 PM Jason Greene <jason....@redhat.com> wrote:

TBH I think instrumentation mode fits this use case. You want small changes to not restart, bug changes have to restart. 

I do think we should look at resurrecting it as the default at some point.

It does partially address the issue but it does not really resolve the issue the OP has with polling.

Instrumentation will work in some cases but not all of them and if your UI is polling every second, I can see how dev mode could be painful.

One other improvement we could do (in addition to supporting pausing) is detect and ignore XHR polling (e.g look for X-Requested-With: XmlHttpRequest)

That might break a lot of non polling SPA's where the interaction with quarkus is all JavaScript initiated.

Yeah I was thinking that even in a pure JS front end, the user just uses their browser refresh button as a way to trigger a reload, but the console button push is just as fast.

Another interesting concept is a little iframe or DOM js snippet that they could include in their app that would act as a small toolbar, so you could enable disable automatic reload, trigger a manual reload, or open the dev console.

[Stuart Douglas]

On Fri, 30 Apr 2021, 1:58 am William Burke, <bbu...@redhat.com> wrote:

On Thu, Apr 29, 2021 at 11:41 AM Georgios Andrianakis <gand...@redhat.com> wrote:

On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet <guillau...@gmail.com> wrote:

A lot of us are using Quarkus to develop web apps.

But yes, if your UI is polling, you will reload things, not sure what we can do about it.

As for keeping the context and avoid restarting your app if not required, you can use `quarkus.live-reload.instrumentation=true`.

But reading you, I think you just want to avoid live reload altogether and just start your app in debug without using quarkus:dev.

@Stuart Douglas it's not the first time I wonder if we should have a `quarkus:run` command to just start the app outside of dev mode.

We have heard this before although TBH I don't really see the point as this could easily be some kind of script that builds the application and then just runs the jar, right?

Is it even possible to run Quarkus directly from a vanilla IDE?  Would the IDE understand that it needs to run the quarkus plugin?

Just add a main method and run it normally, no plugin required.

Stuart

[Max Rydahl Andersen]

On 29 Apr 2021, at 17:58, William Burke wrote:

> On Thu, Apr 29, 2021 at 11:41 AM Georgios Andrianakis
> <gand...@redhat.com>
> wrote:
>
>>
>>
>> On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet
>> <guillau...@gmail.com>
>> wrote:
>>
>>> A lot of us are using Quarkus to develop web apps.
>>>
>>> But yes, if your UI is polling, you will reload things, not sure
>>> what we
>>> can do about it.
>>>
>>> As for keeping the context and avoid restarting your app if not
>>> required,
>>> you can use `quarkus.live-reload.instrumentation=true`.
>>>
>>> But reading you, I think you just want to avoid live reload
>>> altogether
>>> and just start your app in debug without using quarkus:dev.
>>>

>>> @Stuart Douglas <sdou...@redhat.com> it's not the first time I

>>> wonder
>>> if we should have a `quarkus:run` command to just start the app
>>> outside of
>>> dev mode.
>>>
>>
>> We have heard this before although TBH I don't really see the point
>> as
>> this could easily be some kind of script that builds the application
>> and
>> then just runs the jar, right?
>>
>
> Is it even possible to run Quarkus directly from a vanilla IDE? Would
> the
> IDE understand that it needs to run the quarkus plugin?
>
> A Quarkus:run doesn't sound useful as you can just do java -jar
> target/artifact.jar (easy enough to remember!), but a quarkus:debug
> does
> sound useful maybe? Or is it just as trivial? Apologies, I never use
> any
> of these features as I'm a debug from a right click on a @Test kind of
> guy.

Yes, quarkus main launcher detects this and direct run from IDE brings
you into devmode.

IMO, the suggestion of being able to disable full-reload and make it
explicit would be
good for this workflow.

Just enabling instrumentation mode is not sufficient as the usecase
explicitly is about changing files/resources that are outside classes.

Having dev ui and other goodies are still useful here.

What i'm not sure we can enable cleanly is if users are updating
resources (html, qute files) wether
that can be picked up without restart ? do we have that level of fine
grained control Stuart?



/max
https://xam.dk/about

[Max Rydahl Andersen]

On 29 Apr 2021, at 17:40, Georgios Andrianakis wrote:

> On Thu, Apr 29, 2021 at 6:36 PM Guillaume Smet
> <guillau...@gmail.com>
> wrote:
>
>> A lot of us are using Quarkus to develop web apps.
>>
>> But yes, if your UI is polling, you will reload things, not sure what
>> we
>> can do about it.
>>
>> As for keeping the context and avoid restarting your app if not
>> required,
>> you can use `quarkus.live-reload.instrumentation=true`.
>>
>> But reading you, I think you just want to avoid live reload
>> altogether and
>> just start your app in debug without using quarkus:dev.
>>

>> @Stuart Douglas <sdou...@redhat.com> it's not the first time I

>> wonder if
>> we should have a `quarkus:run` command to just start the app outside
>> of dev
>> mode.
>>
>
> We have heard this before although TBH I don't really see the point as
> this
> could easily be some kind of script that builds the application and
> then
> just runs the jar, right?

Thats quite slow compared to traditional incremental updates of
resources
thats been supported by IDE's for traditional web apps.

/max

>>> <https://groups.google.com/d/msgid/quarkus-dev/f91a0d17-3766-4b2e-a9e4-953682bfd967n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3D_bh9-z3%3DW4rqONDcs9b%2BfrWcR%2Bj09SG9bEAouBgnDig%40mail.gmail.com.

[Emmanuel Bernard]

Here is my proposed solution to the problem.

We add two new things:

* ability to disable the reload on web resource access

* add a /q/reload web endpoint that would trigger the reload

From these two base concepts we can do two things:

* have the Dev UI offer waits to trigger these

    * so as a user I would clock on that UI button to refresh when I want. It needs to be tested but I think it will be faster UX wise than a Quarkus:ruin alternative.

* offer some widget people could add to their app when in dev mode. Like a fork me on github but instead a "Quarkus: reload!" button which would call /q/reload

    * this one is a in place click in the UI being tested

Thoughts?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com.

[Stuart Douglas]

On Fri, 30 Apr 2021, 6:09 pm Emmanuel Bernard, <eber...@redhat.com> wrote:

Here is my proposed solution to the problem.

We add two new things:

* ability to disable the reload on web resource access

* add a /q/reload web endpoint that would trigger the reload

This is very similar to what I proposed, and to what I have done with continuous testing. As well as the above though you would also have the ability to turn live reload on and off though a key binding in the console, and run the tests manually the same way.

Stuart

[Antoine D]

I agree. My main problem is to be able to disable live-coding/hot-reload to be able to use the IDE for full debug by launching the Main class with the IDE.

Live-reload is great when you modify the schema of a class, because the app needs full restarts, and it’s done very fast according to a IDE, so it would be great to triger it when I need.

However, for tiny modification, Eclipse is very fast as it builds the code automatically its way. Netbeans is slower as it uses maven to replace the class at runtime but still, the context is saved.

[Stuart Douglas]

Here is a super simple initial implementation: https://github.com/quarkusio/quarkus/pull/17035

It has some limitations and can be improved, but its a start.

Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/61255d60-739f-4080-a471-e56badcc3246n%40googlegroups.com.

[Stephane Epardaud]

What I understood in the original question was that Antoine wanted to use the IDE to update his code while in the debugger while "keeping its context", which in my understanding means "hot reload of that class via instrumentation and not even dropping the thread's stack while in the debugger". I guess you're in a breakpoint during a request, you modify the endpoint currently being debugged and invoked, and that code is applied before the request terminates. I'm not sure debuggers can do that, I've never ever used that. If they support that, I'm pretty sure a lot of Quarkus won't support it depending on what it does, because build steps would be interested in that change in many cases. Well, maybe not if it's not changing any signature. The ClassLoader we use might be problematic though.

Or are we talking about something else?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyf%2BkCO72bVHBgGSfeZ%2B6X12pQTPQUawp-rcTxX-Zatbg%40mail.gmail.com.

--

Stéphane Épardaud

[Ladislav Thon]

čt 6. 5. 2021 v 11:03 odesílatel Stephane Epardaud <stephane...@gmail.com> napsal:

What I understood in the original question was that Antoine wanted to use the IDE to update his code while in the debugger while "keeping its context", which in my understanding means "hot reload of that class via instrumentation and not even dropping the thread's stack while in the debugger". I guess you're in a breakpoint during a request, you modify the endpoint currently being debugged and invoked, and that code is applied before the request terminates. I'm not sure debuggers can do that, I've never ever used that.

I used that a long time ago and it seemed wonderful at that time. I didn't see the need for it in a long while -- which might very well be caused by a very different nature of bugs I've had to debug in that "long while".

 

If they support that, I'm pretty sure a lot of Quarkus won't support it depending on what it does, because build steps would be interested in that change in many cases. Well, maybe not if it's not changing any signature.

I'm not sure if "many cases", but there certainly are cases -- think all the bytecode manipulation we do.

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9tP7tuw56KPZEmkyJ8OH67orne%3DEnGuoWCxTF-kC-g4gQ%40mail.gmail.com.

[Max Rydahl Andersen]

This is only for method body changes and its nice.

I use it constantly as it lets me just reload the stack frame after changing some code and
see it work with parameters and state passed in.

As it does not cover signature changes none of quarkus should care.

Somehow our instrumentation support confuses IDE's so its less clean - but if your IDE
is connected with a debugger then Quarkus shouldn't have to care for this except user need to be able to tell
Quarkus not to do the instrumentation (twice) and to not restarts...

which Stuarts PR enables.

so this should work pretty nice.
/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALbocOmPiVHxemuWanN4zK6d0q7-E31448Za4HVuzj5_6cmLpg%40mail.gmail.com.

/max
https://xam.dk/about

[Ladislav Thon]

čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen <mand...@redhat.com> napsal:

This is only for method body changes and its nice.

I use it constantly as it lets me just reload the stack frame after changing some code and
see it work with parameters and state passed in.

As it does not cover signature changes none of quarkus should care.

Again, the bytecode manipulation parts of Quarkus will care. E.g. when we rewrite direct field access to getter/setter invocation, things like that.

LT

[Max Rydahl Andersen]

On 6 May 2021, at 13:55, Ladislav Thon wrote:

> čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> This is only for method body changes and its nice.
>>
>> I use it constantly as it lets me just reload the stack frame after
>> changing some code and
>> see it work with parameters and state passed in.
>>
>> As it does not cover signature changes none of quarkus should care.
>>
> Again, the bytecode manipulation parts of Quarkus will care. E.g. when
> we
> rewrite direct field access to getter/setter invocation, things like
> that.

aaah - I hadn't thought about that aspect. hmm...damn. I knew I would be
bit
by liking panaches public field approach :)

are there more than panache relying on such "fun" ?

/max

>>>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/f91a0d17-3766-4b2e-a9e4-953682bfd967n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .

>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the
>>>>>>>> Google
>>>>>>>> Groups "Quarkus Development mailing list" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>> it,
>>>>>>>> send an email to quarkus-dev...@googlegroups.com.
>>>>>>>> To view this discussion on the web visit

>>>>>>>> https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com
>>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_iocyMz%2BYpi-sVtnGo9AvZ7vRZYfznZ2cYv%2BahzjZ1rA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>> .

>>>>>>>>
>>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Quarkus Development mailing list" group.
>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send
>>>>> an email to quarkus-dev...@googlegroups.com.
>>>>> To view this discussion on the web visit

>>>>> https://groups.google.com/d/msgid/quarkus-dev/61255d60-739f-4080-a471-e56badcc3246n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/quarkus-dev/61255d60-739f-4080-a471-e56badcc3246n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .

>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Quarkus Development mailing list" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send
>>>> an email to quarkus-dev...@googlegroups.com.
>>>> To view this discussion on the web visit

>>>> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyf%2BkCO72bVHBgGSfeZ%2B6X12pQTPQUawp-rcTxX-Zatbg%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyf%2BkCO72bVHBgGSfeZ%2B6X12pQTPQUawp-rcTxX-Zatbg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .

>>>>
>>>
>>>
>>> --
>>> Stéphane Épardaud
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9tP7tuw56KPZEmkyJ8OH67orne%3DEnGuoWCxTF-kC-g4gQ%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9tP7tuw56KPZEmkyJ8OH67orne%3DEnGuoWCxTF-kC-g4gQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/CALbocOmPiVHxemuWanN4zK6d0q7-E31448Za4HVuzj5_6cmLpg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CALbocOmPiVHxemuWanN4zK6d0q7-E31448Za4HVuzj5_6cmLpg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> /max
>> https://xam.dk/about
>>


/max
https://xam.dk/about

[Ladislav Thon]

čt 6. 5. 2021 v 13:58 odesílatel Max Rydahl Andersen <mand...@redhat.com> napsal:

On 6 May 2021, at 13:55, Ladislav Thon wrote:

> čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> This is only for method body changes and its nice.
>>
>> I use it constantly as it lets me just reload the stack frame after
>> changing some code and
>> see it work with parameters and state passed in.
>>
>> As it does not cover signature changes none of quarkus should care.
>>
> Again, the bytecode manipulation parts of Quarkus will care. E.g. when
> we
> rewrite direct field access to getter/setter invocation, things like
> that.

aaah - I hadn't thought about that aspect. hmm...damn. I knew I would be
bit
by liking panaches public field approach :)

are there more than panache relying on such "fun" ?

When we get Jandex 3, this PR https://github.com/quarkusio/quarkus/pull/14586 will do "fun" things too :-)

LT

[Stuart Douglas]

On Thu, 6 May 2021 at 21:58, Max Rydahl Andersen <mand...@redhat.com> wrote:

On 6 May 2021, at 13:55, Ladislav Thon wrote:

> čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> This is only for method body changes and its nice.
>>
>> I use it constantly as it lets me just reload the stack frame after
>> changing some code and
>> see it work with parameters and state passed in.
>>
>> As it does not cover signature changes none of quarkus should care.
>>
> Again, the bytecode manipulation parts of Quarkus will care. E.g. when
> we
> rewrite direct field access to getter/setter invocation, things like
> that.

aaah - I hadn't thought about that aspect. hmm...damn. I knew I would be
bit
by liking panaches public field approach :)

are there more than panache relying on such "fun" ?

Our instrumentation approach actually fixes this, as it performs the transformation before the replacement.

I can make this work for IDE's as well by changing that logic to a javaagent transformer, but it means it will only work when running from quarkus:dev, not when running from the IDE as that will not run with the javaagent.

Stuart

[Stuart Douglas]

On Fri, 7 May 2021 at 08:49, Stuart Douglas <sdou...@redhat.com> wrote:

On Thu, 6 May 2021 at 21:58, Max Rydahl Andersen <mand...@redhat.com> wrote:

On 6 May 2021, at 13:55, Ladislav Thon wrote:

> čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> This is only for method body changes and its nice.
>>
>> I use it constantly as it lets me just reload the stack frame after
>> changing some code and
>> see it work with parameters and state passed in.
>>
>> As it does not cover signature changes none of quarkus should care.
>>
> Again, the bytecode manipulation parts of Quarkus will care. E.g. when
> we
> rewrite direct field access to getter/setter invocation, things like
> that.

aaah - I hadn't thought about that aspect. hmm...damn. I knew I would be
bit
by liking panaches public field approach :)

are there more than panache relying on such "fun" ?

Our instrumentation approach actually fixes this, as it performs the transformation before the replacement.

I can make this work for IDE's as well by changing that logic to a javaagent transformer, but it means it will only work when running from quarkus:dev, not when running from the IDE as that will not run with the javaagent.

Although on second thoughts, maybe we should look into why IDE's get messed up by instrumentation and try and fix that, rather than going any further down this rabbit hole.

Stuart

[Max Andersen]

Now that I grok what happens My guess is that the IDEs aren’t made aware the instrumentation have happened. 

They normally would do it themselves. 

Or are you actually picking up the IDEs attempt to update over the debug channel ? 

/max

[Sanne Grinovero]

On Thu, 6 May 2021 at 12:58, Max Rydahl Andersen <mand...@redhat.com> wrote:

On 6 May 2021, at 13:55, Ladislav Thon wrote:

> čt 6. 5. 2021 v 13:44 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> This is only for method body changes and its nice.
>>
>> I use it constantly as it lets me just reload the stack frame after
>> changing some code and
>> see it work with parameters and state passed in.
>>
>> As it does not cover signature changes none of quarkus should care.
>>
> Again, the bytecode manipulation parts of Quarkus will care. E.g. when
> we
> rewrite direct field access to getter/setter invocation, things like
> that.

aaah - I hadn't thought about that aspect. hmm...damn. I knew I would be
bit
by liking panaches public field approach :)

are there more than panache relying on such "fun" ?

Sure, all of Hibernate.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/A32BBB11-400D-4C6A-AA1B-D7FD46E07225%40redhat.com.

[Antoine D]

Hi All,

Did you find out how to solve this issue?

Having an URL to do the reload would be great.

About optimisation done in the bytecode, that true I see a stack with strange class names and that can make the debug harder, even without Panache used.

[Stuart Douglas]

With Quarkus 2.0 you will be able to disable the live reload by pressing 'l' in the console.

Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/985adbf0-507a-4ebe-b555-2670e5da9140n%40googlegroups.com.

[Antoine D]

That's good news.

Well done.