Description Yury Kats 2011-03-18 10:10:29 EDT

Created attachment 191507 [details]
primefaces jar

A customer of an adopter product reported a problem with JSF jar files in workspace being locked. This, in turns, causes problems with project deletion and refactoring -- neither of the operations is possible because jsf jars can not be deleted.

In the scenario the customer imports an existing project with JSF jars in WEB-INF/lib. Once import completes, some of the jars are locked and can not be deleted. An example of such jar would be primefaces-2.2.1 (attached here). I believe, from my investigation, that the jar needs to have /resources/ folder in it, to cause the lock.

My debugging shows the following:

org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.FaceletTagIndex#DefaultProjectTaglibDescriptorFactory creates various locators/resolvers in its create() method.

I've commented them out one by one and found that the jars are locked only when the following is created:
            resourceLocators
                    .add(new JarBasedJSFResourceLocator(Collections.EMPTY_LIST,
                            new CopyOnWriteArrayList<ILocatorChangeListener>(),
                            new DefaultJarLocator(Collections
                                    .singletonList(new AlwaysMatcher()),
                                    new JavaCoreMediator()),
                            new ContentTypeResolver()));

Looking deeper into JarBasedJSFResourceLocator, the jar seems to be locked only when the following is executed inside its processJar method:

            tagLibsFound.add(new JarBasedJSFResource(
                    libRes, jarUrl, _contentTypeResolver));

It would seem that something in that JarBasedJSFResource class holds on to the Jar and thus prevents it from being closed.

Looking at JarBasedJSFResource I found this method:

    public boolean isAccessible()
    {
        JarFile jarFile = null;
        try
        {
            jarFile = getJarFile();
            if (jarFile != null)
            {
                final ZipEntry entry = getZipEntry(jarFile);
                return entry != null;
            }
        } finally
        {
            if (jarFile != null)
            {
//                try
//                {
//                    // TODO
////                    jarFile.close();
//                } /*catch (IOException e)
//                {
//                    // fall-through.
//                }*/
            }
        }
        return false;
    }

In here the JarFile is created, but never closed! 

I can't tell why jarFile.close() was commented out with a TODO comment, but it certainly causes the JAR file to be locked. Once I uncommented jarFile.close(), the jars were no longer locked.