Bugzilla – Full Text Bug Listing
| Summary: | jdt.ui bundle activator assumes PlatformUI.getWorkbench(), causing autobuild failure when running headless | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Joe Toomey <jptoomey> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, dmorris, paulslau |
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Joe Toomey
The problem is that you have all plug-ins installed and enabled - including UI plug-ins. Now, these UI plug-ins register stuff when enabled and hence it can happen that such a plug-in is activated. Unless there is a real notion of "headless" in the Equinox or Platform which 1. enables a bundle to spec that it is (not) headless 2. offer to specify "headless" flag when launching 3. let the framework ignore non-headless bundles when launched with "headless" the only thing you can do to be safe is either not install or disable the UI plug-ins. NOTE: this is nothing new and like that for several releases. Moving to Equinox Core for comment (not sure whether that's the place where 'headless' notion would be introduced). Unfortunately, we aren't installing a headless application with too many plug-ins -- rather, we have a feature that allows users to launch services of TPTP from outside the workbench (i.e. run tests, generate reports, etc., from command line or ant, or an external Java application.) This is all done with a normal TPTP workbench install. This feature is also depended on by IBM consuming products (Rational Performance Tester, Rational Functional Tester and ClearQuest Test Manager.) That issue aside, I don't think I agree that the correct fix is to not have JDT UI installed -- I think this is a question of defensive programming. I would argue that this is implied API, and it has worked flawlessly in releases 3.0, 3.1 and 3.2. > NOTE: this is nothing new and like that for several releases. This is a regression in our use case, and is indeed something new. This problem was introduced with PreferenceConstants version 1.212 on 4/27, which was a fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=22243. It seems to me that it would be a straightforward fix to simply call PlatformUI.isWorkbenchRunning() before calling getWorkbench(), and if it returns false, simply fall back to the old way of setting color preferences (or even don't bother, since there's no UI anyway.) I hate to ask this, but would the likelihood of a fix (in JDT UI) change if I attached a proposed patch? Not that I don't have other work to do, but this is an important defect for us. Sure, JDT UI can *again* (just check bugzilla and you'll see) work around this but the point is that JDT UI is not meant to be installed in a headless environment. Most likely you will run into this issue with each release and we have to put a hack in again. Let's leave that bug here to solve the general issue. I'll put in a workaround in our land (M2 and R3_3_maintenance) for you. Joe, I looked into a workaround. What you wrote: >This is a regression in our use case, and is indeed something new. This >problem was introduced with PreferenceConstants version 1.212 on 4/27, is only half of the truth (and especially: not the main trigger). Just look at the other code in JavaPlugin.start(...) and put a breakpoint when PlatformUI.getWorkbench() is called. There are at least two very old places where this happens: - getASTProvider(); // (since March 2004) - new InitializeAfterLoadJob().schedule(); // (since May 2005) i.e. even reverting bug 22243 won't help. This however wasn't a problem so far because PDE's error reporter (BuildErrorReporter) didn't use file buffers. I've now hopefully fixed all those cases in JDT UI. Please try next weeks I- and/or M-build and check whether this works for you. HTH Dani Hi Joe, JDT restructure the code quite a but recently and I wanted to make sure we didn't break you again. Could you download the next 3.4 N-build or next weeks I-build and try it out? Thanks, Dani Thanks for the heads-up, Dani. I am no longer the owner of the component in question, so I have CC'd DuWayne Morris (new owner) and Paul Slauenwhite (TPTP Architecture Group lead). DuWayne, can you please verify that ASF execution of JUnit tests is not regressed in the build that Dani references in his comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199135#c5 ? Paul -- we're exposed in our ASF implementation to any eclipse code that may indirectly call PlatformUI.getWorkbench() (which throws an unchecked exception if the workbench has not been created, as is the case for any headless eclipse process.) We discussed this a few months ago, but I have some ideas for how to protect us from this scenario -- would be worth discussing sometime. (In reply to comment #6) > Thanks for the heads-up, Dani. > > I am no longer the owner of the component in question, so I have CC'd DuWayne > Morris (new owner) and Paul Slauenwhite (TPTP Architecture Group lead). > > DuWayne, can you please verify that ASF execution of JUnit tests is not > regressed in the build that Dani references in his comment: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=199135#c5 ? > > Paul -- we're exposed in our ASF implementation to any eclipse code that may > indirectly call PlatformUI.getWorkbench() (which throws an unchecked exception > if the workbench has not been created, as is the case for any headless eclipse > process.) We discussed this a few months ago, but I have some ideas for how to > protect us from this scenario -- would be worth discussing sometime. > Duwayne, please verify and post your findings to this defect. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. No feedback for 10 years. Closing. |