FWIW, the MANIFEST.MF is supposed to be the first entry in the zip file, and the limitations on the line length is imposed by the JRE, not OSGi per se. It's just that the JVM usually don't care about the manifest, whereas OSGi always need to read it...
On Mon, Feb 15, 2010 at 11:48, Gert Vanthienen <[email protected]> wrote: > L.S., > > I don't think there's anything special to the packaging of the > manifest file -- as long as it's in the archive under the META-INF > directory, it shouldn't really matter how the ZIP/JAR file was > created. However, the OSGi runtime is very picky about how the > MANIFEST.MF file looks (line delimiters, maximum line length, special > syntax for imports/exports, ...) so it's very easy to get into trouble > when manually editing the MANIFEST. > > Anyway, thanks for raising the JIRA issue, I think the important thing > here is to get a more suitable error message so people know what is > going on when things fail. > > Regards, > > Gert Vanthienen > ------------------------ > Open Source SOA: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > > > > On 15 February 2010 09:25, TheWinch > <[email protected]> wrote: >> >> Issue created: https://issues.apache.org/jira/browse/FELIX-2077 >> >> By the way, I was meaning more than the fact an OSGi bundle's Manifest >> contains special entries. It seems that the Manifest should be placed >> somewhere special in the archive file (not sure this is bundle-specific). My >> broken bundles were plain working bundles that I had 1. unzipped, 2. >> modified the Manifest and 3. compressed again as a Zip file, changing the >> extension. It seems that the "jar" utility does more than just zip the >> contents of the file. >> >> >> >> Gert Vanthienen wrote: >>> >>> Vincent, >>> >>> Could you raise a Felix Karaf JIRA for this problem, describing the >>> steps we need to take to reproduce the problem? You're right that an >>> OSGi bundle is a JAR where the MANIFEST/META-INF file has to contain >>> some additional data. We won't be able to start a feature that has an >>> invalid jar in it, but we should be able to improve the error message >>> get ('null' is not a very descriptive error message ;) ) >>> >>> Regards, >>> >>> Gert Vanthienen >>> ------------------------ >>> Open Source SOA: http://fusesource.com >>> Blog: http://gertvanthienen.blogspot.com/ >>> >>> >>> >>> On 12 February 2010 15:38, TheWinch >>> <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> I think I just found the problem. Stepping into the code, I noticed that >>>> this problem occures when Karaf tries to install a bundle and it cannot >>>> read >>>> the Manifest. >>>> Checking again, I noticed that any time I have a failure, this is on a >>>> bundle that I unzipped, fixed Manifest and zipped again using a file >>>> archiver (7-zip to be precise). >>>> >>>> So it seems that a jar is not "just" a zip file, but the Manifest must >>>> appear at some place in the archive. When it cannot load the manifest, >>>> Karaf >>>> throws an exception that ends up finally showing "null" on the command >>>> line. >>>> >>>> To find the responsible bundle: >>>> - use features:install -c, the last installed bundle is the faulty one >>>> - or activate the "trace" log level and check the logs for the last >>>> bundle >>>> being installed. >>>> >>>> Note that this problem occures event if the bundle is already installed, >>>> because Karaf checks for version updates. >>>> >>>> Vincent >>>> >>>> >>>> Pgaz wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm currently experiencing the same problem. >>>>> I'm working with Apache Karaf 1.2.0 and I'm unable to find out why this >>>>> error is happening. >>>>> I think something's wrong in the download/install/start mechanism of the >>>>> features module of karaf, because as you said, it perfectlly works when >>>>> deploying by hand (I mean install -s ...). >>>>> >>>>> Any idea about that ? >>>>> Does it come from a malformed feature.xml, or a problem in the activator >>>>> ? >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> TheWinch wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'm experiencing a strange problem with the "features" functionality of >>>>>> Karaf. I'm trying to install a feature (which contains a single >>>>>> bundle), >>>>>> but it doesn't install. On the console I see a single debug message >>>>>> appear: >>>>>> >>>>>> ka...@root>features:install camel-activemq >>>>>> null >>>>>> >>>>>> I have installed manually all dependencies of activemq-camel. Then, I >>>>>> have tried to make another feature which just contains the >>>>>> activemq-camel >>>>>> bundle (v5.3.0) but I get the same result. When I install the bundle in >>>>>> isolation (using osgi:install -s) it works perfectly. >>>>>> >>>>>> Did someone already see this happen ? I have the same problem with a >>>>>> bundle of mine. I don't have a single clue about the problem (putting >>>>>> the >>>>>> log level to TRACE didn't help either). >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Vincent >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/-SMX4.1--Feature-won%27t-install-but-the-osgi-bundle-installs-fine-tp27270459p27564518.html >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> ----- >>> --- >>> Gert Vanthienen >>> http://gertvanthienen.blogspot.com >>> >> >> -- >> View this message in context: >> http://old.nabble.com/-SMX4.1--Feature-won%27t-install-but-the-osgi-bundle-installs-fine-tp27270459p27590666.html >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
