Jetty
  1. Jetty
  2. JETTY-282

Support manually-triggered reloading

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.2.0pre0, 7.0.0pre4, 6.1.12.rc2
    • Component/s: Maven
    • Labels:
      None
    • Number of attachments :
      3

      Description

      With modern JVMs supporting class hot-swapping, causing webapps to reload for every change is not necessary nor productive. That is, with a small change, you'd rather have your IDE reload the class without having Jetty reload the webapp, but with a larger change, hot-swapping won't work, so you'd rather have jetty reload the webapp.

      Currently, jetty maven plugin cannot be fine-tuned for this kind of set up.

      It would be nice if I can manually reload the web app, by perhaps hitting ENTER on the console. Maven has an abstraction for doing user interaction (see the release plugin for example), so this should be doable.

      I guess the workaround would be to nominate one file and have Jetty monitor it, and run the touch command to trigger a reload.

      1. JETTY-282.patch
        15 kB
        Cristiano Kliemann
      2. JETTY-282-2.patch
        17 kB
        Cristiano Kliemann
      3. JETTY-282-3.patch
        19 kB
        Jesse McConnell

        Activity

        Hide
        Cristiano Kliemann added a comment -

        I made some modifications to the plugin and now it can reload the context when someone hits ENTER on the console.

        I don't know if it will be applied to the trunk. Anyway, just apply to rev 2228 and add the following configuration in your POM:

        <plugins>
        ...
        <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <configuration>
        ...
        <newLineScan>true</newLineScan> <!-- <<< here -->
        ...
        </configuration>
        </plugin>
        ...

        Show
        Cristiano Kliemann added a comment - I made some modifications to the plugin and now it can reload the context when someone hits ENTER on the console. I don't know if it will be applied to the trunk. Anyway, just apply to rev 2228 and add the following configuration in your POM: <plugins> ... <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <configuration> ... <newLineScan>true</newLineScan> <!-- <<< here --> ... </configuration> </plugin> ...
        Hide
        Jan Bartel added a comment -

        This seems ok to me - any comments ?

        Jan

        Show
        Jan Bartel added a comment - This seems ok to me - any comments ? Jan
        Hide
        Jesse McConnell added a comment -

        seems like a good idea to me, increases the potential for frustration in a user that might not realize that they need to do something to get a change factored into the webapp they are running.

        I would change the name of the param to something like <consoleReloadBlocking>true</

        A bit clearer for someone just scanning through the params of the jetty plugin to see whats going on.

        Show
        Jesse McConnell added a comment - seems like a good idea to me, increases the potential for frustration in a user that might not realize that they need to do something to get a change factored into the webapp they are running. I would change the name of the param to something like <consoleReloadBlocking>true</ A bit clearer for someone just scanning through the params of the jetty plugin to see whats going on.
        Hide
        Cristiano Kliemann added a comment -

        I know letting the user hits ENTER to reload the application may not be the best way to support smarter reloading. I wanted something to allow me to provide exactly the files I want the plugin to scan in order to automatically reload the application. As you know, today the plugin scans all files. I wanted to tell it to scan just web.xml, for example. So, it would allow me to tell the plugin to reload the application by just touching web.xml.

        When I saw this JIRA issue, I thought I might be what I was actually looking for. I'm very satisfied with the results. Now I don't want to use that horrible Tomcat Eclipse WTP integration anymore It gave me an incredible agility.

        As I'm not an English speaker, I didn't know the appropriate property name to use in the configuration file.

        Things to do after applying the patch:

        • please take a goot look at the source comments I entered. I think they deserve correction.
        • create an expression to the newLine parameter to allow the user to use -Dxxxxxx in the maven command line
        Show
        Cristiano Kliemann added a comment - I know letting the user hits ENTER to reload the application may not be the best way to support smarter reloading. I wanted something to allow me to provide exactly the files I want the plugin to scan in order to automatically reload the application. As you know, today the plugin scans all files. I wanted to tell it to scan just web.xml, for example. So, it would allow me to tell the plugin to reload the application by just touching web.xml. When I saw this JIRA issue, I thought I might be what I was actually looking for. I'm very satisfied with the results. Now I don't want to use that horrible Tomcat Eclipse WTP integration anymore It gave me an incredible agility. As I'm not an English speaker, I didn't know the appropriate property name to use in the configuration file. Things to do after applying the patch: please take a goot look at the source comments I entered. I think they deserve correction. create an expression to the newLine parameter to allow the user to use -Dxxxxxx in the maven command line
        Hide
        Cristiano Kliemann added a comment -

        Some things to make things a bit clearer (just in case):

        This new scanner is not enabled by default. Nothing has changed to the default plugin behavior. If the user wants to make the plugin scan the application files to detect modifications in order to reload the application, he stills need to set the scanIntervalSeconds property.

        When enabled, it will not modify the default behavior, just add a new possibility: to reload all the application if the user hits ENTER on the console.

        Both scanners (new line and file scannig) are totally independent. It is possible to use both of them at the same time.

        Show
        Cristiano Kliemann added a comment - Some things to make things a bit clearer (just in case): This new scanner is not enabled by default. Nothing has changed to the default plugin behavior. If the user wants to make the plugin scan the application files to detect modifications in order to reload the application, he stills need to set the scanIntervalSeconds property. When enabled, it will not modify the default behavior, just add a new possibility: to reload all the application if the user hits ENTER on the console. Both scanners (new line and file scannig) are totally independent. It is possible to use both of them at the same time.
        Hide
        Jan Bartel added a comment -

        Cristiano,

        That is the very thing I'm wondering about. Is it a good thing to have both the background scanner and the on-demand scanner running? There is potential for both to happen at the same time and trip over each other.

        Jan

        Show
        Jan Bartel added a comment - Cristiano, That is the very thing I'm wondering about. Is it a good thing to have both the background scanner and the on-demand scanner running? There is potential for both to happen at the same time and trip over each other. Jan
        Hide
        Cristiano Kliemann added a comment -

        Jan,

        Yes, It is a problem, specially because they run in different threads.

        What about disabling temporarly the manual scanner when the file scanner detects a change?

        I think I can implement that.

        Show
        Cristiano Kliemann added a comment - Jan, Yes, It is a problem, specially because they run in different threads. What about disabling temporarly the manual scanner when the file scanner detects a change? I think I can implement that.
        Hide
        Jesse McConnell added a comment -

        why not make them mutually exclusive?

        one monitors files for changes and reloads, the other allows the user to tap enter to force a reload

        Show
        Jesse McConnell added a comment - why not make them mutually exclusive? one monitors files for changes and reloads, the other allows the user to tap enter to force a reload
        Hide
        Cristiano Kliemann added a comment -

        It seems more appropriate.

        How do you think the config should be?

        Show
        Cristiano Kliemann added a comment - It seems more appropriate. How do you think the config should be?
        Hide
        Jesse McConnell added a comment -

        I would say that by default its the existing file scanning and reload mechanic...

        and then adding in an appropriately named parameter for the console reload that would turn off the existing behavior and enable this new one. that should be feasible, right?

        Show
        Jesse McConnell added a comment - I would say that by default its the existing file scanning and reload mechanic... and then adding in an appropriately named parameter for the console reload that would turn off the existing behavior and enable this new one. that should be feasible, right?
        Hide
        Cristiano Kliemann added a comment -

        Sure. I'll do that and upload the patch probably on Sunday.

        Since I'm not a good English speaker, I'm in doubt about the parameter name. Please suggest one.

        Show
        Cristiano Kliemann added a comment - Sure. I'll do that and upload the patch probably on Sunday. Since I'm not a good English speaker, I'm in doubt about the parameter name. Please suggest one.
        Hide
        Jesse McConnell added a comment -

        maybe...

        <consoleForcedReload>true</consoleForcedReload>

        Show
        Jesse McConnell added a comment - maybe... <consoleForcedReload>true</consoleForcedReload>
        Hide
        Cristiano Kliemann added a comment -

        If both of them are enabled, should we cancel the excution showing an error or just issue a warning and automatically disable consoleForceReload?

        Show
        Cristiano Kliemann added a comment - If both of them are enabled, should we cancel the excution showing an error or just issue a warning and automatically disable consoleForceReload?
        Hide
        Jesse McConnell added a comment -

        I would just make it so that is consoleForceReload is true then the other is turned off

        Show
        Jesse McConnell added a comment - I would just make it so that is consoleForceReload is true then the other is turned off
        Hide
        Cristiano Kliemann added a comment -

        Here's a new patch:

        • Created a new configuration, consoleForceReload. If it's true, the plugin will listen to the console
        • If consoleForceReload is true AND scanIntervalSeconds is greater than zero, the plugin will ignore file scanning (behaves like scanIntervalSeconds=0), BUT it will issue a warning to the user on the console.

        Some extra:

        Added expressions to scanIntervalSeconds and consoleForceReload, so the user is able to configure them 'outside' of POM, by entering
        -Djetty.scanIntervalSeconds=X
        or
        -Djetty.consoleForceReload=true|false
        in the mvn command line.

        If you decide these parameters aren't nice, just modify the @parameter tags.

        Please take a time to review the messages.

        Show
        Cristiano Kliemann added a comment - Here's a new patch: Created a new configuration, consoleForceReload. If it's true, the plugin will listen to the console If consoleForceReload is true AND scanIntervalSeconds is greater than zero, the plugin will ignore file scanning (behaves like scanIntervalSeconds=0), BUT it will issue a warning to the user on the console. Some extra: Added expressions to scanIntervalSeconds and consoleForceReload, so the user is able to configure them 'outside' of POM, by entering -Djetty.scanIntervalSeconds=X or -Djetty.consoleForceReload=true|false in the mvn command line. If you decide these parameters aren't nice, just modify the @parameter tags. Please take a time to review the messages.
        Hide
        Cristiano Kliemann added a comment -

        oops, the new patch is obviously JETTY-282-2.patch

        Show
        Cristiano Kliemann added a comment - oops, the new patch is obviously JETTY-282 -2.patch
        Hide
        Jesse McConnell added a comment -

        changed patch a bit so the param looks like

        <reload>automatic</reload>

        or

        <reload>manual</reload>

        it defaults to automatic which was the old behavior

        Show
        Jesse McConnell added a comment - changed patch a bit so the param looks like <reload>automatic</reload> or <reload>manual</reload> it defaults to automatic which was the old behavior
        Hide
        Jan Bartel added a comment -

        Patch applied to HEAD as svn rev 2301.

        cheers
        Jan

        Show
        Jan Bartel added a comment - Patch applied to HEAD as svn rev 2301. cheers Jan
        Hide
        Tim added a comment -

        Can you please patch this into 6.1 branch? since it seems that 6.1 will be here for a long haul and this feature is very useful, at least in my case for GWT development in combination with Jetty and Spring.

        Show
        Tim added a comment - Can you please patch this into 6.1 branch? since it seems that 6.1 will be here for a long haul and this feature is very useful, at least in my case for GWT development in combination with Jetty and Spring.
        Hide
        Jesse McConnell added a comment -

        this is in the jetty-7 released version already, and will be going out with 6.1.12 release

        Show
        Jesse McConnell added a comment - this is in the jetty-7 released version already, and will be going out with 6.1.12 release
        Hide
        Jesse McConnell added a comment -

        reopenning to fix fix versions

        Show
        Jesse McConnell added a comment - reopenning to fix fix versions
        Hide
        Jesse McConnell added a comment -

        fixed for 6.1.12

        Show
        Jesse McConnell added a comment - fixed for 6.1.12

          People

          • Assignee:
            Unassigned
            Reporter:
            Kohsuke Kawaguchi
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: