The Apache Jenkins build system has built Camel.trunk.notest (build #2105)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.trunk.notest/2105/
to view the results.
The Apache Jenkins build system has built Camel.2.13.x.notest (build #28)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.2.13.x.notest/28/
to view the results.
The Apache Jenkins build system has built Camel.trunk.notest.jdk7 (build #50)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Camel.trunk.notest.jdk7/50/ to view the results.
The Apache Jenkins build system has built Camel.2.12.x.notest (build #115)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.2.12.x.notest/115/
to view the results.
I'd be willing to contribute toward a JCache-based component. It might be
worth considering another related component for generic data grid style
components.
On 9 July 2014 10:34, ugol wrote:
> We have two options:
>
> 1. code directly against JCache (JSR 107)
> pro: out of the box integration
We have two options:
1. code directly against JCache (JSR 107)
pro: out of the box integration with JSR 107 compliant cache providers
cons: doesn't work with every provider. JCache API don't cover lot of
use cases (it's temporary in nature for example, while Infinispan is
more on the "grid" side)
Technically components like camel-jms/camel-sjms, camel-jdbc/camel-sql,
camel-jpa, camel-jcr, etc., all code to JSRs instead of particular
implementations. I don't think I've seen an equivalent for camel-camel ;)
Using the JSRs for a generic cache component would be nice because EHCache
and Infini
Do we have any example of a generic camel component with different
implementations?
Or should be camel-cache just a set of common API?
On Wed, Jul 9, 2014 at 4:08 PM, ugol wrote:
>> I like the idea of having some common api for caching in Camel. And
>> making sure that this is the easiest and a g
Hi,
thanks for answer. Please, can you provide link to this JIRA task for
feedback?
On the other hand, what is the scenario when user want to have two same
conversation method? Maybe when we have isolated modules? Nothing else I can
think...
Sometimes unexpected behavior of converter is if input
> I like the idea of having some common api for caching in Camel. And
> making sure that this is the easiest and a good way to use caching.
>
> Altough there is also the jcache spec that Matt talks about. Not sure
> where that spec fits into this picture?
In my idea, it's just that JSR107 and JSR
Hi
Good question. I think we have a JIRA ticket about adding a choice, so
users can control if they want Camel to
- fail for duplicates
- keep the oldest
- keep the newest (i think this is the model today)
- something else ???
As we got so many components now, its maybe time to get worked on this
Hi,
situation: Camel Context contains many and many routes and therefore many
types of converters. But if we have two different converters (different
package, name and so on), but with same signature of method and with same
return types, unexpected behavior of Camel and TypeConverterRegistry is th
Hi guys
I had the pleasure of meeting Piotr today in London at a fuse community event.
I like the idea of having some common api for caching in Camel. And
making sure that this is the easiest and a good way to use caching.
Altough there is also the jcache spec that Matt talks about. Not sure
whe
13 matches
Mail list logo
