Camel mime-multipart marshal data formatter is not writing the complete body part

2018-06-19 Thread Gopalkrishna Kulkarni
Hi We are using blueprint XML for camel route and using
mime-multipart:marshal data formatter.
On very rare cases, this data formatted is failing to write the comple
body. It simply adds few Mime headers and sends the message to next step of
the route. I have documented the issue in Stack over flow. Kindly help
https://stackoverflow.com/questions/50941153/camel-mime-multipart-marshal-data-formatter-is-not-writing-the-complete-body-par


Regards,
Gopal


Re: Upgrade to Mina 2.0.19 broke camel-xmpp tests

2018-06-19 Thread Pascal Schumacher

Should have been "properly fix this".

Sorry,
Pascal

Am 19.06.2018 um 19:27 schrieb Pascal Schumacher:

Hi everybody,

after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken:

https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ 



I can replicated this locally. Reverting commit 
2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version 
2.0.19" makes the tests pass again.


No idea how to probably fix this, but I think we should fix this 
before releasing camel 2.22.


Cheers,

Pascal








Upgrade to Mina 2.0.19 broke camel-xmpp tests

2018-06-19 Thread Pascal Schumacher

Hi everybody,

after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken:

https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/

I can replicated this locally. Reverting commit 
2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version 
2.0.19" makes the tests pass again.


No idea how to probably fix this, but I think we should fix this before 
releasing camel 2.22.


Cheers,

Pascal






Re: Getting ready for Camel 2.22 Release with SB2 support

2018-06-19 Thread Onder SEZGIN
Hi,

I am done with CAMEL-6840. This will possibly resolve CAMEL-5599.
I think lately Willem has had one comment. I think it is addressed already.
If you have more, please let me know and we can have it merged soon.

Thanks,
Önder

On Mon, Jun 18, 2018 at 11:02 AM Onder SEZGIN  wrote:

> Hi,
>
> I would like to include CAMEL-6840 after addressing review comments.
> Possibly today or so..
> i think i will catch up.
>
> On Mon, Jun 18, 2018 at 9:45 AM Claus Ibsen  wrote:
>
>> Hi
>>
>> Okay so I have a PR for CAMEL-9751. Feel free to review/comment.
>>
>> For the other stuff that we need to get into Camel 2.22.0 then please
>> speak up.
>> We should go over the outstanding JIRA tickets and get them moved to
>> 2.22.1 or 2.23.0 release, so we can close down.
>>
>> The CI builds are passing and they are blue (that is good)
>> https://builds.apache.org/job/Camel/job/master/
>>
>>
>>
>> On Mon, Jun 11, 2018 at 9:35 AM, Claus Ibsen 
>> wrote:
>> > Hi
>> >
>> > So just a reminder that we should close down on the Camel 2.22.0
>> release.
>> > Spring Boot 2.0.3 is going to be released this week.
>> >
>> > There are still a fair high number of tickets assigned to 2.22.0
>> > release. So we should try to move
>> > tickets to 2.23 and also get tickets fixed if possible.
>> >
>> > I am traveling this and the following week, so I have less time to
>> > work on Camel. There is however one ticket I would like to get
>> > implemented and started working on:
>> > https://issues.apache.org/jira/browse/CAMEL-9751
>> >
>> >
>> >
>> > On Tue, May 29, 2018 at 9:10 AM, Onder SEZGIN 
>> wrote:
>> >> I think SB 2.0.3 will be released around 13th of June.
>> >>
>> >> 2.0.3 
>> >>  Due by June 13, 2018  Last updated 5 minutes ago
>> >>
>> >> 87% complete
>> >>
>> >> 4 open
>> >> <
>> https://github.com/spring-projects/spring-boot/issues?q=is%3Aopen+milestone%3A2.0.3
>> >
>> >>
>> >> 28 closed
>> >> <
>> https://github.com/spring-projects/spring-boot/issues?q=is%3Aclosed+milestone%3A2.0.3
>> >
>> >>
>> >>
>> >> On Tue, May 29, 2018 at 9:56 AM, Claus Ibsen 
>> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> The next month June is approaching.
>> >>>
>> >>> We should close down on getting the master branch ready for the Camel
>> >>> 2.22.0 release.
>> >>> I have just moved some tickets to the next 2.23.0 release.
>> >>>
>> >>> There is still about 50 jira tickets outstanding, so you are welcome
>> >>> to take a look as well and move tickets to 2.20.1 or 2.23.0 versions.
>> >>> And of course get the tickets fixed/implemented etc.
>> >>>
>> >>> There is a thing about upgrading camel-solr and camel-lucene to newer
>> >>> versions. But I think I saw something about we may need Spring Boot
>> >>> 2.0.3 to be released first.
>> >>> Anyone know more about this?
>> >>>
>> >>> The CI build server on master seems stable. All blue or yellow (no
>> red)
>> >>> https://builds.apache.org/job/Camel/job/master/
>> >>>
>> >>> Andreas, there may be some OSGi bundles for the Spring 5, Spring Boot
>> >>> 2 upgrade which is needed to be releases from the SMX team.
>> >>> It would be good to get that done, so we are ready from Karaf/OSGi
>> >>> side of things for the 2.22.0 release.
>> >>>
>> >>> There is ticket https://issues.apache.org/jira/browse/CAMEL-12375
>> >>> Maybe you can take this ticket?
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, May 24, 2018 at 7:41 AM, Andrea Cosentino
>> >>>  wrote:
>> >>> > Yes, it is, but some bundles are available already
>> >>> >
>> >>> > --
>> >>> > Andrea Cosentino
>> >>> > --
>> >>> > Apache Camel PMC Member
>> >>> > Apache Karaf Committer
>> >>> > Apache Servicemix PMC Member
>> >>> > Email: ancosen1...@yahoo.com
>> >>> > Twitter: @oscerd2
>> >>> > Github: oscerd
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Thursday, May 24, 2018, 7:35:01 AM GMT+2, Claus Ibsen <
>> >>> claus.ib...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Wed, May 23, 2018 at 10:17 AM, Andrea Cosentino
>> >>> >  wrote:
>> >>> >> We need to take care of Karaf features too. Actually we have some
>> >>> misalignments between bundles and JARs
>> >>> >>
>> >>> >
>> >>> > Is the SMX team working on this, such as a new set of bundles to be
>> >>> released.
>> >>> >
>> >>> >
>> >>> >> --
>> >>> >> Andrea Cosentino
>> >>> >> --
>> >>> >> Apache Camel PMC Member
>> >>> >> Apache Karaf Committer
>> >>> >> Apache Servicemix PMC Member
>> >>> >> Email: ancosen1...@yahoo.com
>> >>> >> Twitter: @oscerd2
>> >>> >> Github: oscerd
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Wednesday, May 23, 2018, 9:08:38 AM GMT+2, Claus Ibsen <
>> >>> claus.ib...@gmail.com> wrote:
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> Hi
>> >>> >>
>> >>> >> I want to let us get started early on preparing for the upcoming
>> and
>> >>> >> anticipated release of Apache Camel 

[GitHub] camel pull request #2386: CAMEL-12588 Fix Improvement

2018-06-19 Thread oscerd
Github user oscerd closed the pull request at:

https://github.com/apache/camel/pull/2386


---


[GitHub] camel pull request #2386: CAMEL-12588 Fix Improvement

2018-06-19 Thread gsudharsan
GitHub user gsudharsan opened a pull request:

https://github.com/apache/camel/pull/2386

CAMEL-12588 Fix Improvement

AggregateProcessor doStop() method changed to call shutdown() instead of
shutdownNow()

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gsudharsan/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2386.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2386


commit 669f5be52e7ed1773fc8aa8cc0b95b1ed676fefa
Author: Sudharsan Govindarajan 
Date:   2018-06-19T14:06:27Z

CAMEL-12588 Fix Improvement

AggregateProcessor doStop() method changed to call shutdown() instead of
shutdownNow()




---


[GitHub] camel pull request #2385: CAMEL-12588 - Improving the fix

2018-06-19 Thread gsudharsan
Github user gsudharsan closed the pull request at:

https://github.com/apache/camel/pull/2385


---


[GitHub] camel pull request #2385: CAMEL-12588 - Improving the fix

2018-06-19 Thread gsudharsan
GitHub user gsudharsan opened a pull request:

https://github.com/apache/camel/pull/2385

 CAMEL-12588 - Improving the fix 

doStop() method now shuts down the timeoutCheckerExecutorService pool too
Improvment - used shutdown instead of shutdownNow

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gsudharsan/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2385.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2385


commit b26f9fca9e48a1afdbbfc6ad576455e2e3c6c0c3
Author: Sudharsan Govindarajan 
Date:   2018-06-19T11:37:52Z

Cleanup TimeOutChecker threads

When a Aggregator route is stopped, only the AggregateRecoveryChecker 
threads are stopped and not the AggregateTimeoutChecker threads. They keep 
lingering around .

commit 8c1b0ddfc0c913f109de746d007ff89e2ae1d2b3
Author: Sudharsan Govindarajan 
Date:   2018-06-19T12:46:47Z

CAMEL-12588 - Improving the fix 

corrected to shutdown instead of shutdownNow




---


[GitHub] camel pull request #2384: Cleanup TimeOutChecker threads

2018-06-19 Thread oscerd
Github user oscerd closed the pull request at:

https://github.com/apache/camel/pull/2384


---


[GitHub] camel pull request #2384: Cleanup TimeOutChecker threads

2018-06-19 Thread gsudharsan
GitHub user gsudharsan opened a pull request:

https://github.com/apache/camel/pull/2384

Cleanup TimeOutChecker threads

When a Aggregator route is stopped, only the AggregateRecoveryChecker 
threads are stopped and not the AggregateTimeoutChecker threads. They keep 
lingering around. - CAMEL-12588

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gsudharsan/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2384.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2384


commit b26f9fca9e48a1afdbbfc6ad576455e2e3c6c0c3
Author: Sudharsan Govindarajan 
Date:   2018-06-19T11:37:52Z

Cleanup TimeOutChecker threads

When a Aggregator route is stopped, only the AggregateRecoveryChecker 
threads are stopped and not the AggregateTimeoutChecker threads. They keep 
lingering around .




---


R: Re: Teiid Camel component

2018-06-19 Thread Andrea Cosentino
Not necessary. We can eventually wrap non OSGi-fied dependencies.

Inviato da Yahoo Mail su Android 
 
  Il mar, 19 giu, 2018 alle 12:42, Rafal Korytkowski 
ha scritto:   Hi Claus,

Thanks a lot for your guidance!

I've got one follow up question. Is it a strict requirement for component's
dependencies to be OSGI-fied?

On Mon, Jun 18, 2018 at 9:01 AM Claus Ibsen  wrote:

> Hi Rafal
>
> Welcome to the Camel community.
> It sounds great with a camel-teiid component.
>
> Writing a Camel component is very open ended and you have a lot of freedom.
>
> In terms of how to embed Teiid engine then Camel has no restrictions.
> If there is one instance in the JVM, then we can let Camel
> auto-discover
> and use the instance in the camel-teiid component, so the end user do
> not have to explicit configure this wiring.
>
> Camel has its Registry abstraction over for example Spring Boot /
> ApplicationContext (bean registry) or CDI's BeanManager, or OSGi
> Service Registry etc.
> So what other components is doing is to lookup in this registry if
> there is a single instance of a specific class type, and then use
> that.
>
> There is a little guide here how to add a new Camel component
> http://camel.apache.org/add-new-component-guide.html
>
> We do have a maven archetype to create a new camel component project,
> or what other people sometimes do is to copy an existing component and
> then delete/modify its source code.
> http://camel.apache.org/camel-maven-archetypes.html
>
>
>
>
>
> On Fri, Jun 15, 2018 at 12:48 PM, Rafal Korytkowski
>  wrote:
> > Hi,
> >
> > We're considering implementing a Camel component for Teiid (
> http://teiid.io/)
> > and looking for your insights on some design aspects and general
> thoughts.
> >
> > Teiid is a data virtualization engine that comes as in-place real-time
> > integration of heterogeneous data sources (~50). Teiid exposes them
> through
> > a SQL engine and ODATA REST endpoints. It is typically run as a server
> > being accessed by SQL clients.
> >
> > Data sources supported by Teiid are pretty much a subset of what Camel
> > already supports, but the benefit we see is that it provides the SQL
> engine
> > to access them all in a unified way, which makes integrations more
> > straightforward than using custom APIs.
> >
> > 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
> > component. It would simplify its usage.
> >
> > Would you have any recommendations for writing such a component?
> >
> > One aspect we need to consider is, if it would be possible to reuse
> somehow
> > an instance of Teiid within a route or across routes or share some of
> > Teiid's metadata so that we do not have to bring up an instance each
> time.
> >
> > Finally, we have just started a similar conversion on the Teiid forum so,
> > if you are interested please also see
> > https://developer.jboss.org/thread/278138
> > --
> >
> > -Rafał
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
-- 

-Rafał  


Re: Teiid Camel component

2018-06-19 Thread Rafal Korytkowski
Hi Claus,

Thanks a lot for your guidance!

I've got one follow up question. Is it a strict requirement for component's
dependencies to be OSGI-fied?

On Mon, Jun 18, 2018 at 9:01 AM Claus Ibsen  wrote:

> Hi Rafal
>
> Welcome to the Camel community.
> It sounds great with a camel-teiid component.
>
> Writing a Camel component is very open ended and you have a lot of freedom.
>
> In terms of how to embed Teiid engine then Camel has no restrictions.
> If there is one instance in the JVM, then we can let Camel
> auto-discover
> and use the instance in the camel-teiid component, so the end user do
> not have to explicit configure this wiring.
>
> Camel has its Registry abstraction over for example Spring Boot /
> ApplicationContext (bean registry) or CDI's BeanManager, or OSGi
> Service Registry etc.
> So what other components is doing is to lookup in this registry if
> there is a single instance of a specific class type, and then use
> that.
>
> There is a little guide here how to add a new Camel component
> http://camel.apache.org/add-new-component-guide.html
>
> We do have a maven archetype to create a new camel component project,
> or what other people sometimes do is to copy an existing component and
> then delete/modify its source code.
> http://camel.apache.org/camel-maven-archetypes.html
>
>
>
>
>
> On Fri, Jun 15, 2018 at 12:48 PM, Rafal Korytkowski
>  wrote:
> > Hi,
> >
> > We're considering implementing a Camel component for Teiid (
> http://teiid.io/)
> > and looking for your insights on some design aspects and general
> thoughts.
> >
> > Teiid is a data virtualization engine that comes as in-place real-time
> > integration of heterogeneous data sources (~50). Teiid exposes them
> through
> > a SQL engine and ODATA REST endpoints. It is typically run as a server
> > being accessed by SQL clients.
> >
> > Data sources supported by Teiid are pretty much a subset of what Camel
> > already supports, but the benefit we see is that it provides the SQL
> engine
> > to access them all in a unified way, which makes integrations more
> > straightforward than using custom APIs.
> >
> > 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
> > component. It would simplify its usage.
> >
> > Would you have any recommendations for writing such a component?
> >
> > One aspect we need to consider is, if it would be possible to reuse
> somehow
> > an instance of Teiid within a route or across routes or share some of
> > Teiid's metadata so that we do not have to bring up an instance each
> time.
> >
> > Finally, we have just started a similar conversion on the Teiid forum so,
> > if you are interested please also see
> > https://developer.jboss.org/thread/278138
> > --
> >
> > -Rafał
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
-- 

-Rafał