Possible regression due to 550548 changes from Activator to FilesSystemAccess in UnixFileNatives
Closed this issue · 7 comments
IBM product Enterprise Workflow Management (EWM), formerly known as Rational Team Concert (RTC) has various components based on Eclipse. The focus of this issue is on what is known as the EWM Build Toolkit that supports compilation of SCM source files on a given target platform (for example, compiling z/OS source code on z/OS or AIX source code on AIX).
The current EWM release in the field is based on Eclipse 4.6. The team is investigating moving up to later Eclipse.
When testing with 4.15 on z/OS in this EWM Build Toolkit context, we see :
_* /u/builder/jan7/rtcEnterpriseBuild.xml:71: java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.ensureError(J9VMInternals.java:145)
at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:134)
at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.isLibraryPresent(UnixFileNatives.java:57)
at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.(UnixFileNatives.java:47)_
We have found through experimentation that replacing the 4.15 org.eclipse.core.filesystem plugin with 4.6 (and no z/OS specific plugin) seems to workaround the problem.
We know there are specific code changes in UnixFileNatives.java between these levels.
It was suggested that this change could be causing the problem :
Bug 550548 - Remove activator from org.eclipse.core.filesystem
where
Activator.findEntries("/", libName, true);
is changed to
FileSystemAccess.findEntries("/", libName, true);_
I think the issue is:
private static BundleContext context = FrameworkUtil.getBundle(FileSystemAccess.class).getBundleContext();
As it falsely assumes that a class can only be loaded from an activated/started bundle. But if the class happened to be initialized before the activator run, the bundlecontext might be null and will never change!
So it would be interesting to see a full stack trace and if an NPE is involved somewhere.
@vogella I think one should never init this in a static way but call FrameworkUtil.getBundle(FileSystemAccess.class).getBundleContext(); at every call and more important check for null, also in case of the findEntries it seems cumbersume to first get the bundle, then the context to then get the bundle from it.
Re the request for more stack trace minus implementation specific bits ...
/u/builder/jan7/rtcEnterpriseBuild.xml:71: java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.ensureError(J9VMInternals.java:145)
at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:134)
at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.isLibraryPresent(UnixFileNatives.java:57)
at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.<clinit>(UnixFileNatives.java:47)
at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.<clinit>(LocalFileNativesManager.java:42)
at org.eclipse.core.internal.filesystem.local.LocalFileSystem.attributes(LocalFileSystem.java:84)
at com.ibm.team.filesystem.client.internal.ManagedFileStore.<clinit>(ManagedFileStore.java:137)
......
Caused by: java.lang.NullPointerException
at org.eclipse.core.internal.filesystem.FileSystemAccess.<clinit>(FileSystemAccess.java:32)
... 68 more
Thanks, this indicates the class is used outside of OSGi is this the case here?
This should be fixed in the next I-build please test and report back if there are any issues left.
We have tested this by patching this fix on Eclipse 4.15 and the issue mentioned in [https://github.com//issues/157] is not seen post this patching.
The associated fix also resolved the issue on z/OS for me. I apologize I had not posted here earlier - I thought I had ...