Quantcast

Multiple WindowsManagerImpl Workaround

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Multiple WindowsManagerImpl Workaround

akorynta

Hi All,

 

Recently I have been tasked to open multiple instances of the Netbeans platform within the same JVM from a non-platform application.

 

I was able to successfully launch the netbeans Main.main() method through Reflection but the WindowsManager is very much a strictly enforced singleton. This lead me to launching the platform through my own custom URLClassLoader, which worked all well and dandy, but still subsequent calls to the Netbeans’ Main opened the new window in place of my old window.

 

This lead me into an investigation of the ModuleManager.SystemClassLoader and how it enables/disables modules. Apparently the SystemClassLoader gets set on every single running thread by way of getting the top-most ThreadGroup and enumerating the Threads recursively.

 

Obviously this is a problem because I don’t want my non-platform application threads to get the Netbeans’ SystemClassLoader and if my first Main.main() launch gets all its threads set to subsequent instances’ SystemClassLoader then I’m back to having a singleton MainWindow.

 

So I came up with a solution:

Netbeans recursively asks for parent ThreadGroups by assuming that the top ThreadGroup has a null parent. The ThreadGroup class itself is pretty locked down tight with final access modifiers everywhere. So I create a new ThreadGroup and through Reflection, force the parent of this thread group to be null.

 

Now I am able to successfully partition Netbeans Platform instances through multiple ThreadGroups. In order to finally get it to work, I also needed to rename the underlying frame to something different than “NbMainWindow”.

 

So I have a question for the panel. On a scale of 1 to 10 how hacky is this solution? Am I going to run into some horrible issues down the road?

 

Thank you for your input.

 

Adam

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Multiple WindowsManagerImpl Workaround

akorynta

Hi All,

 

Recently I have been tasked to open multiple instances of the Netbeans platform within the same JVM from a non-platform application.

 

I was able to successfully launch the netbeans Main.main() method through Reflection but the WindowsManager is very much a strictly enforced singleton. This lead me to launching the platform through my own custom URLClassLoader, which worked all well and dandy, but still subsequent calls to the Netbeans’ Main opened the new window in place of my old window.

 

This lead me into an investigation of the ModuleManager.SystemClassLoader and how it enables/disables modules. Apparently the SystemClassLoader gets set on every single running thread by way of getting the top-most ThreadGroup and enumerating the Threads recursively.

 

Obviously this is a problem because I don’t want my non-platform application threads to get the Netbeans’ SystemClassLoader and if my first Main.main() launch gets all its threads set to subsequent instances’ SystemClassLoader then I’m back to having a singleton MainWindow.

 

So I came up with a solution:

Netbeans recursively asks for parent ThreadGroups by assuming that the top ThreadGroup has a null parent. The ThreadGroup class itself is pretty locked down tight with final access modifiers everywhere. So I create a new ThreadGroup and through Reflection, force the parent of this thread group to be null.

 

Now I am able to successfully partition Netbeans Platform instances through multiple ThreadGroups. In order to finally get it to work, I also needed to rename the underlying frame to something different than “NbMainWindow”.

 

So I have a question for the panel. On a scale of 1 to 10 how hacky is this solution? Am I going to run into some horrible issues down the road?

 

Thank you for your input.

 

Adam

 

 

Adam

Software QA Engineer/Developer

1756 Picasso Avenue, Suite G, Davis, CA 95618

Phone 530-564-7043 ext. 217

Fax 530-231-5323

[hidden email]

www.rmanet.com

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple WindowsManagerImpl Workaround

Geertjan Wielenga-3



On 14-4-2017 16:53, Adam Korynta wrote:

Hi All,

 

Recently I have been tasked to open multiple instances of the Netbeans platform within the same JVM from a non-platform application.


The question is: WHY you need to do this.

The reason I am asking you for the WHY is that possibly the solution is different to what you think or what you think you need.

So, can you provide some context for this scenario?

Thanks,

Gj

 

I was able to successfully launch the netbeans Main.main() method through Reflection but the WindowsManager is very much a strictly enforced singleton. This lead me to launching the platform through my own custom URLClassLoader, which worked all well and dandy, but still subsequent calls to the Netbeans’ Main opened the new window in place of my old window.

 

This lead me into an investigation of the ModuleManager.SystemClassLoader and how it enables/disables modules. Apparently the SystemClassLoader gets set on every single running thread by way of getting the top-most ThreadGroup and enumerating the Threads recursively.

 

Obviously this is a problem because I don’t want my non-platform application threads to get the Netbeans’ SystemClassLoader and if my first Main.main() launch gets all its threads set to subsequent instances’ SystemClassLoader then I’m back to having a singleton MainWindow.

 

So I came up with a solution:

Netbeans recursively asks for parent ThreadGroups by assuming that the top ThreadGroup has a null parent. The ThreadGroup class itself is pretty locked down tight with final access modifiers everywhere. So I create a new ThreadGroup and through Reflection, force the parent of this thread group to be null.

 

Now I am able to successfully partition Netbeans Platform instances through multiple ThreadGroups. In order to finally get it to work, I also needed to rename the underlying frame to something different than “NbMainWindow”.

 

So I have a question for the panel. On a scale of 1 to 10 how hacky is this solution? Am I going to run into some horrible issues down the road?

 

Thank you for your input.

 

Adam

 

 

Adam

Software QA Engineer/Developer

1756 Picasso Avenue, Suite G, Davis, CA 95618

Phone 530-564-7043 ext. 217

Fax 530-231-5323

[hidden email]

www.rmanet.com

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple WindowsManagerImpl Workaround

akorynta

We are working on a “Dashboard” interface, that would allow users to create their own desktop based on the components that the original application offers. Our contract specifically calls out being able to open multiple “Dashboards” at the same time so just switching between different Roles won’t cut it. We were trying to find an existing technology that does this for us and the Netbeans platform is by far the most robust we’ve seen. Also we already have a good number of developers who use the platform in other programs.

 

As far as why we’re limited to the same JVM is that the main application already starts 6 other JVM’s and we don’t want the extra overhead. Also we would prefer to not have to write additional RMI (or some other such method) code.

 

 

Thank you,

 

Adam

 

From: geertjan wielenga [mailto:[hidden email]]
Sent: Saturday, April 15, 2017 8:43 AM
To: [hidden email]
Subject: [platform-dev] Re: Multiple WindowsManagerImpl Workaround

 

 

 

On 14-4-2017 16:53, Adam Korynta wrote:

Hi All,

 

Recently I have been tasked to open multiple instances of the Netbeans platform within the same JVM from a non-platform application.


The question is: WHY you need to do this.

The reason I am asking you for the WHY is that possibly the solution is different to what you think or what you think you need.

So, can you provide some context for this scenario?

Thanks,

Gj


 

I was able to successfully launch the netbeans Main.main() method through Reflection but the WindowsManager is very much a strictly enforced singleton. This lead me to launching the platform through my own custom URLClassLoader, which worked all well and dandy, but still subsequent calls to the Netbeans’ Main opened the new window in place of my old window.

 

This lead me into an investigation of the ModuleManager.SystemClassLoader and how it enables/disables modules. Apparently the SystemClassLoader gets set on every single running thread by way of getting the top-most ThreadGroup and enumerating the Threads recursively.

 

Obviously this is a problem because I don’t want my non-platform application threads to get the Netbeans’ SystemClassLoader and if my first Main.main() launch gets all its threads set to subsequent instances’ SystemClassLoader then I’m back to having a singleton MainWindow.

 

So I came up with a solution:

Netbeans recursively asks for parent ThreadGroups by assuming that the top ThreadGroup has a null parent. The ThreadGroup class itself is pretty locked down tight with final access modifiers everywhere. So I create a new ThreadGroup and through Reflection, force the parent of this thread group to be null.

 

Now I am able to successfully partition Netbeans Platform instances through multiple ThreadGroups. In order to finally get it to work, I also needed to rename the underlying frame to something different than “NbMainWindow”.

 

So I have a question for the panel. On a scale of 1 to 10 how hacky is this solution? Am I going to run into some horrible issues down the road?

 

Thank you for your input.

 

Adam

 

 

Adam

Software QA Engineer/Developer

1756 Picasso Avenue, Suite G, Davis, CA 95618

Phone 530-564-7043 ext. 217

Fax 530-231-5323

[hidden email]

www.rmanet.com

 

 

Loading...