nly 15mb
> > of memory [7].
> >
> > Thoughts ?
> >
> > Luca
> >
> > [1] https://quarkus.io/
> > [2] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> > [3]
> https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-
>> >
> > >> > It is currently possible to use the sql-camel/jdbc-camel component
> to
> > >> > connect to a running Teiid instance, but we are looking for a
> tighter
> > >> > integration by providing a way to embed the Teiid engine in a Camel
> > >> > comp
sources
> > only when actually running.
> >
> > Being the final integrations lightweight and being the DSL
> > language-independent, we may see a increased adoption of Camel also as
> > agile integration layer for not-only-java applications (both "cloud" and
> > "serverless" applications).
> >
> > I'm the first one that would like to work on a project ilke this. I've
> > worked on many Kubernetes/Openshift based applications and frameworks in
> > the past years, also on operators and CRDs, and I think this way of
> > redesigning integrations has a lot of potential.
> >
> > Integrations will not be necessarily limited to the simplified DSL, but
> we
> > can add extension points for scripting and even custom libraries
> (although
> > limiting the freedom of the optimizer).
> >
> > The most important thing: it may become a great project, since it's
> driven
> > by a great community.
> >
> > So, what do you think? Is it crazy enough?
> >
> > Nicola
>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
amel
> 2.18) to use 3gb and these CI jobs now are able to run.
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
scerd
>
>
>
>
> On Thursday, January 21, 2016 4:29 PM, Hiram Chirino
> wrote:
> Hi folks,
>
> The artemis project has been using a gitbook based tool chain to
> generate their docs from project source that seems kinda cool. I know
> a while back we discussed movin
goal, I'm going to replicate that gitbook toolchain setup
in the camel project
Next step after that would be figuring out a good conversion/migration
plan for the actual content.
Expect that to show up soon.
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesourc
gt; > > > is also written in Scala.
> > >
> > >
> > > Agree. That's the reason why we have a Scala component, a Scala DSL,
> ...
> > > But providing an integration with Stomp is not a Scala subject IMO.
> > > And there is no reason why this component can not be developed in Java.
> > >
> > > >
> > > > Maybe we could settle some "official policy" regarding Scala-related
> > > > code for Camel?
> > >
> > >
> > > I don't see the need right now. There are many other scripting
> languages
> > > running in a JVM (http://en.wikipedia.org/wiki/List_of_JVM_languages).
> > > Should we also accept new components written in these languages? I
> don't
> > > think so...
> > >
> > > >
> > > > --
> > > > Henryk Konsek
> > > > http://henryk-konsek.blogspot.com
> > >
> > >
> > >
> > >
> > >
> > > --
>
>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchir...@redhat.com | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
String decodedUriFromDsl = ...
>> String encodedUri = UriUtils.encodeUri(**decodedUriFromDsl, "UTF-8");
>> assertValidUri(encodedUri);
>>
>> This will guarantee that Camel uses valid URIs but won't break
>> contract of many existing components.
>>
>>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chir...@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
://www.ietf.org/rfc/rfc2396.txt>
> [2] http://mail-archives.apache.**org/mod_mbox/camel-dev/201206.**
> mbox/%3C4FD60168.5090009%**40gmail.com%3E<http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E>
>
--
**
*Hiram Chirino*
*S
The fact that it's not 100% compatible IS why it's not a good idea to
call it 2.x. The point of version numbering schemes are to reflect
the compatibility between releases. If trunk is not a major release,
I don't know what is. And yes I would hope that the 3.x line tries to
keep as much backwar
I just did a similar thing for ActiveMQ, If there were actually a
couple of variations need to hand the other svn keyword tags. Gotta
dig for them in my bash history. If you don't get to it before I do,
I'll apply them to the source tree.
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
[
https://issues.apache.org/activemq/browse/CAMEL-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62734#action_62734
]
Hiram Chirino commented on CAMEL-3249:
--
Thanks for the test case. I foun
Hiram Chirino
Assignee: Hiram Chirino
Fix For: 2.5.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[
https://issues.apache.org/activemq/browse/CAMEL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino resolved CAMEL-2964.
--
Resolution: Fixed
fixed in trunk rev 965601
> Upgrade to HawtDB
Thanks for the heads up.. I just upgraded camel to hawtdb 1.1
https://issues.apache.org/activemq/browse/CAMEL-2901
On Wed, Jun 30, 2010 at 11:11 AM, Hadrian Zbarcea wrote:
> We have already well over 100 issues fixed on trunk. The most notable
> change in 2.4 [1] is the long awaited fully non blo
[
https://issues.apache.org/activemq/browse/CAMEL-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino resolved CAMEL-2901.
--
Resolution: Fixed
upgraded trunk.
> Upgrade to HawtDB
: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 2.4.0
HawtDB 1.1 has been released. Change log at:
http://github.com/chirino/hawtdb/blob/master/changelog.md
We should upgrade to pick up the listed bug fixes:
{quote}
* Fixing BTree node next linking.. It was possible
Awesome work. This should really provide a huge scalability boost for some
folks!
On Thu, Jul 1, 2010 at 7:58 AM, Claus Ibsen wrote:
> Hi
>
> The major goal for Camel 2.4 is introducing back the asynchronous
> routing engine from the Camel 1.x days.
> What we had replaced it with, just didn't c
18 matches
Mail list logo
