Hi
Yeah over the years many of the Camel components has become more
lenient/flexible in terms of starting order, so you can start seda
routes in any order.
The direct component now has an option to not fail if no active
consumers. And its likely a matter of just adding some logic to it
that it de
On Mon, Jul 13, 2015 at 3:24 PM, Jakub Korab
wrote:
> Yeah, that makes a lot of sense. I spent some time drilling through that
> component's logic and while it would be hard to marry up the two processing
> models and their use of Synchronizations, it definitely feels like something
> that belongs
Working out route order startup automatically is more problematic than
it would appear. Consider the following:
.recipientList(bean(myRoutingBean, "whereTo"))
This is just one EIP where the route is worked out on a per-exchange
basis. The framework itself has no insight into the possible value
On Mon, Jul 13, 2015 at 3:59 PM, Daniel Kulp wrote:
>
> This makes sense to me.
>
> That said, moving to Karaf 3.0 doesn’t get rid of jetty8. Need 4.0 for that.
> :-)
>
Ah darn - one battle at a time ;)
> Dan
>
>
>> On Jul 13, 2015, at 6:35 AM, Claus Ibsen wrote:
>>
>> Hi
>>
>> I wonder if
On Mon, Jul 13, 2015 at 3:57 PM, Daniel Kulp wrote:
> I’m actually ok with the version range update. That said, we should
> probably then also go through the code and remove the reflection code and
> extra methods that are in there to support the two versions. Would clean it
> up a bit.
>
>
This makes sense to me.
That said, moving to Karaf 3.0 doesn’t get rid of jetty8. Need 4.0 for that.
:-)
Dan
> On Jul 13, 2015, at 6:35 AM, Claus Ibsen wrote:
>
> Hi
>
> I wonder if its time we move on master branch of Camel to require a
> newer version of Apache Karaf?
>
> Maybe C
I’m actually ok with the version range update. That said, we should probably
then also go through the code and remove the reflection code and extra methods
that are in there to support the two versions. Would clean it up a bit.
Dan
> On Jul 13, 2015, at 6:19 AM, Aki Yoshida wrote:
>
> Hi
Yeah, that makes a lot of sense. I spent some time drilling through that
component's logic and while it would be hard to marry up the two
processing models and their use of Synchronizations, it definitely feels
like something that belongs in the same JAR.
What's the best way to submit this? Sh
Thanks Claus. I'll make those changes and ping back when done.
Jakub
On 13/07/15 13:10, Claus Ibsen wrote:
Hi Jakub
Looks good a few comments
The component should extend UriEndpointComponent
And the endpoint should have @UriEndpoint and other
annotations for the options. You can take look how
OK. Fine.
Thanks.
2015-07-13 12:32 GMT+02:00 Claus Ibsen :
> Hi
>
> We cannot support old stuff forever. camel-cxf is using and tested
> with CXF 3.0+ for a rather long time.
> Camel 2.13 was the last release with CXF 2.7. (released in March 2014)
>
> Camel 2.14 and 2.15 was using CXF 3.0.x. And
Hi
And I think a good home for this is camel-sjms as its only using
standard JMS api. And we can have 2 or more components in the same JAR
- we have that in others.
And it may be able to reuse some logic to populate from JMS to Camel
Message to set headers and what different JMX message types the
Hi Jakub
Looks good a few comments
The component should extend UriEndpointComponent
And the endpoint should have @UriEndpoint and other
annotations for the options. You can take look how its done elsewhere.
We use ObjectHelper.notNull for validate if a parameter is configured
or not, you can use
Hi
I wonder if its time we move on master branch of Camel to require a
newer version of Apache Karaf?
Maybe Camel 2.16 should be the last release where we test and support
with Karaf 2.4.
And then move on for next release to be Karaf 3.0+.
This helps us move away from the old EOL version of Jett
Hi
We cannot support old stuff forever. camel-cxf is using and tested
with CXF 3.0+ for a rather long time.
Camel 2.13 was the last release with CXF 2.7. (released in March 2014)
Camel 2.14 and 2.15 was using CXF 3.0.x. And now Camel 2.16 is using CXF 3.1.x.
We do not want to tie to old version
Hi Claus,
could you look at my comment on this ticket regarding the cxf's
osgi-version range?
I think we should keep the range as before, that is to have [2.7,4.0).
So I am interested in hearing the argument for updating the range.
thanks.
regards, aki
2015-07-09 15:35 GMT+02:00 Aki Yoshida :
> I
15 matches
Mail list logo
