Register protocol handlers in a lazy fashin #52
Conversation
Currently the activator loads the extension class what might trigger activation of bundles immediatly. This changes to a more lazy aproach where the extension class is only loaded at frist use of the protocol.
|
Hi Christoph. To make certain: This change is only about doing things more lazily, right? There isn't some bug or semantic change that this is meant to address? The reason I ask is that since this code used in Eclipse (p2) I recall something long ago about the p2 startup sequence (which I'm not completely familiar with) potentially requiring (at one point in the past if not now) a greedy startup/setting of the url stream handler service (maybe because equinox sets it as well?). At any rate I would ask that we do a little checking. I will help with this in the coming week. |
Correct, at least from my testing :-)
The handler is still eagerly registered, it is just delaying the loading of the implementation class until the first request is made to the handler, this is similar to changes in
Thanks! |
|
@scottslewis any idea about the build? I can't really understand what is causing the failure or how to see the full buildlog... |
|
Christoph I have authorized you for this specific build. Let me know if this works for you:
|
|
It seems the PR just triggers another build so I just found the buildlog now, thanks! |
|
But now Github seems playing tricks on me if I look here: I see 4 changed files, but this PR only shows 3 changed files.... |
|
I have created a new PR now, sorry for confusion: |
Currently the activator loads the extension class what might trigger activation of bundles immediatly.
This changes to a more lazy aproach where the extension class is only loaded at frist use of the protocol.