Fixed issue #26: Starting eclipse's help feature just shows you a 500 error, ond depending on your eclipse version, a long stack trace.

The problem boiled down to the JSP compiler used by the help system also being instrumented with lombok, but that's not exactly the environment lombok was expecting. Fixed by simply disabling lombok when the environments don't match what we expect. In the process, the instrumentation has been made a little more robust; multiple separate OSGi modules can all be instrumented now, instead of the first one winning.

1 files changed, 11 insertions, 1 deletions

diff --git a/src/lombok/eclipse/TransformEclipseAST.java b/src/lombok/eclipse/TransformEclipseAST.java
index ff40c110..9bc3326f 100644
--- a/src/lombok/eclipse/TransformEclipseAST.java
+++ b/src/lombok/eclipse/TransformEclipseAST.java
@@ -96,7 +96,17 @@ public class TransformEclipseAST {
 				EclipseAST.addProblemToCompilationResult(ast, false, message, 0, 0);
 				t.printStackTrace();
 			} catch ( Throwable t2 ) {
-				Eclipse.error(ast, "Can't create an error in the problems dialog while adding: " + t.toString(), t2);
+				try {
+					Eclipse.error(ast, "Can't create an error in the problems dialog while adding: " + t.toString(), t2);
+				} catch ( Throwable t3 ) {
+					//This seems risky to just silently turn off lombok, but if we get this far, something pretty
+					//drastic went wrong. For example, the eclipse help system's JSP compiler will trigger a lombok call,
+					//but due to class loader shenanigans we'll actually get here due to a cascade of
+					//ClassNotFoundErrors. This is the right action for the help system (no lombok needed for that JSP compiler,
+					//of course). 'disableLombok' is static, but each context classloader (e.g. each eclipse OSGi plugin) has
+					//it's own edition of this class, so this won't turn off lombok everywhere.
+					disableLombok = true;
+				}
 			}
 		}
 	}