You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Zoran Regvart <zo...@regvart.com> on 2017/05/29 07:29:40 UTC
[HEADS UP] Revision of CamelContext startup/stoppage with Spring is
now in master
Hi Cameleers,
I've merged PR#1685[1] for CAMEL-11261[2] the revision of the way
CamelContext is started/stopped when used with Spring framework.
Based on the amount of intertwined functionality that we have with
Spring this has the potential to break things in unexpected places, so
please get back to me so I can troubleshoot any bugs you find.
I already had an issue reported[3] by the wildfly-camel team that I'm
looking into, please keep those coming as you encounter any.
On a sidenote, I've seen a strange behaviour when Maven uses outdated
version of `camel-test-spring` from the local repository; so, if
possible, before reporting please remove Camel artifacts from the
local repository (mvn -Pcleanrepo) and install the latest SNAPSHOT
(mvn -Pfastinstall clean install). With any luck the CI builds with
the newer version will pass soon so we'll have those SNAPSHOTS in the
Apache repository so this will not be needed.
zoran
[1] https://github.com/apache/camel/pull/1685
[2] https://issues.apache.org/jira/browse/CAMEL-11261
[3] https://github.com/wildfly-extras/wildfly-camel/issues/1889
--
Zoran Regvart
Re: [HEADS UP] Revision of CamelContext startup/stoppage with Spring
is now in master
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah that is fine.
The noStart flag stuff is not intended for end users but a special
flag to Camel itself in the bootstrap of Camel when using Spring and
unit tests etc.
On Tue, Jun 13, 2017 at 10:30 AM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi Cameleers,
> I've discussed the change with WildFly Camel folks and the current
> 2.20.x branch with the changed behaviour is working for them.
>
> Just to reiterate, the SpringCamelContext::setNoStart behaviour
> changed in 2.20, it used to mean "don't start automatically with
> Spring application context", in 2.20 it means just "don't start". So
> in order to start, if previously set:
>
> SpringCamelContext.setNoStart(true)
>
> before SpringCamelContext::start, one must invoke:
>
> SpringCamelContext.setNoStart(false)
>
> I've tried to make the new startup/shutdown behaviour work with
> `noStart` flag as it used to work before 2.20, but it gets complicated
> really quickly.
>
> I think that in the future we should remove the `noStart` flag and
> have a mechanism that is not tied to thread local or global state,
> i.e. per Camel context instance.
>
> While getting there, are there any objections on keeping this new
> state: `noStart` flag means do not start (unconditionally)? I can
> invest more time into getting the new startup/shutdown order working
> with `noStart` behaviour as it used to, and I'm sure I can get it
> done, but I think that the idea of removing thread local flag is
> better in the long run.
>
> So my proposal is to close CAMEL-11261[1] and create new issue for the
> replacement of `noStart` flag with a per context instance mechanism.
>
> zoran
>
> [1] https://issues.apache.org/jira/browse/CAMEL-11261
> --
> Zoran Regvart
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] Revision of CamelContext startup/stoppage with Spring
is now in master
Posted by Zoran Regvart <zo...@regvart.com>.
Hi Cameleers,
I've discussed the change with WildFly Camel folks and the current
2.20.x branch with the changed behaviour is working for them.
Just to reiterate, the SpringCamelContext::setNoStart behaviour
changed in 2.20, it used to mean "don't start automatically with
Spring application context", in 2.20 it means just "don't start". So
in order to start, if previously set:
SpringCamelContext.setNoStart(true)
before SpringCamelContext::start, one must invoke:
SpringCamelContext.setNoStart(false)
I've tried to make the new startup/shutdown behaviour work with
`noStart` flag as it used to work before 2.20, but it gets complicated
really quickly.
I think that in the future we should remove the `noStart` flag and
have a mechanism that is not tied to thread local or global state,
i.e. per Camel context instance.
While getting there, are there any objections on keeping this new
state: `noStart` flag means do not start (unconditionally)? I can
invest more time into getting the new startup/shutdown order working
with `noStart` behaviour as it used to, and I'm sure I can get it
done, but I think that the idea of removing thread local flag is
better in the long run.
So my proposal is to close CAMEL-11261[1] and create new issue for the
replacement of `noStart` flag with a per context instance mechanism.
zoran
[1] https://issues.apache.org/jira/browse/CAMEL-11261
--
Zoran Regvart
Re: [HEADS UP] Revision of CamelContext startup/stoppage with Spring
is now in master
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, May 30, 2017 at 11:19 AM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi,
> yes, the issue is with the `noStart` flag in `SpringCamelContext` the
> contract of which I changed with CAMEL-11261, it used to mean: do not
> start automatically, but only on `CamelContext::start()` with my
> change it means do not start unless set to `false`. I've created a PR
> against wildfly-camel[1] that should help.
>
> But I think it would be better to remove `noStart` flag from
> SpringCamelContext, we could do a SpringCamelContextCustomizer or such
> interface that will be applied before SpringCamelContext is started
> (for instance on afterPropertiesSet) and wildfly-camel and tests can
> use this to set `autoStartup` flag to `false`.
>
> If we're going to keep the `noStart` flag, then I think I need to
> rework it to work like it did before CAMEL-11261, I don't know if
> there are any other projects that might be affected by this change in
> behaviour.
>
I would not think there are many other projects as wildfly-camel is an
extension to bring Camel to run on WildFly via the JBoss Module
System. Most Camel users are end users and Camel runs well on other
platforms and containers out of the box.
> zoran
>
> [1] https://github.com/wildfly-extras/wildfly-camel/pull/1890
>
> On Tue, May 30, 2017 at 11:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Did you guys find out the problem with wildfly-camel ?
>>
>> And wonder if people from the community could give this a test on
>> their camel spring apps? For example I think there was an user
>> reported about this shutdown problem a while back, that lead to this
>> solution. Maybe that person can give this a test?
>>
>> On Mon, May 29, 2017 at 9:29 AM, Zoran Regvart <zo...@regvart.com> wrote:
>>> Hi Cameleers,
>>> I've merged PR#1685[1] for CAMEL-11261[2] the revision of the way
>>> CamelContext is started/stopped when used with Spring framework.
>>>
>>> Based on the amount of intertwined functionality that we have with
>>> Spring this has the potential to break things in unexpected places, so
>>> please get back to me so I can troubleshoot any bugs you find.
>>>
>>> I already had an issue reported[3] by the wildfly-camel team that I'm
>>> looking into, please keep those coming as you encounter any.
>>>
>>> On a sidenote, I've seen a strange behaviour when Maven uses outdated
>>> version of `camel-test-spring` from the local repository; so, if
>>> possible, before reporting please remove Camel artifacts from the
>>> local repository (mvn -Pcleanrepo) and install the latest SNAPSHOT
>>> (mvn -Pfastinstall clean install). With any luck the CI builds with
>>> the newer version will pass soon so we'll have those SNAPSHOTS in the
>>> Apache repository so this will not be needed.
>>>
>>> zoran
>>>
>>> [1] https://github.com/apache/camel/pull/1685
>>> [2] https://issues.apache.org/jira/browse/CAMEL-11261
>>> [3] https://github.com/wildfly-extras/wildfly-camel/issues/1889
>>> --
>>> Zoran Regvart
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Zoran Regvart
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] Revision of CamelContext startup/stoppage with Spring
is now in master
Posted by Zoran Regvart <zo...@regvart.com>.
Hi,
yes, the issue is with the `noStart` flag in `SpringCamelContext` the
contract of which I changed with CAMEL-11261, it used to mean: do not
start automatically, but only on `CamelContext::start()` with my
change it means do not start unless set to `false`. I've created a PR
against wildfly-camel[1] that should help.
But I think it would be better to remove `noStart` flag from
SpringCamelContext, we could do a SpringCamelContextCustomizer or such
interface that will be applied before SpringCamelContext is started
(for instance on afterPropertiesSet) and wildfly-camel and tests can
use this to set `autoStartup` flag to `false`.
If we're going to keep the `noStart` flag, then I think I need to
rework it to work like it did before CAMEL-11261, I don't know if
there are any other projects that might be affected by this change in
behaviour.
zoran
[1] https://github.com/wildfly-extras/wildfly-camel/pull/1890
On Tue, May 30, 2017 at 11:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Did you guys find out the problem with wildfly-camel ?
>
> And wonder if people from the community could give this a test on
> their camel spring apps? For example I think there was an user
> reported about this shutdown problem a while back, that lead to this
> solution. Maybe that person can give this a test?
>
> On Mon, May 29, 2017 at 9:29 AM, Zoran Regvart <zo...@regvart.com> wrote:
>> Hi Cameleers,
>> I've merged PR#1685[1] for CAMEL-11261[2] the revision of the way
>> CamelContext is started/stopped when used with Spring framework.
>>
>> Based on the amount of intertwined functionality that we have with
>> Spring this has the potential to break things in unexpected places, so
>> please get back to me so I can troubleshoot any bugs you find.
>>
>> I already had an issue reported[3] by the wildfly-camel team that I'm
>> looking into, please keep those coming as you encounter any.
>>
>> On a sidenote, I've seen a strange behaviour when Maven uses outdated
>> version of `camel-test-spring` from the local repository; so, if
>> possible, before reporting please remove Camel artifacts from the
>> local repository (mvn -Pcleanrepo) and install the latest SNAPSHOT
>> (mvn -Pfastinstall clean install). With any luck the CI builds with
>> the newer version will pass soon so we'll have those SNAPSHOTS in the
>> Apache repository so this will not be needed.
>>
>> zoran
>>
>> [1] https://github.com/apache/camel/pull/1685
>> [2] https://issues.apache.org/jira/browse/CAMEL-11261
>> [3] https://github.com/wildfly-extras/wildfly-camel/issues/1889
>> --
>> Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Zoran Regvart
Re: [HEADS UP] Revision of CamelContext startup/stoppage with Spring
is now in master
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Did you guys find out the problem with wildfly-camel ?
And wonder if people from the community could give this a test on
their camel spring apps? For example I think there was an user
reported about this shutdown problem a while back, that lead to this
solution. Maybe that person can give this a test?
On Mon, May 29, 2017 at 9:29 AM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi Cameleers,
> I've merged PR#1685[1] for CAMEL-11261[2] the revision of the way
> CamelContext is started/stopped when used with Spring framework.
>
> Based on the amount of intertwined functionality that we have with
> Spring this has the potential to break things in unexpected places, so
> please get back to me so I can troubleshoot any bugs you find.
>
> I already had an issue reported[3] by the wildfly-camel team that I'm
> looking into, please keep those coming as you encounter any.
>
> On a sidenote, I've seen a strange behaviour when Maven uses outdated
> version of `camel-test-spring` from the local repository; so, if
> possible, before reporting please remove Camel artifacts from the
> local repository (mvn -Pcleanrepo) and install the latest SNAPSHOT
> (mvn -Pfastinstall clean install). With any luck the CI builds with
> the newer version will pass soon so we'll have those SNAPSHOTS in the
> Apache repository so this will not be needed.
>
> zoran
>
> [1] https://github.com/apache/camel/pull/1685
> [2] https://issues.apache.org/jira/browse/CAMEL-11261
> [3] https://github.com/wildfly-extras/wildfly-camel/issues/1889
> --
> Zoran Regvart
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2