Groovy
  1. Groovy
  2. GROOVY-3963

GroovyConsole windows should be their own process

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.7.0
    • Fix Version/s: None
    • Component/s: Groovy Console
    • Labels:
      None
    • Environment:
      Tested on Windows XP

      Description

      The output is shared between GroovyConsole windows created from the same process, since requesting a new window doesn't create a new process.

      Steps to reproduce:
      1. Open a new console window (ctrl + shift + n)
      2. Cause some output to be generated
      3. Observe output in original window

      The output of that script will be displayed on all console windows created in the (ctrl + shift + n) way but not when it is launched as a new process. I believe the latter behavior to be preferable.

        Issue Links

          Activity

          Keegan Witt created issue -
          Hide
          Jochen Theodorou added a comment -

          this one is a bit difficult to implement, since it is a normal swing application we are talking here about. Normally Java processes don't create other Java processes. It would require native code, or a library that provides that. Any idea on that?

          Show
          Jochen Theodorou added a comment - this one is a bit difficult to implement, since it is a normal swing application we are talking here about. Normally Java processes don't create other Java processes. It would require native code, or a library that provides that. Any idea on that?
          Hide
          Keegan Witt added a comment - - edited

          I'm no expert on this, but couldn't you use Runtime.exec("groovyConsole")? I would think that would work as long as the Groovy bin folder is on the path, or you could pass a string array of environment variables into exec as the second argument and set it yourself (maybe using GROOVY_HOME?). Another possibility, if the Java were directly accessed would be to use ProcessBuilder with javap, but I don't think that will work here.

          Show
          Keegan Witt added a comment - - edited I'm no expert on this, but couldn't you use Runtime.exec("groovyConsole")? I would think that would work as long as the Groovy bin folder is on the path, or you could pass a string array of environment variables into exec as the second argument and set it yourself (maybe using GROOVY_HOME?). Another possibility, if the Java were directly accessed would be to use ProcessBuilder with javap, but I don't think that will work here.
          Hide
          Jochen Theodorou added a comment -

          I will try to explain a bit... native code can clone or fork the process. That action includes all the settings made for the process. Java does not offer this, so native code is reuqired to achieve it.

          But the problem to solve here is more delegating System.out and System.err. From different Threads into different output windows without really knowing which Thread belongs to which output window.

          Show
          Jochen Theodorou added a comment - I will try to explain a bit... native code can clone or fork the process. That action includes all the settings made for the process. Java does not offer this, so native code is reuqired to achieve it. But the problem to solve here is more delegating System.out and System.err. From different Threads into different output windows without really knowing which Thread belongs to which output window.
          Hide
          Keegan Witt added a comment -

          I guess my question would be why do you need to fork the process? What variables do you need from the original process? The way I use GroovyConsole, creating a new process with nothing carried over from the original would work fine. I would think this should be the case for anyone using it as a standalone swing app. For those using it as an embedded component, I wouldn't think they would need to call the fileNewWindow method (or if they did they would override it to work with the embedding app). Could you explain the thought process behind the current behavior?

          Show
          Keegan Witt added a comment - I guess my question would be why do you need to fork the process? What variables do you need from the original process? The way I use GroovyConsole, creating a new process with nothing carried over from the original would work fine. I would think this should be the case for anyone using it as a standalone swing app. For those using it as an embedded component, I wouldn't think they would need to call the fileNewWindow method (or if they did they would override it to work with the embedding app). Could you explain the thought process behind the current behavior?
          Hide
          Jochen Theodorou added a comment -

          What would I need? Well the classloader setup for example. A new process is most probably good enough... I guess a look at ant and how they the "forking" would be a good idea... or reusing the ant stuff even.

          Show
          Jochen Theodorou added a comment - What would I need? Well the classloader setup for example. A new process is most probably good enough... I guess a look at ant and how they the "forking" would be a good idea... or reusing the ant stuff even.
          Paul King made changes -
          Field Original Value New Value
          Link This issue relates to GROOVY-4596 [ GROOVY-4596 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 13:32:57 UTC 2015 [ 1428240777691 ]
          Mark Thomas made changes -
          Workflow jira [ 12732921 ] Default workflow, editable Closed status [ 12744678 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 02:11:23 UTC 2015 [ 1428286283443 ]
          Mark Thomas made changes -
          Workflow jira [ 12973999 ] Default workflow, editable Closed status [ 12981170 ]
          Hide
          John Wagenleitner added a comment -

          The issue of script output being sent to multiple console windows should be addressed with the fix for GROOVY-4888. Even though the title says windows should be their own process it really seems like the main issue here was with the output being directed to all console output areas.

          If the issue is really about windows should be their own process then I think the best way to achieve that is with the existing groovyConsole command. The user can execute that script to create a new console window that is a separate process. I think executing that should be left to the user and not attempted from an existing jvm process.

          Show
          John Wagenleitner added a comment - The issue of script output being sent to multiple console windows should be addressed with the fix for GROOVY-4888 . Even though the title says windows should be their own process it really seems like the main issue here was with the output being directed to all console output areas. If the issue is really about windows should be their own process then I think the best way to achieve that is with the existing groovyConsole command. The user can execute that script to create a new console window that is a separate process. I think executing that should be left to the user and not attempted from an existing jvm process.
          Hide
          Pascal Schumacher added a comment -

          I'm closing this after Johns comment.

          Show
          Pascal Schumacher added a comment - I'm closing this after Johns comment.
          Pascal Schumacher made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]
          Hide
          Keegan Witt added a comment -

          Sorry for the late response. I think GROOVY-4888 addresses my concern with this Jira, so +1 on closing. Thanks for spotting duplication.

          Show
          Keegan Witt added a comment - Sorry for the late response. I think GROOVY-4888 addresses my concern with this Jira, so +1 on closing. Thanks for spotting duplication.
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          2184d 1 Pascal Schumacher 23/Dec/15 13:57

            People

            • Assignee:
              Unassigned
              Reporter:
              Keegan Witt
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development