Jetty
  1. Jetty
  2. JETTY-991

Starting Jetty in separate JVM

    Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.1.16
    • Fix Version/s: 7.6.6, 8.1.6
    • Component/s: Maven
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Please support starting jetty (using jetty-maven-plugin) in separate JVM istance than one Maven build is running in. With jetty-maven-plugin running in separate JVM instance, stopping it should exit JVM instance Jetty was running in. This would enable maven code coverage plugins like maven cobertura plugin to get coverage data on time for maven report generation, as these data get stored on JVM exit event.

        Issue Links

          Activity

          Hide
          Shawn Clark added a comment -

          <waitForChild> is working on the 7.6.5-20120703.080710-38. During my testing of this feature I found that I am now stuck at two extremes for the jetty startup. One is where the maven lifecycle stops when using the run-forked as part of another phase, pre-integration-test in my case, or the other extreme which is that the maven lifecycle just continues to process the next phase even before Jetty has initialized. When using the "run" goal the maven process wouldn't continue onto the next phase until the init of Jetty was complete. Is there someway to tie into that same state change when dealing with the <waitForChild>, maybe a <waitForInit> or something similar?

          Show
          Shawn Clark added a comment - <waitForChild> is working on the 7.6.5-20120703.080710-38. During my testing of this feature I found that I am now stuck at two extremes for the jetty startup. One is where the maven lifecycle stops when using the run-forked as part of another phase, pre-integration-test in my case, or the other extreme which is that the maven lifecycle just continues to process the next phase even before Jetty has initialized. When using the "run" goal the maven process wouldn't continue onto the next phase until the init of Jetty was complete. Is there someway to tie into that same state change when dealing with the <waitForChild>, maybe a <waitForInit> or something similar?
          Hide
          Edd grant added a comment -

          Tested this today with SNAPSHOT-7-6-5. I can confirm that waitForChild now has an effect however it's not the effect I was personally hoping it would have. Essentially I wanted it to have the same effect as setting <daemon>true</daemon has when running jetty:run, in that Jetty would start (in a new JVM) and Maven would block until Jetty had started, at which point Maven would continue (in my case running the integration test phase as I have bound run-forked to the pre-integration-test) running the requested goals. What is actually happening is that the forked JVM begins to start but control returns immediately to the parent process which executes my integration tests, these all fail with connection refused errors because Jetty hasn't yet completely started up.

          Is there any way to make jetty:run-forked behave more like jetty:run in terms of blocking? I realise that there may be extra difficulties in terms of inter-jvm-communication but this would be great for cases like mine where we need a fresh JVM but want to support running Jetty for integration tests.

          I seem to be unable to re-open JIRA but wanted to comment my findings.

          Show
          Edd grant added a comment - Tested this today with SNAPSHOT-7-6-5 . I can confirm that waitForChild now has an effect however it's not the effect I was personally hoping it would have. Essentially I wanted it to have the same effect as setting <daemon>true</daemon has when running jetty:run , in that Jetty would start (in a new JVM) and Maven would block until Jetty had started, at which point Maven would continue (in my case running the integration test phase as I have bound run-forked to the pre-integration-test ) running the requested goals. What is actually happening is that the forked JVM begins to start but control returns immediately to the parent process which executes my integration tests, these all fail with connection refused errors because Jetty hasn't yet completely started up. Is there any way to make jetty:run-forked behave more like jetty:run in terms of blocking? I realise that there may be extra difficulties in terms of inter-jvm-communication but this would be great for cases like mine where we need a fresh JVM but want to support running Jetty for integration tests. I seem to be unable to re-open JIRA but wanted to comment my findings.
          Hide
          Jan Bartel added a comment -

          Ok, change made so that even if the parent process is going to exit (ie waitForChild is FALSE) then it waits until the forked jetty has started up.

          Show
          Jan Bartel added a comment - Ok, change made so that even if the parent process is going to exit (ie waitForChild is FALSE) then it waits until the forked jetty has started up.
          Hide
          Edd grant added a comment -

          Tested this on 7.6.8-SNAPSHOT, can confirm that run-forked is now starting, waiting and stopping correctly - thanks for this. I have an issue where it hangs in a multi module project build however will raise this as a separate JIRA and will try to put together a sharable example.

          Show
          Edd grant added a comment - Tested this on 7.6.8-SNAPSHOT, can confirm that run-forked is now starting, waiting and stopping correctly - thanks for this. I have an issue where it hangs in a multi module project build however will raise this as a separate JIRA and will try to put together a sharable example.
          Hide
          Edd grant added a comment -

          r.e. my last comment about multi-module project builds hanging, ignore that it was an issue created within my particular project. My testing of this suggests that it is working perfectly now. Many thanks.

          Show
          Edd grant added a comment - r.e. my last comment about multi-module project builds hanging, ignore that it was an issue created within my particular project. My testing of this suggests that it is working perfectly now. Many thanks.

            People

            • Assignee:
              Jan Bartel
              Reporter:
              Stevo Slavic
            • Votes:
              13 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: