You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Bob Paulin <bo...@bobpaulin.com> on 2019/12/04 14:48:14 UTC
Re: Camel Main for OSGi?
Hi wanted to bring some discussion back to the list from GitHub since I
think the list is a better place to discuss:
From Claus Ibsen:
<snip>
Thanks for keep working on this.
Thanks so what I think is really taking people with some surprise is
that it registers Camel routes into the *same single camel context* from
any bundles. The point of Apache Karaf was to be like an app server
where each bundle is isolated. So this goes against this practice. This
should be documented much much more clearly. And also it lacks features
with the ease of use how to configure camel context itself (you end up
with its defaults) and how would people do dependency injections for
beans etc.
Also it should be renamed to |camel-osgi-activator|, and moved to
components (as its not a core piece, eg not used by other osgi like osgi
blueprint which is the main osgi support in Camel).
</snip>
Full PR context [1] [2].
Responses to key points
1) Why *same single camel context* from any bundles?
There are many ways this could be done in OSGi so the idea behind this
module was to provide an opinionated approach that enables a developer
to get started faster much like the spring boot approach. A single
context trades off some flexibility for simplicity to allow a developer
to get going quickly. This module also takes advantage of OSGi's
dynamic nature to provide some features spring boot does not have in
order to add routes at runtime. It takes the opinion that Karaf can be
used as a camel route container rather than only an application
container. I agree an example project would make this more clear.
Spring boot has many examples that demonstrate the value of a single
context so it make sense to add similar examples with this module.
2) Lacks features with the ease of use how to configure camel context itself
I might need some suggestions of what kind of configurations folks might
want here. I've not had to make many customization to the context at
startup. Most of the configurations I've done are in the RouteBuilder
configure methods. For bean injection in my projects I've generally
used services I've registered as OSGi services so I've access them
through the camel-core-osgi's OsgiServiceRegistry (pre 3.x). So open to
hearing suggestions on what folks would like to configure at startup. I
haven't included options since on prior project it hasn't been something
I needed.
3) It should be renamed to |camel-osgi-activator|, and moved to components
In 2.x I would agree that it fits in with components however with the
3.x refactor I'm struggling to find how it fits. Components in 3.x
seems to be all things that extend the DSL and have implemented
component endpoints. This project doesn't do any of those things.
While it's different than camel-main there are similarities that it is
for helping start/manage the CamelContext as well as the RouteBuilder
classes. So i think core is probably the closest fit. It could even be
put in camel-core-osgi with a feature toggle. I'm just not sure if
flipping a config to turn it on is better than having a developer just
install a new Jar. Would be interested in folks perspectives on that if
this is a path we want to take.
Thanks again for the feedback!
- Bob
||
[1] https://github.com/apache/camel/pull/3381
[2] https://github.com/apache/camel/pull/3378
On 2019/11/25 15:18:59, Bob Paulin <b....@bobpaulin.com> wrote:
> Excellent. I've created the following JIRA [1] please let me know if>
> there are any goals or non-goals that should be added. I'll start work>
> on an initial PR for 3.x based on the source I provided as>
> camel-main-osgi within the camel-core folder if there are no>
> objections. Then we can evolve it from there. Looking forward to>
> collaborating on this!>
>
> - Bob>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-14215>
>
>
> On 2019/11/24 05:29:33, Jean-Baptiste Onofré <j....@nanthrax.net> wrote:>
> > Hi Bob,>>
> >>
> > I think it makes sense, and I would be more than happy to>
> help/contribute.>>
> >>
> > +1 for me.>>
> >>
> > Regards>>
> > JB>>
> >>
> > On 23/11/2019 15:02, Bob Paulin wrote:>>
> > > Hi,>>
> > > >>
> > > I've had success using the camel-core-osgi bundle in my OSGi
projects>>
> > > for a while now. It gives me everything I need with the exception>
> of an>>
> > > Activator to start the OsgiDefaultCamelContext in the same way
that is>>
> > > done in Spring Boot. So on a few projects I've been using the same>>
> > > Activator code to start the context and track the RouteBuilders as>
> OSGi>>
> > > services registered from any bundle in the container. Since I keep>>
> > > rewriting it the same way I'm wondering if this might make sense
as a>>
> > > camel-main module for OSGi [1]. Is there any interest in bringing>
> this>>
> > > code into the project as another camel-core module? I haven't tried>
> it>>
> > > on 3.x so it seemed like a good time to revisit the code.>>
> > > >>
> > > >>
> > > - Bob>>
> > > >>
> > > >>
> > > [1] https://github.com/bobpaulin/camel-main-osgi>>
> > > >>
> > > >>
> >>
> > -- >>
> > Jean-Baptiste Onofré>>
> > jbonofre@apache.org>>
> > http://blog.nanthrax.net>>
> > Talend - http://www.talend.com>>
> >>
> >>
>
>
Re: Camel Main for OSGi?
Posted by Bob Paulin <bo...@bobpaulin.com>.
Hi,
> Yes limited at this time, you can add a route builder and do some>
> configuration there from java code.>
> And then you can only configure stuff after camel has been started, as>
> the module currently startup camel first, and discover routes>
> afterwards.>
Sounds good. We can iterate on this as folks find things they want to
tweak at startup. Open for suggestions.
> I dont see it as a core module. As you say its a specialized and>
> opinionated prototype that you built for your use-cases. I dont see>
> this as a core module that are a base for all of osgi.>
> And to second that we have other runtimes in the components folder,>
> like camel-spring-boot, camel-blueprint, and in the 2.x, we have a>
> camel-servlet-listener to bootstrap camel via that, and there are some>
> others like camel-kura for Camel on that OSGi platform and so on.>
After reviewing the camel-blueprint component I see what you are
saying. So given that line of thought the module moves to components
and additionally it would make sense to separate this into it's own
karaf feature rather than placing it in camel-core karaf feature.
Thanks again. Please let me know if anything else comes to mind.
- Bob
On 2019/12/04 18:47:14, Claus Ibsen <c....@gmail.com> wrote:
> On Wed, Dec 4, 2019 at 3:48 PM Bob Paulin <bo...@bobpaulin.com> wrote:>
> >>
> > Hi wanted to bring some discussion back to the list from GitHub
since I think the list is a better place to discuss:>
> >>
> > From Claus Ibsen:>
> >>
> > <snip>>
> >>
> > Thanks for keep working on this.>
> >>
> > Thanks so what I think is really taking people with some surprise is
that it registers Camel routes into the same single camel context from
any bundles. The point of Apache Karaf was to be like an app server
where each bundle is isolated. So this goes against this practice. This
should be documented much much more clearly. And also it lacks features
with the ease of use how to configure camel context itself (you end up
with its defaults) and how would people do dependency injections for
beans etc.>
> >>
> > Also it should be renamed to camel-osgi-activator, and moved to
components (as its not a core piece, eg not used by other osgi like osgi
blueprint which is the main osgi support in Camel).>
> >>
> > </snip>>
> >>
> > Full PR context [1] [2].>
> >>
> > Responses to key points>
> >>
> > 1) Why same single camel context from any bundles?>
> >>
> > There are many ways this could be done in OSGi so the idea behind
this module was to provide an opinionated approach that enables a
developer to get started faster much like the spring boot approach. A
single context trades off some flexibility for simplicity to allow a
developer to get going quickly. This module also takes advantage of
OSGi's dynamic nature to provide some features spring boot does not have
in order to add routes at runtime. It takes the opinion that Karaf can
be used as a camel route container rather than only an application
container. I agree an example project would make this more clear. Spring
boot has many examples that demonstrate the value of a single context so
it make sense to add similar examples with this module.>
> >>
> > 2) Lacks features with the ease of use how to configure camel
context itself>
> >>
> > I might need some suggestions of what kind of configurations folks
might want here. I've not had to make many customization to the context
at startup. Most of the configurations I've done are in the RouteBuilder
configure methods. For bean injection in my projects I've generally used
services I've registered as OSGi services so I've access them through
the camel-core-osgi's OsgiServiceRegistry (pre 3.x). So open to hearing
suggestions on what folks would like to configure at startup. I haven't
included options since on prior project it hasn't been something I needed.>
> >>
>
> Yes limited at this time, you can add a route builder and do some>
> configuration there from java code.>
> And then you can only configure stuff after camel has been started, as>
> the module currently startup camel first, and discover routes>
> afterwards.>
>
> > 3) It should be renamed to camel-osgi-activator, and moved to
components>
> >>
> > In 2.x I would agree that it fits in with components however with
the 3.x refactor I'm struggling to find how it fits. Components in 3.x
seems to be all things that extend the DSL and have implemented
component endpoints. This project doesn't do any of those things. While
it's different than camel-main there are similarities that it is for
helping start/manage the CamelContext as well as the RouteBuilder
classes. So i think core is probably the closest fit. It could even be
put in camel-core-osgi with a feature toggle. I'm just not sure if
flipping a config to turn it on is better than having a developer just
install a new Jar. Would be interested in folks perspectives on that if
this is a path we want to take.>
> >>
>
> I dont see it as a core module. As you say its a specialized and>
> opinionated prototype that you built for your use-cases. I dont see>
> this as a core module that are a base for all of osgi.>
> And to second that we have other runtimes in the components folder,>
> like camel-spring-boot, camel-blueprint, and in the 2.x, we have a>
> camel-servlet-listener to bootstrap camel via that, and there are some>
> others like camel-kura for Camel on that OSGi platform and so on.>
>
>
>
>
> >>
> > Thanks again for the feedback!>
> >>
> > - Bob>
> >>
> >>
> > [1] https://github.com/apache/camel/pull/3381>
> >>
> > [2] https://github.com/apache/camel/pull/3378>
> >>
> >>
> >>
> > On 2019/11/25 15:18:59, Bob Paulin <b....@bobpaulin.com> wrote:>
> > > Excellent. I've created the following JIRA [1] please let me know
if>>
> > > there are any goals or non-goals that should be added. I'll start
work>>
> > > on an initial PR for 3.x based on the source I provided as>>
> > > camel-main-osgi within the camel-core folder if there are no>>
> > > objections. Then we can evolve it from there. Looking forward to>>
> > > collaborating on this!>>
> > >>
> > > - Bob>>
> > >>
> > > [1] https://issues.apache.org/jira/browse/CAMEL-14215>>
> > >>
> > >>
> > > On 2019/11/24 05:29:33, Jean-Baptiste Onofré <j....@nanthrax.net>
wrote:>>
> > > > Hi Bob,>>>
> > > >>>
> > > > I think it makes sense, and I would be more than happy to>>
> > > help/contribute.>>>
> > > >>>
> > > > +1 for me.>>>
> > > >>>
> > > > Regards>>>
> > > > JB>>>
> > > >>>
> > > > On 23/11/2019 15:02, Bob Paulin wrote:>>>
> > > > > Hi,>>>
> > > > > >>>
> > > > > I've had success using the camel-core-osgi bundle in my OSGi
projects>>>
> > > > > for a while now. It gives me everything I need with the
exception>>
> > > of an>>>
> > > > > Activator to start the OsgiDefaultCamelContext in the same way
that is>>>
> > > > > done in Spring Boot. So on a few projects I've been using the
same>>>
> > > > > Activator code to start the context and track the
RouteBuilders as>>
> > > OSGi>>>
> > > > > services registered from any bundle in the container. Since I
keep>>>
> > > > > rewriting it the same way I'm wondering if this might make
sense as a>>>
> > > > > camel-main module for OSGi [1]. Is there any interest in
bringing>>
> > > this>>>
> > > > > code into the project as another camel-core module? I haven't
tried>>
> > > it>>>
> > > > > on 3.x so it seemed like a good time to revisit the code.>>>
> > > > > >>>
> > > > > >>>
> > > > > - Bob>>>
> > > > > >>>
> > > > > >>>
> > > > > [1] https://github.com/bobpaulin/camel-main-osgi>>>
> > > > > >>>
> > > > > >>>
> > > >>>
> > > > -- >>>
> > > > Jean-Baptiste Onofré>>>
> > > > jbonofre@apache.org>>>
> > > > http://blog.nanthrax.net>>>
> > > > Talend - http://www.talend.com>>>
> > > >>>
> > > >>>
> > >>
> > >>
>
>
>
> -- >
> Claus Ibsen>
> ----------------->
> http://davsclaus.com @davsclaus>
> Camel in Action 2: https://www.manning.com/ibsen2>
>
Re: Camel Main for OSGi?
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Dec 4, 2019 at 3:48 PM Bob Paulin <bo...@bobpaulin.com> wrote:
>
> Hi wanted to bring some discussion back to the list from GitHub since I think the list is a better place to discuss:
>
> From Claus Ibsen:
>
> <snip>
>
> Thanks for keep working on this.
>
> Thanks so what I think is really taking people with some surprise is that it registers Camel routes into the same single camel context from any bundles. The point of Apache Karaf was to be like an app server where each bundle is isolated. So this goes against this practice. This should be documented much much more clearly. And also it lacks features with the ease of use how to configure camel context itself (you end up with its defaults) and how would people do dependency injections for beans etc.
>
> Also it should be renamed to camel-osgi-activator, and moved to components (as its not a core piece, eg not used by other osgi like osgi blueprint which is the main osgi support in Camel).
>
> </snip>
>
> Full PR context [1] [2].
>
> Responses to key points
>
> 1) Why same single camel context from any bundles?
>
> There are many ways this could be done in OSGi so the idea behind this module was to provide an opinionated approach that enables a developer to get started faster much like the spring boot approach. A single context trades off some flexibility for simplicity to allow a developer to get going quickly. This module also takes advantage of OSGi's dynamic nature to provide some features spring boot does not have in order to add routes at runtime. It takes the opinion that Karaf can be used as a camel route container rather than only an application container. I agree an example project would make this more clear. Spring boot has many examples that demonstrate the value of a single context so it make sense to add similar examples with this module.
>
> 2) Lacks features with the ease of use how to configure camel context itself
>
> I might need some suggestions of what kind of configurations folks might want here. I've not had to make many customization to the context at startup. Most of the configurations I've done are in the RouteBuilder configure methods. For bean injection in my projects I've generally used services I've registered as OSGi services so I've access them through the camel-core-osgi's OsgiServiceRegistry (pre 3.x). So open to hearing suggestions on what folks would like to configure at startup. I haven't included options since on prior project it hasn't been something I needed.
>
Yes limited at this time, you can add a route builder and do some
configuration there from java code.
And then you can only configure stuff after camel has been started, as
the module currently startup camel first, and discover routes
afterwards.
> 3) It should be renamed to camel-osgi-activator, and moved to components
>
> In 2.x I would agree that it fits in with components however with the 3.x refactor I'm struggling to find how it fits. Components in 3.x seems to be all things that extend the DSL and have implemented component endpoints. This project doesn't do any of those things. While it's different than camel-main there are similarities that it is for helping start/manage the CamelContext as well as the RouteBuilder classes. So i think core is probably the closest fit. It could even be put in camel-core-osgi with a feature toggle. I'm just not sure if flipping a config to turn it on is better than having a developer just install a new Jar. Would be interested in folks perspectives on that if this is a path we want to take.
>
I dont see it as a core module. As you say its a specialized and
opinionated prototype that you built for your use-cases. I dont see
this as a core module that are a base for all of osgi.
And to second that we have other runtimes in the components folder,
like camel-spring-boot, camel-blueprint, and in the 2.x, we have a
camel-servlet-listener to bootstrap camel via that, and there are some
others like camel-kura for Camel on that OSGi platform and so on.
>
> Thanks again for the feedback!
>
> - Bob
>
>
> [1] https://github.com/apache/camel/pull/3381
>
> [2] https://github.com/apache/camel/pull/3378
>
>
>
> On 2019/11/25 15:18:59, Bob Paulin <b....@bobpaulin.com> wrote:
> > Excellent. I've created the following JIRA [1] please let me know if>
> > there are any goals or non-goals that should be added. I'll start work>
> > on an initial PR for 3.x based on the source I provided as>
> > camel-main-osgi within the camel-core folder if there are no>
> > objections. Then we can evolve it from there. Looking forward to>
> > collaborating on this!>
> >
> > - Bob>
> >
> > [1] https://issues.apache.org/jira/browse/CAMEL-14215>
> >
> >
> > On 2019/11/24 05:29:33, Jean-Baptiste Onofré <j....@nanthrax.net> wrote:>
> > > Hi Bob,>>
> > >>
> > > I think it makes sense, and I would be more than happy to>
> > help/contribute.>>
> > >>
> > > +1 for me.>>
> > >>
> > > Regards>>
> > > JB>>
> > >>
> > > On 23/11/2019 15:02, Bob Paulin wrote:>>
> > > > Hi,>>
> > > > >>
> > > > I've had success using the camel-core-osgi bundle in my OSGi projects>>
> > > > for a while now. It gives me everything I need with the exception>
> > of an>>
> > > > Activator to start the OsgiDefaultCamelContext in the same way that is>>
> > > > done in Spring Boot. So on a few projects I've been using the same>>
> > > > Activator code to start the context and track the RouteBuilders as>
> > OSGi>>
> > > > services registered from any bundle in the container. Since I keep>>
> > > > rewriting it the same way I'm wondering if this might make sense as a>>
> > > > camel-main module for OSGi [1]. Is there any interest in bringing>
> > this>>
> > > > code into the project as another camel-core module? I haven't tried>
> > it>>
> > > > on 3.x so it seemed like a good time to revisit the code.>>
> > > > >>
> > > > >>
> > > > - Bob>>
> > > > >>
> > > > >>
> > > > [1] https://github.com/bobpaulin/camel-main-osgi>>
> > > > >>
> > > > >>
> > >>
> > > -- >>
> > > Jean-Baptiste Onofré>>
> > > jbonofre@apache.org>>
> > > http://blog.nanthrax.net>>
> > > Talend - http://www.talend.com>>
> > >>
> > >>
> >
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2