groovy

GroovyConsole windows should be their own process

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.7.0
  • Fix Version/s: None
  • Component/s: Groovy Console
  • Labels:
    None
  • Environment:
    Tested on Windows XP
  • Number of attachments :
    0

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

relates to

Bug - A problem which impairs or prevents the functions of the product. GROOVY-4596 GroovyConsole - Executing script which performs a System.exit(int) causes GroovyConsole to close

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag 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
blackdrag blackdrag 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
Permalink
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
Permalink
blackdrag blackdrag 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
blackdrag blackdrag 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
Permalink
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
Permalink
blackdrag blackdrag 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
blackdrag blackdrag 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Keegan Witt
Vote (1)
Watch (1)

Dates

  • Created:
    Updated: