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. > >
