[jira] [Commented] (CAMEL-8983) Add random function to simple

2015-07-20 Thread Andrea Cosentino (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633083#comment-14633083
 ] 

Andrea Cosentino commented on CAMEL-8983:
-

Maybe the upper bound should be inclusive to avoid confusion.

 Add random function to simple
 -

 Key: CAMEL-8983
 URL: https://issues.apache.org/jira/browse/CAMEL-8983
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Priority: Minor

 We be nice with a random function in simple so you can do random delays 
 during processor or whatnot
 {code}
 ${random(10)}
 {code}
 To return a random value between 0 and 9.
 And to do with range
 {code}
 ${random(10,20)}
 {code}
 To select a random number between 10 and 19.
 We may ponder a bit about the upper bound should be inclusive or exclusive?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8980) Add Camel-git feature

2015-07-20 Thread Andrea Cosentino (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633081#comment-14633081
 ] 

Andrea Cosentino commented on CAMEL-8980:
-

It is already a bundle, as Freeman stated in SM JIRA ticket.

 Add Camel-git feature
 -

 Key: CAMEL-8980
 URL: https://issues.apache.org/jira/browse/CAMEL-8980
 Project: Camel
  Issue Type: Improvement
  Components: camel-git, karaf
Affects Versions: 2.16.0
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Priority: Minor
 Fix For: Future


 We need to add camel-git as feature.
 I'll open a ticket to ServiceMix guys, to release a Jgit bundle.
  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8984) BlueprintCamelContext OSGi service is not unregistered when context is stopped

2015-07-20 Thread Grzegorz Grzybek (JIRA)
Grzegorz Grzybek created CAMEL-8984:
---

 Summary: BlueprintCamelContext OSGi service is not unregistered 
when context is stopped
 Key: CAMEL-8984
 URL: https://issues.apache.org/jira/browse/CAMEL-8984
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek


{{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} doesn't receive 
{{CamelContextStoppingEvent}} because 
{{org.apache.camel.util.EventHelper#doNotifyEvent()}} checks for {{started}} 
state and {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} is never 
started.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8984) BlueprintCamelContext OSGi service is not unregistered when context is stopped

2015-07-20 Thread Grzegorz Grzybek (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633156#comment-14633156
 ] 

Grzegorz Grzybek commented on CAMEL-8984:
-

In camel-test-blueprint tests I had problems with two separate ({{camel-1}} and 
{{camel-2}}) camel contexts available as OSGi services. When config admin 
configurations where updated twice, I had 3 services.

 BlueprintCamelContext OSGi service is not unregistered when context is stopped
 --

 Key: CAMEL-8984
 URL: https://issues.apache.org/jira/browse/CAMEL-8984
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek

 {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} doesn't receive 
 {{CamelContextStoppingEvent}} because 
 {{org.apache.camel.util.EventHelper#doNotifyEvent()}} checks for {{started}} 
 state and {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} is never 
 started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8983) Add random function to simple

2015-07-20 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633110#comment-14633110
 ] 

Claus Ibsen commented on CAMEL-8983:


If you wanna take a stab at implementing this (it can be fun) then its to add 
it to
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/language/simple/ast/SimpleFunctionExpression.java#L218

You need to do your own little ( ) parsing to see if there is 1 or 2 numbers 
provided.

Then add unit tests to 
https://github.com/apache/camel/blob/master/camel-core/src/test/java/org/apache/camel/language/simple/SimpleTest.java#L1425

And I think the upper number should be exclusive so it works like the 
java.util.Random api
http://docs.oracle.com/javase/7/docs/api/java/util/Random.html#nextInt(int)

So if you want 0..9, then its random(10). And if you want 1..10, then its 
random(1,11)

 Add random function to simple
 -

 Key: CAMEL-8983
 URL: https://issues.apache.org/jira/browse/CAMEL-8983
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Priority: Minor

 We be nice with a random function in simple so you can do random delays 
 during processor or whatnot
 {code}
 ${random(10)}
 {code}
 To return a random value between 0 and 9.
 And to do with range
 {code}
 ${random(10,20)}
 {code}
 To select a random number between 10 and 19.
 We may ponder a bit about the upper bound should be inclusive or exclusive?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CAMEL-8983) Add random function to simple

2015-07-20 Thread Andrea Cosentino (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-8983:
---

Assignee: Andrea Cosentino

 Add random function to simple
 -

 Key: CAMEL-8983
 URL: https://issues.apache.org/jira/browse/CAMEL-8983
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Assignee: Andrea Cosentino
Priority: Minor

 We be nice with a random function in simple so you can do random delays 
 during processor or whatnot
 {code}
 ${random(10)}
 {code}
 To return a random value between 0 and 9.
 And to do with range
 {code}
 ${random(10,20)}
 {code}
 To select a random number between 10 and 19.
 We may ponder a bit about the upper bound should be inclusive or exclusive?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8983) Add random function to simple

2015-07-20 Thread Andrea Cosentino (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633111#comment-14633111
 ] 

Andrea Cosentino commented on CAMEL-8983:
-

Nice :-)

 Add random function to simple
 -

 Key: CAMEL-8983
 URL: https://issues.apache.org/jira/browse/CAMEL-8983
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Priority: Minor

 We be nice with a random function in simple so you can do random delays 
 during processor or whatnot
 {code}
 ${random(10)}
 {code}
 To return a random value between 0 and 9.
 And to do with range
 {code}
 ${random(10,20)}
 {code}
 To select a random number between 10 and 19.
 We may ponder a bit about the upper bound should be inclusive or exclusive?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CAMEL-8966) Add a dynamic to that is simpler to use than recipient list

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-8966:
--

Assignee: Claus Ibsen

 Add a dynamic to that is simpler to use than recipient list
 ---

 Key: CAMEL-8966
 URL: https://issues.apache.org/jira/browse/CAMEL-8966
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: Future


 To do dynamic to then see this FAQ
 http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
 I think we should consider a dynamic to variation, or make to dynamic out of 
 the box?
 For example to send a message to a dynamic computed uri with a header that 
 has a stock symbol name:
 {code}
 toD uri=jms:queue:stock-${header.stock}/
 {code}
 Notice the toD for to dynamic.
 It should be as simple so its a one-liner like today. If you want a bit more 
 elaborate then use recipient list. Also the language it uses is simple only.
 We could also ponder about making that defailt for to to use simple 
 language. However a few components like file uses simple language in its 
 parameters. So we would need to tell simple to be lenient and keep tokens it 
 cannot parse at this time, so you can do: 
 {code}
 to uri=file:inbox?fileName=backup-${file:name}/
 {code}
 So parsing 
 {code}
 ${file:name}
 {code}
  don't barf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly

2015-07-20 Thread Alexander Lomov (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633159#comment-14633159
 ] 

Alexander Lomov commented on CAMEL-8971:


As I see the only thing the patch does is disabling recovery despite of the 
RecoverableAggregationRepository settings. I believe it's not the desired 
solution.
I've noticed LevelDBAggregationRepository in your tests fails to confirm an 
exchange is done. I guess it's the problem.

 HazelcastAggregatorRepository redelivers incorrectly
 

 Key: CAMEL-8971
 URL: https://issues.apache.org/jira/browse/CAMEL-8971
 Project: Camel
  Issue Type: Bug
  Components: camel-hazelcast
Affects Versions: 2.16
Reporter: Ben O'Day
Assignee: Ben O'Day
Priority: Minor
 Attachments: HazelcastAggRepo-redelivery-fix.patch


 seeing an incorrect redelivery of a message when using the 
 UseLatestAggregationStrategy...
 this very basic route (see attached)...
   from(direct:start)
   .aggregate(constant(true), new 
 UseLatestAggregationStrategy())
   .completionSize(2)
   
 .aggregationRepository(repo)
   .to(mock:mock);
 resulting in a duplicate message being processed through the aggregator 
 route...
 if the default in-memory repo is used, the test behaves as expected...no 
 unnecessary redelivery, etc.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CAMEL-8984) BlueprintCamelContext OSGi service is not unregistered when context is stopped

2015-07-20 Thread Grzegorz Grzybek (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633156#comment-14633156
 ] 

Grzegorz Grzybek edited comment on CAMEL-8984 at 7/20/15 8:26 AM:
--

In camel-test-blueprint tests I had problems with two separate ({{camel-1}} and 
{{camel-2}}) camel contexts available as OSGi services. When config admin 
configurations were updated twice, I had 3 services.


was (Author: gzres):
In camel-test-blueprint tests I had problems with two separate ({{camel-1}} and 
{{camel-2}}) camel contexts available as OSGi services. When config admin 
configurations where updated twice, I had 3 services.

 BlueprintCamelContext OSGi service is not unregistered when context is stopped
 --

 Key: CAMEL-8984
 URL: https://issues.apache.org/jira/browse/CAMEL-8984
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek

 {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} doesn't receive 
 {{CamelContextStoppingEvent}} because 
 {{org.apache.camel.util.EventHelper#doNotifyEvent()}} checks for {{started}} 
 state and {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} is never 
 started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8966) Add a dynamic to that is simpler to use than recipient list

2015-07-20 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633174#comment-14633174
 ] 

Claus Ibsen commented on CAMEL-8966:


I have a prototype that is just a string where you define the dynamic uri, and 
it allows to concat using different languages (something ppl have asked for)

For example to use a bit of xpath with a prefix you can do
{code}
from(direct:start)
.toD(mock:+xpath:/order/@uri);
{code}

Notice the plus symbol that is used to denote as split between multiple 
expressions. Then you can prefix with the language to use (will use simple by 
default).

For example to have a header after the xpath you can do
{code}
from(direct:start)
.toD(mock:+xpath:/order/@uri+header:sub);
{code}

So if you send a message with
{code}
template.sendBodyAndHeader(direct:start, order uri=\foo\/, 
sub, -123);
{code}

It ends up in the mock endpoint: mock:foo-123

 Add a dynamic to that is simpler to use than recipient list
 ---

 Key: CAMEL-8966
 URL: https://issues.apache.org/jira/browse/CAMEL-8966
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
 Fix For: Future


 To do dynamic to then see this FAQ
 http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
 I think we should consider a dynamic to variation, or make to dynamic out of 
 the box?
 For example to send a message to a dynamic computed uri with a header that 
 has a stock symbol name:
 {code}
 toD uri=jms:queue:stock-${header.stock}/
 {code}
 Notice the toD for to dynamic.
 It should be as simple so its a one-liner like today. If you want a bit more 
 elaborate then use recipient list. Also the language it uses is simple only.
 We could also ponder about making that defailt for to to use simple 
 language. However a few components like file uses simple language in its 
 parameters. So we would need to tell simple to be lenient and keep tokens it 
 cannot parse at this time, so you can do: 
 {code}
 to uri=file:inbox?fileName=backup-${file:name}/
 {code}
 So parsing 
 {code}
 ${file:name}
 {code}
  don't barf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8966) Add a dynamic to that is simpler to use than recipient list

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-8966:
---
Fix Version/s: (was: Future)
   2.16.0

 Add a dynamic to that is simpler to use than recipient list
 ---

 Key: CAMEL-8966
 URL: https://issues.apache.org/jira/browse/CAMEL-8966
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 To do dynamic to then see this FAQ
 http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
 I think we should consider a dynamic to variation, or make to dynamic out of 
 the box?
 For example to send a message to a dynamic computed uri with a header that 
 has a stock symbol name:
 {code}
 toD uri=jms:queue:stock-${header.stock}/
 {code}
 Notice the toD for to dynamic.
 It should be as simple so its a one-liner like today. If you want a bit more 
 elaborate then use recipient list. Also the language it uses is simple only.
 We could also ponder about making that defailt for to to use simple 
 language. However a few components like file uses simple language in its 
 parameters. So we would need to tell simple to be lenient and keep tokens it 
 cannot parse at this time, so you can do: 
 {code}
 to uri=file:inbox?fileName=backup-${file:name}/
 {code}
 So parsing 
 {code}
 ${file:name}
 {code}
  don't barf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8966) Add a dynamic to that is simpler to use than recipient list

2015-07-20 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633421#comment-14633421
 ] 

Claus Ibsen commented on CAMEL-8966:


Documentation will show up here
http://camel.apache.org/message-endpoint.html

 Add a dynamic to that is simpler to use than recipient list
 ---

 Key: CAMEL-8966
 URL: https://issues.apache.org/jira/browse/CAMEL-8966
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 To do dynamic to then see this FAQ
 http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
 I think we should consider a dynamic to variation, or make to dynamic out of 
 the box?
 For example to send a message to a dynamic computed uri with a header that 
 has a stock symbol name:
 {code}
 toD uri=jms:queue:stock-${header.stock}/
 {code}
 Notice the toD for to dynamic.
 It should be as simple so its a one-liner like today. If you want a bit more 
 elaborate then use recipient list. Also the language it uses is simple only.
 We could also ponder about making that defailt for to to use simple 
 language. However a few components like file uses simple language in its 
 parameters. So we would need to tell simple to be lenient and keep tokens it 
 cannot parse at this time, so you can do: 
 {code}
 to uri=file:inbox?fileName=backup-${file:name}/
 {code}
 So parsing 
 {code}
 ${file:name}
 {code}
  don't barf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8966) Add a dynamic to that is simpler to use than recipient list

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-8966.

Resolution: Fixed

 Add a dynamic to that is simpler to use than recipient list
 ---

 Key: CAMEL-8966
 URL: https://issues.apache.org/jira/browse/CAMEL-8966
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 To do dynamic to then see this FAQ
 http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
 I think we should consider a dynamic to variation, or make to dynamic out of 
 the box?
 For example to send a message to a dynamic computed uri with a header that 
 has a stock symbol name:
 {code}
 toD uri=jms:queue:stock-${header.stock}/
 {code}
 Notice the toD for to dynamic.
 It should be as simple so its a one-liner like today. If you want a bit more 
 elaborate then use recipient list. Also the language it uses is simple only.
 We could also ponder about making that defailt for to to use simple 
 language. However a few components like file uses simple language in its 
 parameters. So we would need to tell simple to be lenient and keep tokens it 
 cannot parse at this time, so you can do: 
 {code}
 to uri=file:inbox?fileName=backup-${file:name}/
 {code}
 So parsing 
 {code}
 ${file:name}
 {code}
  don't barf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8985) camel-jetty - A test fails

2015-07-20 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-8985:
--

 Summary: camel-jetty - A test fails
 Key: CAMEL-8985
 URL: https://issues.apache.org/jira/browse/CAMEL-8985
 Project: Camel
  Issue Type: Test
  Components: camel-jetty
Affects Versions: 2.16.0
Reporter: Claus Ibsen
 Fix For: 2.16.0


Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.341 sec  
FAILURE! - in org.apache.camel.component.jetty.HttpStreamCacheFileTest
testStreamCacheToFileShouldBeDeletedInCaseOfException(org.apache.camel.component.jetty.HttpStreamCacheFileTest)
  Time elapsed: 0.165 sec   FAILURE!
java.lang.AssertionError: Should have thrown an exception
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.camel.component.jetty.HttpStreamCacheFileTest.testStreamCacheToFileShouldBeDeletedInCaseOfException(HttpStreamCacheFileTest.java:61)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CAMEL-8965) Wire Tap EIP - Support dynamic uris

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-8965:
--

Assignee: Claus Ibsen

 Wire Tap EIP - Support dynamic uris
 ---

 Key: CAMEL-8965
 URL: https://issues.apache.org/jira/browse/CAMEL-8965
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: Future


 Just like enrich/pollEnrich now support dynamic uris from an expression, we 
 could do the same fore wireTap. Today it uses a static endpoint.
 So in the future you can do
 {code}
 wireTap
   simplejms:queue:copy-${customer}/simple
 /wireTap
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8986) Add specialized mbean for enrich and pollEnrich

2015-07-20 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-8986:
--

 Summary: Add specialized mbean for enrich and pollEnrich
 Key: CAMEL-8986
 URL: https://issues.apache.org/jira/browse/CAMEL-8986
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, jmx
Reporter: Claus Ibsen
 Fix For: 2.16.0


We should have a ManagedEnricherMBean and ManagedPollEnricherMBean that exposes 
additional details about those eips than what a regular managed processor would 
do.

Se for example ManagedSendDynamicProcessor for an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8965) Wire Tap EIP - Support dynamic uris

2015-07-20 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633527#comment-14633527
 ] 

Claus Ibsen commented on CAMEL-8965:


Okay with the dynamic to, this can become a bit easier to implement

 Wire Tap EIP - Support dynamic uris
 ---

 Key: CAMEL-8965
 URL: https://issues.apache.org/jira/browse/CAMEL-8965
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: Future


 Just like enrich/pollEnrich now support dynamic uris from an expression, we 
 could do the same fore wireTap. Today it uses a static endpoint.
 So in the future you can do
 {code}
 wireTap
   simplejms:queue:copy-${customer}/simple
 /wireTap
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8984) BlueprintCamelContext OSGi service is not unregistered when context is stopped

2015-07-20 Thread Grzegorz Grzybek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Grzybek updated CAMEL-8984:

Fix Version/s: 2.16

 BlueprintCamelContext OSGi service is not unregistered when context is stopped
 --

 Key: CAMEL-8984
 URL: https://issues.apache.org/jira/browse/CAMEL-8984
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
 Fix For: 2.16


 {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} doesn't receive 
 {{CamelContextStoppingEvent}} because 
 {{org.apache.camel.util.EventHelper#doNotifyEvent()}} checks for {{started}} 
 state and {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} is never 
 started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers

2015-07-20 Thread Grzegorz Grzybek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Grzybek resolved CAMEL-8948.
-
Resolution: Fixed

Resolved in branch for version 2.16

 CamelBlueprintTestSupport tests have issues with namespace handlers
 ---

 Key: CAMEL-8948
 URL: https://issues.apache.org/jira/browse/CAMEL-8948
 Project: Camel
  Issue Type: Improvement
  Components: camel-blueprint
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
 Fix For: 2.16.0


 Camel blueprint tests have problems with missing namespace handlers due to 
 fragile NS code in aries-blueprint.
 This should be fixed with blueprint-core 1.4.4.
 There are also situations, where camel context is started before its 
 blueprint container is really CREATED.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8002) determineAlphabet only considers GSM 3.38 or UCS2

2015-07-20 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633594#comment-14633594
 ] 

ASF GitHub Bot commented on CAMEL-8002:
---

Github user dpocock closed the pull request at:

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


 determineAlphabet only considers GSM 3.38 or UCS2
 -

 Key: CAMEL-8002
 URL: https://issues.apache.org/jira/browse/CAMEL-8002
 Project: Camel
  Issue Type: Bug
  Components: camel-smpp
Affects Versions: 2.12.2
 Environment: n/a
Reporter: Daniel Pocock

 SmppSmCommand.determineAlphabet(Message) tries to work out which SMPP 
 alphabet code is suitable for encoding the message text.
 It checks if GSM 3.38 can represent all the characters in the message and if 
 not it just uses UCS2 (UTF-16).
 This is less than optimal.  Many messages using European languages can not be 
 encoded in GSM 3.38 but they can be coded in Latin1, which is also supported 
 by SMPP (data_coding / alphabet numeric code for Latin1 is 3)
 The jSMPP library (Alphabet.java) does not currently know about the alphabet 
 code 3.
 I proposed a patch for jSMPP and if it is accepted then camel-smpp should be 
 updated to use it.  I already started writing a patch against camel-smpp.  
 Here is the jSMPP patch:
 https://github.com/uudashr/jsmpp/pull/39



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers

2015-07-20 Thread Grzegorz Grzybek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Grzybek updated CAMEL-8948:

Fix Version/s: (was: 2.15.3)

 CamelBlueprintTestSupport tests have issues with namespace handlers
 ---

 Key: CAMEL-8948
 URL: https://issues.apache.org/jira/browse/CAMEL-8948
 Project: Camel
  Issue Type: Improvement
  Components: camel-blueprint
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
 Fix For: 2.16.0


 Camel blueprint tests have problems with missing namespace handlers due to 
 fragile NS code in aries-blueprint.
 This should be fixed with blueprint-core 1.4.4.
 There are also situations, where camel context is started before its 
 blueprint container is really CREATED.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8984) BlueprintCamelContext OSGi service is not unregistered when context is stopped

2015-07-20 Thread Grzegorz Grzybek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Grzybek resolved CAMEL-8984.
-
Resolution: Fixed

Resolved 
[here|https://github.com/apache/camel/commit/9aa1ab935a24f210a8592e08a34fc6cc5ed10eea]

 BlueprintCamelContext OSGi service is not unregistered when context is stopped
 --

 Key: CAMEL-8984
 URL: https://issues.apache.org/jira/browse/CAMEL-8984
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
 Fix For: 2.16


 {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} doesn't receive 
 {{CamelContextStoppingEvent}} because 
 {{org.apache.camel.util.EventHelper#doNotifyEvent()}} checks for {{started}} 
 state and {{org.apache.camel.core.osgi.OsgiCamelContextPublisher}} is never 
 started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8965) Wire Tap EIP - Support dynamic uris

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-8965:
---
Fix Version/s: (was: Future)
   2.16.0

 Wire Tap EIP - Support dynamic uris
 ---

 Key: CAMEL-8965
 URL: https://issues.apache.org/jira/browse/CAMEL-8965
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 Just like enrich/pollEnrich now support dynamic uris from an expression, we 
 could do the same fore wireTap. Today it uses a static endpoint.
 So in the future you can do
 {code}
 wireTap
   simplejms:queue:copy-${customer}/simple
 /wireTap
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8965) Wire Tap EIP - Support dynamic uris

2015-07-20 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633658#comment-14633658
 ] 

Claus Ibsen commented on CAMEL-8965:


Add wire tap mbean so we can see more details about this eip

 Wire Tap EIP - Support dynamic uris
 ---

 Key: CAMEL-8965
 URL: https://issues.apache.org/jira/browse/CAMEL-8965
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 Just like enrich/pollEnrich now support dynamic uris from an expression, we 
 could do the same fore wireTap. Today it uses a static endpoint.
 So in the future you can do
 {code}
 wireTap
   simplejms:queue:copy-${customer}/simple
 /wireTap
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8987) Vert.x endpoints should support mutliple consumers

2015-07-20 Thread Henryk Konsek (JIRA)
Henryk Konsek created CAMEL-8987:


 Summary: Vert.x endpoints should support mutliple consumers
 Key: CAMEL-8987
 URL: https://issues.apache.org/jira/browse/CAMEL-8987
 Project: Camel
  Issue Type: Improvement
  Components: camel-vertx
Affects Versions: 2.15.2
Reporter: Henryk Konsek
Assignee: Henryk Konsek
 Fix For: 2.15.3, 2.16


Vert.x event bus supports pub/sub communication style, so it should be possible 
to connect more than one consumer to the same endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8987) Vert.x endpoints should support mutliple consumers

2015-07-20 Thread Henryk Konsek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henryk Konsek updated CAMEL-8987:
-
Description: Vert.x event bus supports pub/sub communication style and 
round robin on the queues, so it should be possible to connect more than one 
consumer to the same endpoint.  (was: Vert.x event bus supports pub/sub 
communication style, so it should be possible to connect more than one consumer 
to the same endpoint.)

 Vert.x endpoints should support mutliple consumers
 --

 Key: CAMEL-8987
 URL: https://issues.apache.org/jira/browse/CAMEL-8987
 Project: Camel
  Issue Type: Improvement
  Components: camel-vertx
Affects Versions: 2.15.2
Reporter: Henryk Konsek
Assignee: Henryk Konsek
 Fix For: 2.15.3, 2.16


 Vert.x event bus supports pub/sub communication style and round robin on the 
 queues, so it should be possible to connect more than one consumer to the 
 same endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-8987) Vert.x endpoints should support mutliple consumers

2015-07-20 Thread Henryk Konsek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henryk Konsek updated CAMEL-8987:
-
Fix Version/s: (was: 2.15.3)

 Vert.x endpoints should support mutliple consumers
 --

 Key: CAMEL-8987
 URL: https://issues.apache.org/jira/browse/CAMEL-8987
 Project: Camel
  Issue Type: Improvement
  Components: camel-vertx
Affects Versions: 2.15.2
Reporter: Henryk Konsek
Assignee: Henryk Konsek
 Fix For: 2.16


 Vert.x event bus supports pub/sub communication style and round robin on the 
 queues, so it should be possible to connect more than one consumer to the 
 same endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8988) Can't manually trigger quartz2 jobs

2015-07-20 Thread Jonathan Anstey (JIRA)
Jonathan Anstey created CAMEL-8988:
--

 Summary: Can't manually trigger quartz2 jobs
 Key: CAMEL-8988
 URL: https://issues.apache.org/jira/browse/CAMEL-8988
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz2
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
 Fix For: 2.16.0, 2.15.3


Using org.quartz.Scheduler.triggerJob to manually trigger jobs will result in 
an exception like:

2015-07-20 16:17:28,295 [amel-1_Worker-1] ERROR CamelJob   
- Failed to execute CamelJob.
org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
quartz2://MyTimer?cron=05+00+00+*+*+%3F due to: Trigger key Camel.MyTimer is 
already in use by Endpoint[quartz2://MyTimer?cron=05+00+00+*+*+%3F]

Problem is that CamelJob is having trouble with looking up the proper endpoint 
from a previously saved URI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-8957) adviceWith() doesn't work with loadBalance().failover()

2015-07-20 Thread JIRA

[ 
https://issues.apache.org/jira/browse/CAMEL-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633866#comment-14633866
 ] 

Christian Müller commented on CAMEL-8957:
-

AdviceWith() is working for almost all of our routes, also if they were already 
started when we call adviceWith() (using Camel 2.15.2).
Until (and including) Camel 2.14 it was also possible to call adviceWith() for 
an already started route which is using the loadBalance().

For me, this is a regression.

However, as long as we have a solution, I'm fine with it.
I update the WIKI page to make it clear that we recommend (and only support) 
adviceWith() on a non started route.

Thanks for the clarification!

 adviceWith() doesn't work with loadBalance().failover() 
 

 Key: CAMEL-8957
 URL: https://issues.apache.org/jira/browse/CAMEL-8957
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.15.2
Reporter: Christian Müller
Assignee: Claus Ibsen
 Fix For: 2.16.0, 2.15.3

 Attachments: InterceptSendToEndpointWithLoadbalancerTest.java


 I will provide a test case later this week.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8987) Vert.x endpoints should support mutliple consumers

2015-07-20 Thread Henryk Konsek (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henryk Konsek resolved CAMEL-8987.
--
Resolution: Fixed

Resolved in da9f0f773f37a09c61c276e0e4b6ac19ab4ba09b.

 Vert.x endpoints should support mutliple consumers
 --

 Key: CAMEL-8987
 URL: https://issues.apache.org/jira/browse/CAMEL-8987
 Project: Camel
  Issue Type: Improvement
  Components: camel-vertx
Affects Versions: 2.15.2
Reporter: Henryk Konsek
Assignee: Henryk Konsek
 Fix For: 2.16


 Vert.x event bus supports pub/sub communication style and round robin on the 
 queues, so it should be possible to connect more than one consumer to the 
 same endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8965) Wire Tap EIP - Support dynamic uris

2015-07-20 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-8965.

Resolution: Fixed

Uses same dynamic uri as the new toD does - then we stay compatible.

 Wire Tap EIP - Support dynamic uris
 ---

 Key: CAMEL-8965
 URL: https://issues.apache.org/jira/browse/CAMEL-8965
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, eip
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.16.0


 Just like enrich/pollEnrich now support dynamic uris from an expression, we 
 could do the same fore wireTap. Today it uses a static endpoint.
 So in the future you can do
 {code}
 wireTap
   simplejms:queue:copy-${customer}/simple
 /wireTap
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-8989) SJMS drops messages with null body even if allowNullBody is true

2015-07-20 Thread Jonathan Anstey (JIRA)
Jonathan Anstey created CAMEL-8989:
--

 Summary: SJMS drops messages with null body even if allowNullBody 
is true
 Key: CAMEL-8989
 URL: https://issues.apache.org/jira/browse/CAMEL-8989
 Project: Camel
  Issue Type: Bug
  Components: camel-sjms
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
 Fix For: 2.16.0, 2.15.3






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8988) Can't manually trigger quartz2 jobs

2015-07-20 Thread Jonathan Anstey (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Anstey resolved CAMEL-8988.

Resolution: Fixed

 Can't manually trigger quartz2 jobs
 ---

 Key: CAMEL-8988
 URL: https://issues.apache.org/jira/browse/CAMEL-8988
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz2
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
 Fix For: 2.16.0, 2.15.3


 Using org.quartz.Scheduler.triggerJob to manually trigger jobs will result in 
 an exception like:
 2015-07-20 16:17:28,295 [amel-1_Worker-1] ERROR CamelJob  
  - Failed to execute CamelJob.
 org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
 quartz2://MyTimer?cron=05+00+00+*+*+%3F due to: Trigger key Camel.MyTimer is 
 already in use by Endpoint[quartz2://MyTimer?cron=05+00+00+*+*+%3F]
 Problem is that CamelJob is having trouble with looking up the proper 
 endpoint from a previously saved URI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-8989) SJMS drops messages with null body even if allowNullBody is true

2015-07-20 Thread Jonathan Anstey (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Anstey resolved CAMEL-8989.

Resolution: Fixed

 SJMS drops messages with null body even if allowNullBody is true
 

 Key: CAMEL-8989
 URL: https://issues.apache.org/jira/browse/CAMEL-8989
 Project: Camel
  Issue Type: Bug
  Components: camel-sjms
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
 Fix For: 2.16.0, 2.15.3






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)