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
GitHub user chirino opened a pull request:
https://github.com/apache/camel/pull/1470
As slightly more typesafe impl of the connector mojo which leverages â¦
â¦jackson object binding to do most of the json parsing and formatting.
You can merge this pull request into a Git
Github user chirino closed the pull request at:
https://github.com/apache/camel/pull/1150
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
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
GitHub user chirino opened a pull request:
https://github.com/apache/camel/pull/1150
Fix for CAMEL-10279 - Can't use @ImportResource and configure() in thâ¦
â¦e same SB app.
This assumes there is always a RouteBuilder in a SB app.
You can merge this pull request i
GitHub user chirino opened a pull request:
https://github.com/apache/camel/pull/1114
Fix for CAMEL-10226: Allow JmsComponent subclasses to disable auto-wiâ¦
â¦ring connection factories/destination resolvers.
You can merge this pull request into a Git repository by running
GitHub user chirino opened a pull request:
https://github.com/apache/camel/pull/787
Fixing up some Admonition blocks.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/chirino/camel patch-1
Alternatively you can review and apply
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
Github user chirino closed the pull request at:
https://github.com/apache/camel/pull/430
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user chirino opened a pull request:
https://github.com/apache/camel/pull/430
Fix for CAMEL-8452: Camel route model - Preserve {{ }} placeholders
We preserve just the uri property of ProcessorDefinitions before we create
the associated Processor and restore the original
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
25 matches
Mail list logo
