NamingManager fails to find java.naming.factory.initial during reindex #2211
Comments
|
I think this does not break the Jersey client functionality. It is logged from here: private static ExecutorService lookupManagedExecutorService() {
// Get the default ManagedExecutorService, if available
try {
// Android and some other environments don't have InitialContext class available.
final Class<?> aClass =
AccessController.doPrivileged(ReflectionHelper.classForNamePA("javax.naming.InitialContext"));
final Object initialContext = aClass.newInstance();
final Method lookupMethod = aClass.getMethod("lookup", String.class);
return (ExecutorService) lookupMethod.invoke(initialContext, "java:comp/DefaultManagedExecutorService");
} catch (Exception e) {
// ignore
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE, e.getMessage(), e);
}
} catch (LinkageError error) {
// ignore - JDK8 compact2 profile - http://openjdk.java.net/jeps/161
}
return null;
}which is called from here private static final ExecutorService MANAGED_EXECUTOR_SERVICE = lookupManagedExecutorService();However, there is a null check and other default behaviour so it does not seem it is a big deal: if (MANAGED_EXECUTOR_SERVICE != null) {
defaultAsyncExecutorProvider = new ClientExecutorServiceProvider(MANAGED_EXECUTOR_SERVICE);
} else {
defaultAsyncExecutorProvider = new DefaultClientAsyncExecutorProvider(0);
}I cannot reproduce on my setup. Maybe Solaris specific? Either way, this code should log an exception instead of printing to stderr: Response r = ClientBuilder.newClient()
.target(env.getConfigHost())
.path("api")
.path("v1")
.path("projects")
.path(Util.URIEncode(project.getName()))
.path("indexed")
.request()
.put(Entity.text(""));
if (r.getStatusInfo().getFamily() != Response.Status.Family.SUCCESSFUL) {
System.err.println("Couldn't notify the webapp: " + r.toString());
} |
|
I see that the logging of the |
|
So, Jersey needs an implementation of
So, JNDI needs to be setup in order to perform the lookup. It needs the According to https://docs.oracle.com/javase/tutorial/jndi/ops/faq.html#1 (and https://stackoverflow.com/questions/1525385/noinitialcontextexception-error) the
Now, Tomcat does actually perform some voodoo to inject the initialContext factory. According to https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html
https://stackoverflow.com/questions/17573219/how-does-tomcat-inject-the-jndi-component-local-context explains how this works:
So evidently this mechanism got broken somehow. I wonder if the trick still works with the above code using reflection. |
|
I know it's not that important, but can we mute it? |
|
I am seeing a similar exception thrown indexing one of my projects with 1.2.8. It seems to be I see multiple (at least 2) occurrences of this within the same projects indexing: |
Definitely can be muted. The exception is thrown from Jersey code at the Setting the log level to I constructed a test case using I corrected this in the https://github.com/oracle/opengrok/wiki/Debugging#indexer As quoted on #2211 (comment), the lookup is meant for Java EE environment, which the indexer is not, hence closing. |
|
For the record, here is the log snippet of the recent indexer run with the global log level set to |
|
Actually, I found some sample |
Since upgrading to 1.1-rc31 the following (seemingly innocuous) exception is thrown during indexing:
The text was updated successfully, but these errors were encountered: