Skip to content
Permalink
Browse files

So far unsuccessful attempt to make Jenkins startup more robust again…

…st bugs like JENKINS-25440.

Even though SezpozModule.configure catches and ignores the faulty component, Guice still dies:
… hudson.ExtensionFinder$GuiceFinder <init>
SEVERE: Failed to create Guice container from all the plugins
com.google.inject.internal.guava.collect.$ComputationException: java.lang.NoClassDefFoundError: org/eclipse/jgit/storage/file/FileRepository
	at …
	at com.google.inject.Guice.createInjector(Guice.java:73)
	at hudson.ExtensionFinder$GuiceFinder.<init>(ExtensionFinder.java:279)
  • Loading branch information...
jglick committed Nov 4, 2014
1 parent a6a3d5e commit 22d433deae5e8e056f83900cc6c9bcc5a3ba60d5
Showing with 8 additions and 7 deletions.
  1. +8 −7 core/src/main/java/hudson/ExtensionFinder.java
@@ -281,6 +281,7 @@ protected void configure() {
LOGGER.log(Level.SEVERE, "Failed to create Guice container from all the plugins",e);
// failing to load all bindings are disastrous, so recover by creating minimum that works
// by just including the core
// TODO this recovery is pretty much useless; startup crashes anyway
container = Guice.createInjector(new SezpozModule(loadSezpozIndices(Jenkins.class.getClassLoader())));
}

@@ -355,7 +356,7 @@ private Object instantiate(IndexItem<?,Object> item) {
// which results in a LinkageError
LOGGER.log(isOptional(item.annotation()) ? Level.FINE : Level.WARNING,
"Failed to load "+item.className(), e);
} catch (InstantiationException e) {
} catch (Exception e) {
LOGGER.log(isOptional(item.annotation()) ? Level.FINE : Level.WARNING,
"Failed to load "+item.className(), e);
}
@@ -478,8 +479,10 @@ private void resolve(Class c) {
Method m = ClassLoader.class.getDeclaredMethod("resolveClass", Class.class);
m.setAccessible(true);
m.invoke(ecl, c);
c.getConstructors();
c.getMethods();
c.getFields();
c.getFields();
LOGGER.log(Level.FINER, "{0} looks OK", c);
while (c != Object.class) {
c.getGenericSuperclass();
c = c.getSuperclass();
@@ -534,7 +537,7 @@ public Object get() {
// which results in a LinkageError
LOGGER.log(optional ? Level.FINE : Level.WARNING,
"Failed to load "+item.className(), e);
} catch (InstantiationException e) {
} catch (Exception e) {
LOGGER.log(optional ? Level.FINE : Level.WARNING,
"Failed to load "+item.className(), e);
}
@@ -644,7 +647,7 @@ public synchronized ExtensionComponentSet refresh() {
// sometimes the instantiation fails in an indirect classloading failure,
// which results in a LinkageError
LOGGER.log(logLevel(item), "Failed to load "+item.className(), e);
} catch (InstantiationException e) {
} catch (Exception e) {
LOGGER.log(logLevel(item), "Failed to load "+item.className(), e);
}
}
@@ -675,9 +678,7 @@ public void scout(Class extensionType, Hudson hudson) {
// according to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6459208
// this appears to be the only way to force a class initialization
Class.forName(extType.getName(),true,extType.getClassLoader());
} catch (InstantiationException e) {
LOGGER.log(logLevel(item), "Failed to scout "+item.className(), e);
} catch (ClassNotFoundException e) {
} catch (Exception e) {
LOGGER.log(logLevel(item), "Failed to scout "+item.className(), e);
} catch (LinkageError e) {
LOGGER.log(logLevel(item), "Failed to scout "+item.className(), e);

4 comments on commit 22d433d

@jglick

This comment has been minimized.

Copy link
Member Author

replied Nov 5, 2014

@kohsuke FYI, Guice system still does not protect against all problems in plugins. This one is easily reproduced but I did not manage to track it down.

@jglick

This comment has been minimized.

Copy link
Member Author

replied Nov 5, 2014

Did a little more debugging. It turns out that there are two extensions at play. JenkowWorkflowRepository is the one that has a NoClassDefFoundError, which configure does notice, so this extension is skipped with a warning. But then there is also JenkowWorkflowRepositorySSHAccess which @Injects a JenkowWorkflowRepository. configure does not get any error from that, so it passes it on to Guice to bind, which then dies with the linkage error.

I tried to reproduce all this in ExtensionFinderTest.testFailingInstance without luck. It seems that this test is provoking a different kind of error: one caught by FaultTolerantScope, whereas the problem here is errors caught earlier by SezpozModule.resolve. I am not sure how to adjust the test to behave the way I expect it to, since the real behavior involves a linkage error thrown when resolving a class, rather than instantiating it.

How serious is this? The severity is critical: Jenkins does not start. On the other hand, the problem only seems to affect cases where there is not only a linkage error (hopefully unusual), but @Inject is also used among extensions (which is rarely done).

@kohsuke

This comment has been minimized.

Copy link
Member

replied Nov 5, 2014

I'm missing the context here. Is there a way for me to reproduce this? It sounds like I need to run Jenkow plugin with some specific version of git-client plugin?

It feels like this is something we can punt on for a few weeks easily. Yes, Jenkins fails to start, but hopefully the log is making it obvious where the problem lies (or is it not?), and so the admin can be instructed to go into $JENKINS_HOME and downgrade/remove faulty plugins. I think it's a fairly straightforward procedure.

@jglick

This comment has been minimized.

Copy link
Member Author

replied Jan 15, 2015

I'm missing the context here. Is there a way for me to reproduce this?

JENKINS-25440 is the context. IIRC I merely tried to install the Jenkow plugins on 1.580.x.

hopefully the log is making it obvious where the problem lies

It does not.

Please sign in to comment.
You can’t perform that action at this time.