You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by JavaAdam <a....@cenit.de> on 2013/09/09 09:38:30 UTC
Is the higher OSGi version really needed?
Hi,
I have tried to deploy an OSGi application based on Apache Camel 2.11.1 on a
IBM WebSphere Application Server 8. But I failed, because Camel 2.11.1
requires a newer OSGi Specification than the WAS provides (Equinox 3.6.1).
My investigation shows that the import version of org.osgi.util.tracker was
increased from 1.4 to 1.5 in 2.11.x. I wonder if this version jump is really
needed or if it just happend automatically because of some dependencies in
the build system?
Fact is, that Apache Camel cannot be used on WAS 8 within a "real" OSGi
application based on the provided OSGi platform.
Indeed the solution could be to provide an own OSGi platform embedded in my
application. But this is not my favorite solution.
Thanks
Adam
--
View this message in context: http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924.html
Sent from the Camel - Users mailing list archive at Nabble.com.
AW: Is the higher OSGi version really needed?
Posted by JavaAdam <a....@cenit.de>.
I have checked the new WAS version 8.5. But it is still using Equinox 3.6.1 (OSGI 4.2).
Adam
Adam Wehner
ECM R&D
CENIT AG
Kaiserswerther Straße 115
D-40880 Ratingen
Tel : +49 (0)2102 55 115-61
a.wehner@cenit.de<ma...@cenit.de>
Von: Christian Schneider [via Camel] [mailto:ml-node+s465427n5738930h60@n5.nabble.com]
Gesendet: Montag, 9. September 2013 12:11
An: Wehner, Adam
Betreff: Re: Is the higher OSGi version really needed?
I think what he meant is that Camel currently can not run as a real
OSGi application in Websphere App Server 8.
So in this environment it would be really great if we could lower the
minimum needed OSGi version.
I checked what OSGi release matches the update from package version 1.4
to 1.5.
This seems to be the update from version 4.2 to 4.3. I think the main
difference is that we have API packages for version 4.3(.1) that support
generics on Java 7. Not sure if we depend on any other API changes.
On the other hand it might be quite some effort to make sure we import
only the lower package version while not switching everything back to 4.2.
I am not too familiar with Websphere. Is there a newer version that
supports OSGi 4.3? I have seen there is version 8.5 of websphere but did
not see any details about the supported OSGi specs.
Christian
On 09.09.2013 11:48, Andreas Gies wrote:
> Hmmm,
>
> I see your point and can't answer whether the version change is really
> required.
> I would challenge the claim that camel can't be used in a "real" OSGi
> application.
> I am using Camel all the time in OSGi based apps and I would call them
> real as they
> solve real problems.
>
> This having said, I am packaging the application myself and therefore
> can choose a fitting OSGi
> provider.
>
> Best regards
> Andreas
>
> On 09/09/2013 09:38 AM, JavaAdam wrote:
>> Hi,
>>
>> I have tried to deploy an OSGi application based on Apache Camel
>> 2.11.1 on a
>> IBM WebSphere Application Server 8. But I failed, because Camel 2.11.1
>> requires a newer OSGi Specification than the WAS provides (Equinox
>> 3.6.1).
>> My investigation shows that the import version of
>> org.osgi.util.tracker was
>> increased from 1.4 to 1.5 in 2.11.x. I wonder if this version jump is
>> really
>> needed or if it just happend automatically because of some
>> dependencies in
>> the build system?
>>
>> Fact is, that Apache Camel cannot be used on WAS 8 within a "real" OSGi
>> application based on the provided OSGi platform.
>>
>> Indeed the solution could be to provide an own OSGi platform embedded
>> in my
>> application. But this is not my favorite solution.
>>
>> Thanks
>> Adam
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
________________________________
If you reply to this email, your message will be added to the discussion below:
http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924p5738930.html
To unsubscribe from Is the higher OSGi version really needed?, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738924&code=YS53ZWhuZXJAY2VuaXQuZGV8NTczODkyNHwtMTI4NjY2MDI3MA==>.
NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: +49 711 7825-4000, Internet: www.cenit.de
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 00 SWIFT-Code : COBADEFF600,
BW-Bank (BLZ 600 501 01) Kto. 2 403 313 IBAN : DE17 6005 0101 0002 4033 13 SWIFT-Code : SOLADEST
Registergericht: Amtsgericht Stuttgart
Handelsregister: HRB Nr. 19117
Umsatzsteuer: ID-Nr. DE 147 862 777
--
View this message in context: http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924p5739538.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Is the higher OSGi version really needed?
Posted by Andreas Gies <an...@wayofquality.de>.
Point taken ;) - Was half joking.
Andreas
On 09/09/2013 12:10 PM, Christian Schneider wrote:
> I think what he meant is that Camel currently can not run as a real
> OSGi application in Websphere App Server 8.
> So in this environment it would be really great if we could lower the
> minimum needed OSGi version.
>
> I checked what OSGi release matches the update from package version
> 1.4 to 1.5.
> This seems to be the update from version 4.2 to 4.3. I think the main
> difference is that we have API packages for version 4.3(.1) that
> support generics on Java 7. Not sure if we depend on any other API
> changes.
>
> On the other hand it might be quite some effort to make sure we import
> only the lower package version while not switching everything back to
> 4.2.
>
> I am not too familiar with Websphere. Is there a newer version that
> supports OSGi 4.3? I have seen there is version 8.5 of websphere but
> did not see any details about the supported OSGi specs.
>
> Christian
>
>
>
> On 09.09.2013 11:48, Andreas Gies wrote:
>> Hmmm,
>>
>> I see your point and can't answer whether the version change is
>> really required.
>> I would challenge the claim that camel can't be used in a "real" OSGi
>> application.
>> I am using Camel all the time in OSGi based apps and I would call
>> them real as they
>> solve real problems.
>>
>> This having said, I am packaging the application myself and therefore
>> can choose a fitting OSGi
>> provider.
>>
>> Best regards
>> Andreas
>>
>> On 09/09/2013 09:38 AM, JavaAdam wrote:
>>> Hi,
>>>
>>> I have tried to deploy an OSGi application based on Apache Camel
>>> 2.11.1 on a
>>> IBM WebSphere Application Server 8. But I failed, because Camel 2.11.1
>>> requires a newer OSGi Specification than the WAS provides (Equinox
>>> 3.6.1).
>>> My investigation shows that the import version of
>>> org.osgi.util.tracker was
>>> increased from 1.4 to 1.5 in 2.11.x. I wonder if this version jump
>>> is really
>>> needed or if it just happend automatically because of some
>>> dependencies in
>>> the build system?
>>>
>>> Fact is, that Apache Camel cannot be used on WAS 8 within a "real" OSGi
>>> application based on the provided OSGi platform.
>>>
>>> Indeed the solution could be to provide an own OSGi platform
>>> embedded in my
>>> application. But this is not my favorite solution.
>>>
>>> Thanks
>>> Adam
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>
>
Re: Is the higher OSGi version really needed?
Posted by Christian Schneider <ch...@die-schneider.net>.
I think what he meant is that Camel currently can not run as a real
OSGi application in Websphere App Server 8.
So in this environment it would be really great if we could lower the
minimum needed OSGi version.
I checked what OSGi release matches the update from package version 1.4
to 1.5.
This seems to be the update from version 4.2 to 4.3. I think the main
difference is that we have API packages for version 4.3(.1) that support
generics on Java 7. Not sure if we depend on any other API changes.
On the other hand it might be quite some effort to make sure we import
only the lower package version while not switching everything back to 4.2.
I am not too familiar with Websphere. Is there a newer version that
supports OSGi 4.3? I have seen there is version 8.5 of websphere but did
not see any details about the supported OSGi specs.
Christian
On 09.09.2013 11:48, Andreas Gies wrote:
> Hmmm,
>
> I see your point and can't answer whether the version change is really
> required.
> I would challenge the claim that camel can't be used in a "real" OSGi
> application.
> I am using Camel all the time in OSGi based apps and I would call them
> real as they
> solve real problems.
>
> This having said, I am packaging the application myself and therefore
> can choose a fitting OSGi
> provider.
>
> Best regards
> Andreas
>
> On 09/09/2013 09:38 AM, JavaAdam wrote:
>> Hi,
>>
>> I have tried to deploy an OSGi application based on Apache Camel
>> 2.11.1 on a
>> IBM WebSphere Application Server 8. But I failed, because Camel 2.11.1
>> requires a newer OSGi Specification than the WAS provides (Equinox
>> 3.6.1).
>> My investigation shows that the import version of
>> org.osgi.util.tracker was
>> increased from 1.4 to 1.5 in 2.11.x. I wonder if this version jump is
>> really
>> needed or if it just happend automatically because of some
>> dependencies in
>> the build system?
>>
>> Fact is, that Apache Camel cannot be used on WAS 8 within a "real" OSGi
>> application based on the provided OSGi platform.
>>
>> Indeed the solution could be to provide an own OSGi platform embedded
>> in my
>> application. But this is not my favorite solution.
>>
>> Thanks
>> Adam
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Is the higher OSGi version really needed?
Posted by Andreas Gies <an...@wayofquality.de>.
Hmmm,
I see your point and can't answer whether the version change is really
required.
I would challenge the claim that camel can't be used in a "real" OSGi
application.
I am using Camel all the time in OSGi based apps and I would call them
real as they
solve real problems.
This having said, I am packaging the application myself and therefore
can choose a fitting OSGi
provider.
Best regards
Andreas
On 09/09/2013 09:38 AM, JavaAdam wrote:
> Hi,
>
> I have tried to deploy an OSGi application based on Apache Camel 2.11.1 on a
> IBM WebSphere Application Server 8. But I failed, because Camel 2.11.1
> requires a newer OSGi Specification than the WAS provides (Equinox 3.6.1).
> My investigation shows that the import version of org.osgi.util.tracker was
> increased from 1.4 to 1.5 in 2.11.x. I wonder if this version jump is really
> needed or if it just happend automatically because of some dependencies in
> the build system?
>
> Fact is, that Apache Camel cannot be used on WAS 8 within a "real" OSGi
> application based on the provided OSGi platform.
>
> Indeed the solution could be to provide an own OSGi platform embedded in my
> application. But this is not my favorite solution.
>
> Thanks
> Adam
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Is-the-higher-OSGi-version-really-needed-tp5738924.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>