Community
Participate
Working Groups
Build Identifier: org.eclipse.equinox.metatype_1.0.100.v20100503 Ich the OSGI-INF/metatype directory contains (for example from svn) for each directory entry the following exception is raised: java.io.FileNotFoundException: /<Path To Plugin / Bundle>/OSGI-INF/metatype/.svn (Is a directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at org.eclipse.osgi.framework.util.SecureAction.getFileInputStream(SecureAction.java:123) at org.eclipse.osgi.baseadaptor.bundlefile.FileBundleEntry.getInputStream(FileBundleEntry.java:56) at org.eclipse.osgi.framework.internal.core.BundleURLConnection.connect(BundleURLConnection.java:53) at org.eclipse.osgi.framework.internal.core.BundleURLConnection.getInputStream(BundleURLConnection.java:99) at java.net.URL.openStream(URL.java:1010) at org.eclipse.equinox.metatype.DataParser.doParse(DataParser.java:105) at org.eclipse.equinox.metatype.MetaTypeProviderImpl.readMetaFiles(MetaTypeProviderImpl.java:99) at org.eclipse.equinox.metatype.MetaTypeProviderImpl.<init>(MetaTypeProviderImpl.java:51) at org.eclipse.equinox.metatype.MetaTypeInformationImpl.<init>(MetaTypeInformationImpl.java:35) at org.eclipse.equinox.metatype.MetaTypeServiceImpl$1.run(MetaTypeServiceImpl.java:69) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.equinox.metatype.MetaTypeServiceImpl.getMetaTypeProvider(MetaTypeServiceImpl.java:67) at org.eclipse.equinox.metatype.MetaTypeServiceImpl.getMetaTypeInformation(MetaTypeServiceImpl.java:47) at de.laeubisoft.swingx.configuration.internal.ConfigurationComponent.addConfigurationBundle(ConfigurationComponent.java:106) at de.laeubisoft.swingx.configuration.internal.ConfigurationComponent.start(ConfigurationComponent.java:74) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:329) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:580) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) at org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:323) at org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:221) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:525) at org.eclipse.equinox.internal.cm.Activator.start(Activator.java:53) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1067) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337) Reproducible: Always Steps to Reproduce: 1. Create a directory inside the metatype directory 2. run the framework
I'm going to queue this up for 3.8. The message appears because of some calls to printStackTrace() within the DataParser.doParse() method. We may want to remove those and possibly replace them with a DEBUG log message. This exception does not prevent metadata XML resources within the OSGI-INF/metatype directory from being processed. We may also want to consider whether or not it would be worthwhile to expand the search for metadata XML resources to all sub-directories of OSGI-INF/metatype. Currently, all resources are expected to be directly underneath the metatype directory. A strict interpretation of the spec seems to support this. 105.7 (pg 114) A bundle that wants to provide meta type resources must place these resources in the OSGI-INF/metatype directory. The name of the resource must be a valid JAR path. All resources in that directory must be meta type documents. However, it might be a nice feature of the implementation to support recursive searches.
(In reply to comment #1) > However, it might be a nice feature of the implementation to support recursive > searches. I would not suggest deviating from the specification on this. If the specification does not allow recursive searches, then I would not suggest we add support for that. Usually that just opens us up for bugs about not complying with the specification. Or are you suggesting that the specification is not clear on if recursive searches should be done or not?
> Or are you suggesting that the specification is not clear on if recursive > searches should be done or not? I also think the specification is a bit unclear: In the introduction it say's "OSGI-INF/metatype directories must be scanned for any XML resource" In my opionion this would include searching recursive... but as quoted above by John W Ross if it has to 'All resources in that directory must be meta type documents' and a folder is also a "resource" but not a metatype document... er... confusing :) The problem is still, that for SVN I can't hold the 'All resources in that directory must be meta type documents' rule:-\ Beside this, generating a warning/debug info might be the best solution in my opinion.
(In reply to comment #2) > Or are you suggesting that the specification is not clear on if recursive > searches should be done or not? Yes, I'm suggesting that might be open for debate. What I posted in my previous comment is the only thing I can find in the spec that might support the argument that recursive searches are prohibited.
Move all 3.8 bugs to Juno.
Unfortunately, the work done in bug 350201 and bug 346804 didn't help here. An error message will still be logged if any URL returned by BundleWiring.findEntries does not point to a valid metadata XML file. Assuming we're not interested in supporting recursive searches, one thing to do would be to disable recursive searches on findEntries by setting the FINDENTRIES_RECURSE option. This would alleviate but not completely solve the issue since directory entries off the root level would still be returned. We could potentially use a filePattern of "*.xml", but the spec does not require metadata files to end in that extension. I wonder if it would be worthwhile to suggest a new option be added to BundleWiring.findEntries along the lines of FINDENTRIES_NODIRS.
(In reply to comment #6) > I wonder if it would be worthwhile to suggest a new option be added to > BundleWiring.findEntries along the lines of FINDENTRIES_NODIRS. No, although the javadoc does not appear to be clear on this point; I think URLs to directory entries should end with '/'. I think our implementation can safely ignore URLs with a path ending in '/'.
Created attachment 198990 [details] proposed patch This patch disables recursive searches for BundleWiring.findEntries and ignores entries that end with '/'.
Patch released.
