[jira] [Comment Edited] (NETBEANS-63) Incorrect startup order

["Jaroslav Tulach (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NETBEANS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176205#comment-16176205 ] 

Jaroslav Tulach edited comment on NETBEANS-63 at 9/22/17 9:50 AM:
------------------------------------------------------------------

The {{RunLevel}} concept was introduced when I was trying to use [NetBeans Runtime Container on server|http://wiki.apidesign.org/wiki/NetBeans_Runtime_Container]. It's only purpose was the separate the startup sequence into non-UI and UI parts. It was never meant as an API that anybody outside of the platform cluster could use. For that we now have {{@OnStartup}}, etc.

Introducing {{@OnNetwork}} is an interesting idea, but isn't that an overkill? Just move the initialization of {{NbAuthenticator}} and we are done, aren't we? Well not, having a test would also be good...

I suggest to use the same trick that registers the {{ProxySelector}} in {{CoreBridgeImpl}}:
{code}
        ProxySelector selector = Lookup.getDefault().lookup(ProxySelector.class);
        if (selector != null) {
            // install java.net.ProxySelector
            ProxySelector.setDefault(selector);
        }
{code}
just search for {{java.net.Authenticator}}. Simple and even extensible.




was (Author: jtulach):
The {{RunLevel}} concept was introduced when I was trying to use [NetBeans Runtime Container on server|http://wiki.apidesign.org/wiki/NetBeans_Runtime_Container]. It's only purpose was the separate the startup sequence into non-UI and UI parts. It was never meant as an API that anybody outside of the platform cluster could use. For that we now have {{@OnStartup}}, etc.

Introducing {{@OnNetwork}} is an interesting idea, but isn't that an overkill? Just move the initialization of {{NbAuthenticator}} and we are done, aren't we? Well not, having a test would also be good...

I suggest to use the same trick that registers the {{ProxySelector}}:
{code}
        ProxySelector selector = Lookup.getDefault().lookup(ProxySelector.class);
        if (selector != null) {
            // install java.net.ProxySelector
            ProxySelector.setDefault(selector);
        }
{code}
just search for {{java.net.Authenticator}}. Simple and even extensible.



> Incorrect startup order
> -----------------------
>
>                 Key: NETBEANS-63
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-63
>             Project: NetBeans
>          Issue Type: Bug
>          Components: platform - Module System
>    Affects Versions: 8.2, 9.0
>         Environment: All
>            Reporter: Peter Hansson
>         Attachments: NBStartup.pdf
>
>
> As part of analyzing the [freeze bug on startup|https://issues.apache.org/jira/browse/NETBEANS-58], I've come across something I see as a problem in NB startup sequence.
> Basically I see this sequence in the Platform's main startup thread:
> # @OnStart tasks from modules are spawned
> # ProxySelector is registered
> # WarmUp tasks are spawned
> # Authenticator is registered
> So clearly, tasks that may perform network operations are started _before_ network infrastructure ({{ProxySelector}} and {{Authenticator}}) has been initialized. In real-life it will be hit and miss which comes first.
> I've attached my analysis of the startup sequence as a PDF (in case anyone disagrees).
> My idea for a fix is along these lines:
> * I want to continue to allow @Startup tasks and WarmUp tasks to be launched early (as today), but a task must itself be aware if it needs network or UI initialization or whatever.
> * I want to create a new {{RunLevel}}. Currently the RunLevel feature is under-used in my experience. There's really only one RunLevel at the moment, namely the {{GuiRunLevel}} which is always executed last. (despite the name it applies both to GUI and headless scenario). So I would add an additional RunLevel, {{NetworkRunLevel}}, where network infra will be initialized. The new RunLevel will run before GuiRunLevel. This mimics what operating systems does and I believe this was also the original idea of the RunLevel feature.
> * Currently RunLevels are found by Lookup so that anyone can install their own RunLevel. I don't think this feature is used (it probably requires to be Friend), but it is nice and we should of course still cater for it.
> * Create a public interface where a task can wait for a given RunLevel to have executed. I'm thinking some kind of annotation or something.
> * Existing WarmUp tasks will need to be amended to clearly indicate at what RunLevel they can execute. (default will be that all RunLevels have executed). Module tasks (@OnStartup) will also need to be catered for.
> Ideas, comments, please. There may be simpler ways of solving the problem but we should really keep an eye on allowing to start tasks as early as we allow today (i.e. not make startup performance worse). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)