You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Pgaz <gn...@irisa.fr> on 2010/02/12 15:19:21 UTC
Re: [SMX4.1] Feature won't install but the osgi bundle installs
fine
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:
>
> karaf@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-tp27270459p27564241.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: [SMX4.1] Feature won't install but the osgi bundle installs fine
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<ge...@gmail.com> 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
> <vi...@thalesgroup.com> 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
>>> <vi...@thalesgroup.com> 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:
>>>>>>
>>>>>> karaf@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
Re: [SMX4.1] Feature won't install but the osgi bundle installs fine
Posted by Gert Vanthienen <ge...@gmail.com>.
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
<vi...@thalesgroup.com> 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
>> <vi...@thalesgroup.com> 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:
>>>>>
>>>>> karaf@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.
>
>
Re: [SMX4.1] Feature won't install but the osgi bundle installs
fine
Posted by TheWinch <vi...@thalesgroup.com>.
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
> <vi...@thalesgroup.com> 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:
>>>>
>>>> karaf@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.
Re: [SMX4.1] Feature won't install but the osgi bundle installs fine
Posted by Gert Vanthienen <ge...@gmail.com>.
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
<vi...@thalesgroup.com> 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:
>>>
>>> karaf@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.
>
>
Re: [SMX4.1] Feature won't install but the osgi bundle installs
fine
Posted by TheWinch <vi...@thalesgroup.com>.
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:
>>
>> karaf@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.