The Apache Jenkins build system has built Camel.trunk.notest (build #1805)
Status: Failure
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1805/
to view the results.
On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan wrote:
> +1 on core transaction support
>
> Since development on SJMS started I have been reviewing JTA and how to
> implement it as a core support API in Camel. Adding the capability for a
> single endpoint or even multiple endpoints in a
> I'm wondering if it makes sense to put Scala stuff at Apache, but into a
> Camel sub-project type of thing.
> camel/scala-components/trunk type thing. It could have it's own releases
Sounds perfect for me. As long as Scala goodies have their own place,
I'm be more than happy :) .
Best regards
> Christian:
> Be careful. What do you mean with "the official home for the Camel
> components written in Scala"?
> This is not an ASF project! There are may Apache (Camel) committers who
> also will work in this project.
Camel Scala would be "official" the same way as Camel Extra is.
Formally it
+1 on core transaction support
Since development on SJMS started I have been reviewing JTA and how to
implement it as a core support API in Camel. Adding the capability for a
single endpoint or even multiple endpoints in a route is somewhat strait
forward. Extending the boundary of a transaction
On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet wrote:
> if you configure spring to use the JtaTransactionManager which inherits
> from PlatformTransactionManager, then you'll have the spring transaction
> layer using JTA.
>
> I'll give this a try.
>
>
> On Thu, Feb 28, 2013 at 1:22 AM, Chris
On Wed, Feb 27, 2013 at 10:20 PM, Claus Ibsen wrote:
> On Thu, Feb 28, 2013 at 1:22 AM, Chris Geer wrote:
> > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet
> wrote:
> >
> >> Getting rid of spring transaction support and implementing our own
> layer in
> >> camel would be a big win, as it's r
