ClasspathScanner nominates Jar files that are not bundles (no Bundle-SymbolicName)

[GoogleCodeExporter]

According to section 3.2.1.16 of the OSGi Platform Core specification version 
4.3, the "Bundle-SymbolicName" header is required to be set in the bundle 
Manifest headers. That suggests to me that a Jar file that lacks such a header 
is not an OSGi bundle.

Against this, I noticed that class ClasspathScanner in package 
de.kalpatec.pojosr.framework.launch creates a BundleDescriptor for every Jar 
file it runs into, regardless of whether the Jar file's MANIFEST.MF file 
defines a "Bundle-SymbolicName" header. (See around line 67 in file 
ClasspathScanner.java.) There is a special treatment of when the header /is/ 
there, but the containing scanForBundles() method still accepts a Jar file 
lacking the header as a bundle just the same.

Is this an intentional choice? I would expect that only Jar files found that 
define a "Bundle-SymbolicName" header would be accepted, and the others would 
be skipped. It does seem possible for a caller to supply a filter that could 
mandate the presence of this header, but that requirement already seems to be 
implied by the specification. I would appreciate some clarification of the 
design intent here.

I notice this behavior in version 0.1.2-SNAPSHOT of the library.

Original issue reported on code.google.com by sehar...@gmail.com on 29 Jul 2011 at 1:01

[GoogleCodeExporter]

The Bundle-SymbolicName header is only required if we have an R4 bundle (i.e., 
Bundle-ManifestVersion=2). For R3 bundles there is no such requirement (in 
fact, all jars are valid bundles in R3). 

Initially, i made it so that only R4 bundles are recognized but later changed 
my mind as this is the standard behavior (you can install any jar as a bundle 
into real OSGi framework like felix too). Only if the are saying that they are 
R4 (Bundle-ManifestVersion=2) but don't specify a Bundle-SymbolicName header 
they are broken. 

As you already noticed, I added the possibility for a filter especially for 
this kind of situation (i.e., you can make your one policy using an ldap filter 
over the manifest attributes). I hope that is not a problem for you?

Original comment by karlpauls on 2 Aug 2011 at 10:29

• Changed state: Started
• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Ah, now I understand. I missed the detail about the change in R4; I thought 
that header had always been required to qualify as a bundle.

It's not a problem, because as you suggested, one can mandate that header with 
a filter:

  (Bundle-SymbolicName=*)

It would be nice to add a note on the Wiki about this, so that if other users 
wish to only pick up R4-compliant bundles, they would know how to do it and 
avoid being surprised by the more liberal normal behavior.

Thanks for following up and for sharing this project.

Original comment by sehar...@gmail.com on 3 Aug 2011 at 11:48

[GoogleCodeExporter]

Yeah, we need more usage documentation. I'll try to get to it. Thanks for 
looking into pojosr - feel free to let us know if you use it for something or 
have other problems.

Original comment by karlpauls on 16 Aug 2011 at 3:07

• Changed state: Done