You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Charles Moulliard <cm...@gmail.com> on 2010/08/13 10:54:02 UTC
Suggestion concerning camel bundles and services
Hi,
OSGI is an amazing world for architect and developers. They bring a new
concept in the development life cycle compare to monolithic J2EE application
and their WAR / EAR. The "modularity" provides advantages and of course
disadvantages like any other specification/technology.
To improve OSGI projects, I would like to suggest that in the future we do
two things :
1) Bundle Start Level
I suggest that we add the start bundle value for our camel components in the
feature xml file. This feature is available since Karaf 2.0. So we can group
what I call infrastructure bundles together and dissociate them from project
bundles. In this way, they will be activated and started before the bundle
projects. Using bundle start level is interesting but not enough in some
cases. So I suggest to do the following for by example HTTP, CXF components
2) Declarative Service
I suggest that we expose some services like CXF, HTTP, Servlet to allow a
project or camel to use OSGI Declarative Service (
http://felix.apache.org/site/apache-felix-service-component-runtime.html).
In this case, the project can react or be informed if by example jetty http
or cxf is not up and running. In the meantime, the infrastructure team or
the development project has no idea about the origin of the issue when web
service (configured through a camel route using cxf:bean) is not answering.
Is it because the bundles of cxf are not yet started or because the http
service of jetty is not running !!
I'm pretty sure that these suggestions will improve our ServiceMix platform
and will help architect to design more professional solutions for their
clients.
What do you think about that ?
Kind regards,
Charles Moulliard
Senior Enterprise Architect (J2EE, .NET, SOA)
Apache Camel - Karaf - ServiceMix Committer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Blog : http://cmoulliard.blogspot.com | Twitter :
http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard
Re: Suggestion concerning camel bundles and services
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Regards
JB
On 08/13/2010 01:17 PM, Adrian Trenaman wrote:
> Hi Charles,
>
> I think these are great ideas. Let me add another: we need to modify
> Karaf so that when you do an osgi:list, you see only the application
> bundles, not the system bundles. We should only see the
> system/infrastructure bundles if we do something like 'osgi:list -s' or
> 'osgi:list -v'. There's very little value for most users that when they
> do 'osgi:list' they get between 80 and 170 bundles listed, flying up
> their screen. Less is more: we should expose the interesting things
> easily, and allow users to see the background 'under-the-hood' stuff
> only when they like and when they're ready.
>
> Thoughts?
> Ade.
>
> On 13/08/2010 09:54, Charles Moulliard wrote:
>> Hi,
>>
>> OSGI is an amazing world for architect and developers. They bring a
>> new concept in the development life cycle compare to monolithic J2EE
>> application and their WAR / EAR. The "modularity" provides advantages
>> and of course disadvantages like any other specification/technology.
>>
>> To improve OSGI projects, I would like to suggest that in the future
>> we do two things :
>>
>> 1) Bundle Start Level
>> I suggest that we add the start bundle value for our camel components
>> in the feature xml file. This feature is available since Karaf 2.0. So
>> we can group what I call infrastructure bundles together and
>> dissociate them from project bundles. In this way, they will be
>> activated and started before the bundle projects. Using bundle start
>> level is interesting but not enough in some cases. So I suggest to do
>> the following for by example HTTP, CXF components
>>
>> 2) Declarative Service
>> I suggest that we expose some services like CXF, HTTP, Servlet to
>> allow a project or camel to use OSGI Declarative Service
>> (http://felix.apache.org/site/apache-felix-service-component-runtime.html).
>> In this case, the project can react or be informed if by example jetty
>> http or cxf is not up and running. In the meantime, the infrastructure
>> team or the development project has no idea about the origin of the
>> issue when web service (configured through a camel route using
>> cxf:bean) is not answering. Is it because the bundles of cxf are not
>> yet started or because the http service of jetty is not running !!
>>
>> I'm pretty sure that these suggestions will improve our ServiceMix
>> platform and will help architect to design more professional solutions
>> for their clients.
>>
>> What do you think about that ?
>>
>> Kind regards,
>>
>> Charles Moulliard
>>
>> Senior Enterprise Architect (J2EE, .NET, SOA)
>> Apache Camel - Karaf - ServiceMix Committer
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Blog : http://cmoulliard.blogspot.com | Twitter :
>> http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype:
>> cmoulliard
Re: Suggestion concerning camel bundles and services
Posted by Lars Heinemann <lh...@apache.org>.
+1 for that idea, Adrian.
Regards
Lars
2010/8/13 Adrian Trenaman <tr...@progress.com>:
> Hi Charles,
>
> I think these are great ideas. Let me add another: we need to modify Karaf
> so that when you do an osgi:list, you see only the application bundles, not
> the system bundles. We should only see the system/infrastructure bundles if
> we do something like 'osgi:list -s' or 'osgi:list -v'. There's very little
> value for most users that when they do 'osgi:list' they get between 80 and
> 170 bundles listed, flying up their screen. Less is more: we should expose
> the interesting things easily, and allow users to see the background
> 'under-the-hood' stuff only when they like and when they're ready.
>
> Thoughts?
> Ade.
>
> On 13/08/2010 09:54, Charles Moulliard wrote:
>>
>> Hi,
>>
>> OSGI is an amazing world for architect and developers. They bring a new
>> concept in the development life cycle compare to monolithic J2EE application
>> and their WAR / EAR. The "modularity" provides advantages and of course
>> disadvantages like any other specification/technology.
>>
>> To improve OSGI projects, I would like to suggest that in the future we do
>> two things :
>>
>> 1) Bundle Start Level
>> I suggest that we add the start bundle value for our camel components in
>> the feature xml file. This feature is available since Karaf 2.0. So we can
>> group what I call infrastructure bundles together and dissociate them from
>> project bundles. In this way, they will be activated and started before the
>> bundle projects. Using bundle start level is interesting but not enough in
>> some cases. So I suggest to do the following for by example HTTP, CXF
>> components
>>
>> 2) Declarative Service
>> I suggest that we expose some services like CXF, HTTP, Servlet to allow a
>> project or camel to use OSGI Declarative Service
>> (http://felix.apache.org/site/apache-felix-service-component-runtime.html).
>> In this case, the project can react or be informed if by example jetty http
>> or cxf is not up and running. In the meantime, the infrastructure team or
>> the development project has no idea about the origin of the issue when web
>> service (configured through a camel route using cxf:bean) is not answering.
>> Is it because the bundles of cxf are not yet started or because the http
>> service of jetty is not running !!
>>
>> I'm pretty sure that these suggestions will improve our ServiceMix
>> platform and will help architect to design more professional solutions for
>> their clients.
>>
>> What do you think about that ?
>>
>> Kind regards,
>>
>> Charles Moulliard
>>
>> Senior Enterprise Architect (J2EE, .NET, SOA)
>> Apache Camel - Karaf - ServiceMix Committer
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Blog : http://cmoulliard.blogspot.com | Twitter :
>> http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard
>
--
http://lhein.blogspot.com
Fwd: Suggestion concerning camel bundles and services
Posted by Charles Moulliard <cm...@gmail.com>.
Great idea.
We should use the bundle start level to filter what we display on the
screen. By default it is equal to 50 but that means that the client must add
it in its project bundles and that we add it in the camel, karaf, servicemix
bundles too. Otherwise, the list will not be filtered
In this case we could provide as a parameter the bundle start level as an
option :
osgi:list -l 50
l = level from which we would like to display the bundles
or maybe
osgi:list -l 50-100
to be able to display range of bundles
Regards
Charles
On Fri, Aug 13, 2010 at 1:17 PM, Adrian Trenaman <tr...@progress.com>wrote:
> Hi Charles,
>
> I think these are great ideas. Let me add another: we need to modify Karaf
> so that when you do an osgi:list, you see only the application bundles, not
> the system bundles. We should only see the system/infrastructure bundles if
> we do something like 'osgi:list -s' or 'osgi:list -v'. There's very little
> value for most users that when they do 'osgi:list' they get between 80 and
> 170 bundles listed, flying up their screen. Less is more: we should expose
> the interesting things easily, and allow users to see the background
> 'under-the-hood' stuff only when they like and when they're ready.
>
> Thoughts?
> Ade.
>
>
> On 13/08/2010 09:54, Charles Moulliard wrote:
>
>> Hi,
>>
>> OSGI is an amazing world for architect and developers. They bring a new
>> concept in the development life cycle compare to monolithic J2EE application
>> and their WAR / EAR. The "modularity" provides advantages and of course
>> disadvantages like any other specification/technology.
>>
>> To improve OSGI projects, I would like to suggest that in the future we do
>> two things :
>>
>> 1) Bundle Start Level
>> I suggest that we add the start bundle value for our camel components in
>> the feature xml file. This feature is available since Karaf 2.0. So we can
>> group what I call infrastructure bundles together and dissociate them from
>> project bundles. In this way, they will be activated and started before the
>> bundle projects. Using bundle start level is interesting but not enough in
>> some cases. So I suggest to do the following for by example HTTP, CXF
>> components
>>
>> 2) Declarative Service
>> I suggest that we expose some services like CXF, HTTP, Servlet to allow a
>> project or camel to use OSGI Declarative Service (
>> http://felix.apache.org/site/apache-felix-service-component-runtime.html).
>> In this case, the project can react or be informed if by example jetty http
>> or cxf is not up and running. In the meantime, the infrastructure team or
>> the development project has no idea about the origin of the issue when web
>> service (configured through a camel route using cxf:bean) is not answering.
>> Is it because the bundles of cxf are not yet started or because the http
>> service of jetty is not running !!
>>
>> I'm pretty sure that these suggestions will improve our ServiceMix
>> platform and will help architect to design more professional solutions for
>> their clients.
>>
>> What do you think about that ?
>>
>> Kind regards,
>>
>> Charles Moulliard
>>
>> Senior Enterprise Architect (J2EE, .NET, SOA)
>> Apache Camel - Karaf - ServiceMix Committer
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Blog : http://cmoulliard.blogspot.com | Twitter :
>> http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype:
>> cmoulliard
>>
>
Fwd: Suggestion concerning camel bundles and services
Posted by Charles Moulliard <cm...@gmail.com>.
Great idea.
We should use the bundle start level to filter what we display on the
screen. By default it is equal to 50 but that means that the client must add
it in its project bundles and that we add it in the camel, karaf, servicemix
bundles too. Otherwise, the list will not be filtered
In this case we could provide as a parameter the bundle start level as an
option :
osgi:list -l 50
l = level from which we would like to display the bundles
or maybe
osgi:list -l 50-100
to be able to display range of bundles
Regards
Charles
On Fri, Aug 13, 2010 at 1:17 PM, Adrian Trenaman <tr...@progress.com>wrote:
> Hi Charles,
>
> I think these are great ideas. Let me add another: we need to modify Karaf
> so that when you do an osgi:list, you see only the application bundles, not
> the system bundles. We should only see the system/infrastructure bundles if
> we do something like 'osgi:list -s' or 'osgi:list -v'. There's very little
> value for most users that when they do 'osgi:list' they get between 80 and
> 170 bundles listed, flying up their screen. Less is more: we should expose
> the interesting things easily, and allow users to see the background
> 'under-the-hood' stuff only when they like and when they're ready.
>
> Thoughts?
> Ade.
>
>
> On 13/08/2010 09:54, Charles Moulliard wrote:
>
>> Hi,
>>
>> OSGI is an amazing world for architect and developers. They bring a new
>> concept in the development life cycle compare to monolithic J2EE application
>> and their WAR / EAR. The "modularity" provides advantages and of course
>> disadvantages like any other specification/technology.
>>
>> To improve OSGI projects, I would like to suggest that in the future we do
>> two things :
>>
>> 1) Bundle Start Level
>> I suggest that we add the start bundle value for our camel components in
>> the feature xml file. This feature is available since Karaf 2.0. So we can
>> group what I call infrastructure bundles together and dissociate them from
>> project bundles. In this way, they will be activated and started before the
>> bundle projects. Using bundle start level is interesting but not enough in
>> some cases. So I suggest to do the following for by example HTTP, CXF
>> components
>>
>> 2) Declarative Service
>> I suggest that we expose some services like CXF, HTTP, Servlet to allow a
>> project or camel to use OSGI Declarative Service (
>> http://felix.apache.org/site/apache-felix-service-component-runtime.html).
>> In this case, the project can react or be informed if by example jetty http
>> or cxf is not up and running. In the meantime, the infrastructure team or
>> the development project has no idea about the origin of the issue when web
>> service (configured through a camel route using cxf:bean) is not answering.
>> Is it because the bundles of cxf are not yet started or because the http
>> service of jetty is not running !!
>>
>> I'm pretty sure that these suggestions will improve our ServiceMix
>> platform and will help architect to design more professional solutions for
>> their clients.
>>
>> What do you think about that ?
>>
>> Kind regards,
>>
>> Charles Moulliard
>>
>> Senior Enterprise Architect (J2EE, .NET, SOA)
>> Apache Camel - Karaf - ServiceMix Committer
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Blog : http://cmoulliard.blogspot.com | Twitter :
>> http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype:
>> cmoulliard
>>
>
Re: Suggestion concerning camel bundles and services
Posted by Adrian Trenaman <tr...@progress.com>.
Hi Charles,
I think these are great ideas. Let me add another: we need to modify
Karaf so that when you do an osgi:list, you see only the application
bundles, not the system bundles. We should only see the
system/infrastructure bundles if we do something like 'osgi:list -s' or
'osgi:list -v'. There's very little value for most users that when they
do 'osgi:list' they get between 80 and 170 bundles listed, flying up
their screen. Less is more: we should expose the interesting things
easily, and allow users to see the background 'under-the-hood' stuff
only when they like and when they're ready.
Thoughts?
Ade.
On 13/08/2010 09:54, Charles Moulliard wrote:
> Hi,
>
> OSGI is an amazing world for architect and developers. They bring a
> new concept in the development life cycle compare to monolithic J2EE
> application and their WAR / EAR. The "modularity" provides advantages
> and of course disadvantages like any other specification/technology.
>
> To improve OSGI projects, I would like to suggest that in the future
> we do two things :
>
> 1) Bundle Start Level
> I suggest that we add the start bundle value for our camel components
> in the feature xml file. This feature is available since Karaf 2.0. So
> we can group what I call infrastructure bundles together and
> dissociate them from project bundles. In this way, they will be
> activated and started before the bundle projects. Using bundle start
> level is interesting but not enough in some cases. So I suggest to do
> the following for by example HTTP, CXF components
>
> 2) Declarative Service
> I suggest that we expose some services like CXF, HTTP, Servlet to
> allow a project or camel to use OSGI Declarative Service
> (http://felix.apache.org/site/apache-felix-service-component-runtime.html).
> In this case, the project can react or be informed if by example jetty
> http or cxf is not up and running. In the meantime, the infrastructure
> team or the development project has no idea about the origin of the
> issue when web service (configured through a camel route using
> cxf:bean) is not answering. Is it because the bundles of cxf are not
> yet started or because the http service of jetty is not running !!
>
> I'm pretty sure that these suggestions will improve our ServiceMix
> platform and will help architect to design more professional solutions
> for their clients.
>
> What do you think about that ?
>
> Kind regards,
>
> Charles Moulliard
>
> Senior Enterprise Architect (J2EE, .NET, SOA)
> Apache Camel - Karaf - ServiceMix Committer
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Blog : http://cmoulliard.blogspot.com | Twitter :
> http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard