[jira] [Commented] (CAMEL-10389) Move string related function from ObjectHelper to StringHelper

2016-10-14 Thread Luca Burgazzoli (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575699#comment-15575699
 ] 

Luca Burgazzoli commented on CAMEL-10389:
-

As there is a StringHelper it would be nice to move string related functions 
from ObjectHelper to StringHelper.
We could keep  ObjectHelper functions for a wile marking them as deprecated and 
delegate the implementation to StringHelper

> Move string related function from ObjectHelper to StringHelper
> --
>
> Key: CAMEL-10389
> URL: https://issues.apache.org/jira/browse/CAMEL-10389
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.19.0
>
>




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

[jira] [Created] (CAMEL-10390) ObjectHelper's after/before/between enhancements

2016-10-14 Thread Luca Burgazzoli (JIRA) 
Luca Burgazzoli created CAMEL-10390:
---

 Summary: ObjectHelper's after/before/between enhancements
 Key: CAMEL-10390
 URL: https://issues.apache.org/jira/browse/CAMEL-10390
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Luca Burgazzoli
Assignee: Luca Burgazzoli
Priority: Minor
 Fix For: 2.18.1, 2.19.0


I've sometime had the need to find a string after a separator, lookup
an object based on the result value and then use it to process
something, like:

String after = ObjectHelper.after(key, ":");
if (after != null) {
MyStuff s = cache.get(after)
if (s != null) {
s.doSomething(exchange)
}
}


So I wonder whether it makes sense to add a 'fluent' variant to these
functions to impement such pattern, like:

 Optional after(String value, String delimiter,
Function function)


The we could do something like:

ObjectHelper.after(key, ":", cache::get).ifPresent(s ->
s.doSomething(exchange));



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

[jira] [Created] (CAMEL-10389) Move string related function from ObjectHelper to StringHelper

2016-10-14 Thread Luca Burgazzoli (JIRA) 
Luca Burgazzoli created CAMEL-10389:
---

 Summary: Move string related function from ObjectHelper to 
StringHelper
 Key: CAMEL-10389
 URL: https://issues.apache.org/jira/browse/CAMEL-10389
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Luca Burgazzoli
Assignee: Luca Burgazzoli
Priority: Minor
 Fix For: 2.19.0






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

[jira] [Resolved] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser

2016-10-14 Thread Luca Burgazzoli (JIRA) 

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

Luca Burgazzoli resolved CAMEL-10352.
-
   Resolution: Fixed
Fix Version/s: 2.19.0
   2.18.1

> Optionally delegate to Aries PropertyEvaluator services in 
> BlueprintPropertiesParser
> 
>
> Key: CAMEL-10352
> URL: https://issues.apache.org/jira/browse/CAMEL-10352
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-blueprint, osgi
>Reporter: Grzegorz Grzybek
>Assignee: Luca Burgazzoli
> Fix For: 2.18.1, 2.19.0
>
>




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

[jira] [Updated] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-10387:

Priority: Minor  (was: Major)

> JMS correlationIdAsBytes should return null and not byte array with zero 
> values
> ---
>
> Key: CAMEL-10387
> URL: https://issues.apache.org/jira/browse/CAMEL-10387
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jms
>Affects Versions: 2.18.0
>Reporter: Terral Guillaume
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
> for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
> this byte array is dump in an XML that no one can parse.
> Therefore I think it could be usefull to return null when we receive a 
> bytearray full of 0.



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

[jira] [Commented] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575406#comment-15575406
 ] 

ASF GitHub Bot commented on CAMEL-10387:


Github user guillaumeterral closed the pull request at:

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


> JMS correlationIdAsBytes should return null and not byte array with zero 
> values
> ---
>
> Key: CAMEL-10387
> URL: https://issues.apache.org/jira/browse/CAMEL-10387
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jms
>Affects Versions: 2.18.0
>Reporter: Terral Guillaume
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
> for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
> this byte array is dump in an XML that no one can parse.
> Therefore I think it could be usefull to return null when we receive a 
> bytearray full of 0.



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

[jira] [Resolved] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-10387.
-
   Resolution: Fixed
 Assignee: Claus Ibsen
Fix Version/s: 2.19.0
   2.18.1
   2.17.4

Thanks for the PR

> JMS correlationIdAsBytes should return null and not byte array with zero 
> values
> ---
>
> Key: CAMEL-10387
> URL: https://issues.apache.org/jira/browse/CAMEL-10387
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jms
>Affects Versions: 2.18.0
>Reporter: Terral Guillaume
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
> for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
> this byte array is dump in an XML that no one can parse.
> Therefore I think it could be usefull to return null when we receive a 
> bytearray full of 0.



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

[jira] [Updated] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-10387:

Issue Type: Improvement  (was: Bug)

> JMS correlationIdAsBytes should return null and not byte array with zero 
> values
> ---
>
> Key: CAMEL-10387
> URL: https://issues.apache.org/jira/browse/CAMEL-10387
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jms
>Affects Versions: 2.18.0
>Reporter: Terral Guillaume
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
> for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
> this byte array is dump in an XML that no one can parse.
> Therefore I think it could be usefull to return null when we receive a 
> bytearray full of 0.



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

[jira] [Created] (CAMEL-10388) Dynamic update predicate/expression at runtime

2016-10-14 Thread Claus Ibsen (JIRA) 
Claus Ibsen created CAMEL-10388:
---

 Summary: Dynamic update predicate/expression at runtime
 Key: CAMEL-10388
 URL: https://issues.apache.org/jira/browse/CAMEL-10388
 Project: Camel
  Issue Type: New Feature
  Components: camel-core
Reporter: Claus Ibsen
 Fix For: Future


When using expression and predicates in your routes, then they are created once 
during startup of Camel.

It may be desirable to allow dynamic updating these at runtime based on a 
configuration parameter change configured from a property placeholder.

For example
{code:xml}

  
{{auditEnabled}}

  
  ...
{code}

In this example the simple predicate in the filter should be automatic updated 
if the property placeholder value changes.

This requires

1. Properties component to support notification of value changes (SPI hook)
2. Predicate/Expression Factory in camel-core
3. Creating all expression/predicates using the factory
4. Option to turn this feature on (off by default)
5. If the option is on, then the factory creates the expression/predicate with 
a wrapper that hooks into the notification event and listen on changes. If a 
change happens, then expression/predicate is re-created and swapped out with 
the existing.

There should not be a global lock, so the changes happens as-is and they are 
not atomic. So end users should just beware, that if you do multiple property 
changes then depending on concurrency then at any given time some 
predicates/expression may be updated while others are still using old values.

We can optimize so they only update if the property placeholder key is used by 
the expression/predicate.

Notice that endpoints is not supported. For those to updates you would need to 
restart/re-create the route. Or use dynamic-to.

For the consumer we could consider a way for it to allow to auto restart by 
doing a route stop/update/start.

However this is a slipping stope. As having immutable containers and leaving 
updates to be done by a platform is better/safer.




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

[jira] [Commented] (CAMEL-10385) simple ognl expression issue w/ list & spring boot

2016-10-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575315#comment-15575315
 ] 

ASF GitHub Bot commented on CAMEL-10385:


Github user dmitriyC300 closed the pull request at:

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


> simple ognl expression issue w/ list & spring boot
> --
>
> Key: CAMEL-10385
> URL: https://issues.apache.org/jira/browse/CAMEL-10385
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot
>Affects Versions: 2.17.0, 2.17.3, 2.18.0
>Reporter: Dmitriy Frolov
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> conflict running simple expression w/ list under spring boot.  
> SpringTypeConverter is registered as a fallback converter which gets picked 
> up during ognl while attempting to convert list -> map causing an exception 
> instead of a null response that is expected.  It is happening under 2.17 & 
> 2.18.
> sample expression: ${body.list[0].field} 
> 10:20:32.499 [main] TRACE o.a.c.i.c.DefaultTypeConverter | Converting 
> java.util.ArrayList -> java.util.Map 
> 10:20:32.500 [main] TRACE o.a.c.i.c.DefaultTypeConverter | Using converter: 
> org.apache.camel.impl.converter.ArrayTypeConverter@79d7035 to convert [class 
> java.util.ArrayList=>interface java.util.Map] 
> Caused by: org.apache.camel.TypeConversionException: Error during type 
> conversion from type: java.util.ArrayList to the required type: java.util.Map 
> with due Failed to convert from type [java.util.ArrayList] to type 
> [java.util.Map] 
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:629)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:150)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:121)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.lookupResult(BeanExpression.java:358)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.process(BeanExpression.java:334)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:114)
>  
> ... 55 common frames omitted 
> Caused by: org.springframework.core.convert.ConversionFailedException: Failed 
> to convert from type [java.util.ArrayList] to type [java.util.Map] 
> at 
> org.springframework.core.convert.support.ConversionUtils.invokeConverter(ConversionUtils.java:42)
>  
> at 
> org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.java:192)
>  
> at 
> org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.java:176)
>  
> at 
> org.apache.camel.spring.boot.SpringTypeConverter.convertTo(SpringTypeConverter.java:46)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.doConvertTo(BaseTypeConverterRegistry.java:346)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:133)
>  
> ... 59 common frames omitted 



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

[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser

2016-10-14 Thread Luca Burgazzoli (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571731#comment-15571731
 ] 

Luca Burgazzoli edited comment on CAMEL-10352 at 10/14/16 11:54 AM:


[~davsclaus] [~gzres]

I had a second look at the code and I think we can implement this thing in a 
better and less intrusive way, some background:

- BlueprintPropertiesParser invokes AbstractPropertyPlaceholder::getProperty 
via reflection (as it is protected) and this method does not take into account 
PropertyEvaluator
- DefaultPropertiesParser tries to resolve a placeholder using registered 
functions then it check if the placeholder has a default value before to call 
doGetPropertyValue so if you have a placeholder named prefix:something, you'll 
get doGetPropertyValue invoked with prefix

To let PropertyEvaluators be taken into account, we could:

- Invoke AbstractPropertyPlaceholder::retrieveValue which eventually invokes a 
PropertyEvaluator
- Invoke parseProperty in DefaultPropertiesParser::getPropertyValue before 
searching for the default so that you can give a change to the specific 
subclass ((in our case BlueprintPropertiesParser) to resolve the placeholder as 
it is , if no result are returned we then go ahead as today searching for a 
default and so on.


By doing so we relies on Aries for property resolution so we do not need to 
care about PropertyEvaluators or any other stuff that may land in aries in the 
future and we do not need to add a new prefix resolution in 
BlueprintPropertiesParser.


[Here|https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10352] 
you can wee the required changes

Let me know what you think.


Links:
1) 
https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L99
2) 
https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L138
3) 
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/properties/DefaultPropertiesParser.java#L213-L234ù
4) 
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/properties/DefaultPropertiesParser.java#L237-L241



was (Author: lb):
[~davsclaus] [~gzres]

I had a second look at the code and I think we can implement this thing in a 
better and less intrusive way, some background:

- BlueprintPropertiesParser invokes AbstractPropertyPlaceholder::getProperty 
via reflection (as it is protected) and this method does not take into account 
PropertyEvaluator
- DefaultPropertiesParser tries to resolve a placeholder using registered 
functions then it check if the placeholder has a default value before to call 
doGetPropertyValue so if you have a placeholder named prefix:something, you'll 
get doGetPropertyValue invoked with prefix

To let PropertyEvaluators be taken into account, we could:

- Invoke AbstractPropertyPlaceholder::retrieveValue which eventually invokes a 
PropertyEvaluator
- Invoke doGetPropertyValue in DefaultPropertiesParser::getPropertyValue also 
before searching for the default so that you can give a change to the specific 
subclass ((in our case BlueprintPropertiesParser) to resolve the placeholder as 
it is , if no result are returned we then go ahead as today searching for a 
default and so on.


By doing so we relies on Aries for property resolution so we do not need to 
care about PropertyEvaluators or any other stuff that may land in aries in the 
future and we do not need to add a new prefix resolution in 
BlueprintPropertiesParser.


[Here|https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10352] 
you can wee the required changes

Let me know what you think.


Links:
1) 
https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L99
2) 
https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L138
3) 
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/properties/DefaultPropertiesParser.java#L213-L234ù
4) 
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/properties/DefaultPropertiesParser.java#L237-L241


> Optionally delegate to Aries PropertyEvaluator services in 
> BlueprintPropertiesParser
> 
>
> Key: CAMEL-10352
> URL: https://issues.apache.org/jira/browse/CAMEL-10352
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-blueprint, osgi
>Reporter: Grzegorz Grzybek
>Assignee: Luca Burgazzoli
>

[jira] [Commented] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575098#comment-15575098
 ] 

ASF GitHub Bot commented on CAMEL-10387:


GitHub user guillaumeterral opened a pull request:

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

CAMEL-10387 - Return null if the byte array contains only 0x0 values



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

$ git pull https://github.com/guillaumeterral/camel CAMEL-10387

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

https://github.com/apache/camel/pull/1212.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 #1212


commit a140889f693ac829376bcf5afb37fbfbae23963f
Author: Guillaume Terral 
Date:   2016-10-14T11:45:11Z

CAMEL-10387 - Return null if the byte array contains only 0x0 values




> JMS correlationIdAsBytes should return null and not byte array with zero 
> values
> ---
>
> Key: CAMEL-10387
> URL: https://issues.apache.org/jira/browse/CAMEL-10387
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jms
>Affects Versions: 2.18.0
>Reporter: Terral Guillaume
>
> When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
> for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
> this byte array is dump in an XML that no one can parse.
> Therefore I think it could be usefull to return null when we receive a 
> bytearray full of 0.



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

[jira] [Created] (CAMEL-10387) JMS correlationIdAsBytes should return null and not byte array with zero values

2016-10-14 Thread Terral Guillaume (JIRA) 
Terral Guillaume created CAMEL-10387:


 Summary: JMS correlationIdAsBytes should return null and not byte 
array with zero values
 Key: CAMEL-10387
 URL: https://issues.apache.org/jira/browse/CAMEL-10387
 Project: Camel
  Issue Type: Bug
  Components: camel-jms
Affects Versions: 2.18.0
Reporter: Terral Guillaume


When a JMS broker send a null JMSCorrelationId and a byte array full of zero 
for JMSCorrelationIdAsBytes it creates issues with the hawtio webconsole as 
this byte array is dump in an XML that no one can parse.

Therefore I think it could be usefull to return null when we receive a 
bytearray full of 0.





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

[jira] [Work stopped] (CAMEL-10327) New Apache drill component

2016-10-14 Thread Fabrizio Spataro (JIRA) 

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

Work on CAMEL-10327 stopped by Fabrizio Spataro.

> New Apache drill component
> --
>
> Key: CAMEL-10327
> URL: https://issues.apache.org/jira/browse/CAMEL-10327
> Project: Camel
>  Issue Type: New Feature
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
>Priority: Minor
>
> Hello,
> the main idea is to create a producer to run queries on the apache drill 
> cluster. Can i start to develop this "simple" producer?
> kings regards



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

[jira] [Commented] (CAMEL-10327) New Apache drill component

2016-10-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15574759#comment-15574759
 ] 

ASF GitHub Bot commented on CAMEL-10327:


GitHub user Fabryprog opened a pull request:

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

Camel 10327, New Apache drill component

https://issues.apache.org/jira/browse/CAMEL-10327

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

$ git pull https://github.com/Fabryprog/camel CAMEL-10327

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

https://github.com/apache/camel/pull/1211.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 #1211


commit 59e1110eca2c912f9e4baa30a7d08368be03ebe7
Author: Fabryprog 
Date:   2016-09-25T21:34:26Z

CAMEL-10327, Apache Drill component

commit c6444a928797d9aa55002f61362b86d5efaa95e6
Author: Fabrizio Spataro 
Date:   2016-09-27T06:22:23Z

CAMEL-10327, fix doc

commit 9e1cc40f0a3a71e2dfa3b21a63ffee380b9773a0
Author: Fabrizio Spataro 
Date:   2016-10-13T15:03:48Z

Merge branch 'master' of https://github.com/Fabryprog/camel into CAMEL-10327

commit 9fb6b99e948747ab934d6e870cae873947f28e2a
Author: Fabrizio Spataro 
Date:   2016-10-14T09:19:33Z

CAMEL-10327, new component apache-drill




> New Apache drill component
> --
>
> Key: CAMEL-10327
> URL: https://issues.apache.org/jira/browse/CAMEL-10327
> Project: Camel
>  Issue Type: New Feature
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
>Priority: Minor
>
> Hello,
> the main idea is to create a producer to run queries on the apache drill 
> cluster. Can i start to develop this "simple" producer?
> kings regards



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

[jira] [Resolved] (CAMEL-10386) simple language nullsafe expression fails on empty array

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-10386.
-
Resolution: Fixed
  Assignee: Claus Ibsen

Thanks for the PR

> simple language nullsafe expression fails on empty array
> 
>
> Key: CAMEL-10386
> URL: https://issues.apache.org/jira/browse/CAMEL-10386
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Dmitriy Frolov
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.18.1, 2.19.0
>
>
> limitation w/ simple language on the 1st index of an empty array with a 
> nullsafe expression  
> sample expression: ${in.body?.list[0].toString}
> org.apache.camel.language.bean.RuntimeBeanExpressionException: Failed to 
> invoke method: ?.get('list')[0].toString on java.util.HashMap due to: 
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:120)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:138)
>  
> at 
> org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:126)
>  
> at 
> org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:118)
>  
> at 
> org.apache.camel.builder.ExpressionBuilder$40.evaluate(ExpressionBuilder.java:993)
>  
> at 
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36)
>  
> at 
> org.apache.camel.TestSupport.assertExpression(TestSupport.java:255) 
> at 
> org.apache.camel.ContextTestSupport.assertExpression(ContextTestSupport.java:314)
>  
> at 
> org.apache.camel.LanguageTestSupport.assertExpression(LanguageTestSupport.java:62)
>  
> at 
> org.apache.camel.LanguageTestSupport.assertExpression(LanguageTestSupport.java:69)
>  
> at 
> org.apache.camel.language.simple.SimpleTest.testOGNLBodyEmptyList(SimpleTest.java:267)
>  
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:497) 
> at junit.framework.TestCase.runTest(TestCase.java:176) 
> at junit.framework.TestCase.runBare(TestCase.java:141) 
> at org.apache.camel.TestSupport.runBare(TestSupport.java:58) 
> at junit.framework.TestResult$1.protect(TestResult.java:122) 
> at junit.framework.TestResult.runProtected(TestResult.java:142) 
> at junit.framework.TestResult.run(TestResult.java:125) 
> at junit.framework.TestCase.run(TestCase.java:129) 
> at junit.framework.TestSuite.runTest(TestSuite.java:252) 
> at junit.framework.TestSuite.run(TestSuite.java:247) 
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) 
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>  
> Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 
> at java.util.ArrayList.rangeCheck(ArrayList.java:653) 
> at java.util.ArrayList.get(ArrayList.java:429) 
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.lookupResult(BeanExpression.java:385)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.process(BeanExpression.java:334)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:114)
>  



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

[jira] [Updated] (CAMEL-10386) simple language nullsafe expression fails on empty array

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-10386:

Fix Version/s: 2.19.0
   2.18.1

> simple language nullsafe expression fails on empty array
> 
>
> Key: CAMEL-10386
> URL: https://issues.apache.org/jira/browse/CAMEL-10386
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Dmitriy Frolov
>Priority: Trivial
> Fix For: 2.18.1, 2.19.0
>
>
> limitation w/ simple language on the 1st index of an empty array with a 
> nullsafe expression  
> sample expression: ${in.body?.list[0].toString}
> org.apache.camel.language.bean.RuntimeBeanExpressionException: Failed to 
> invoke method: ?.get('list')[0].toString on java.util.HashMap due to: 
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:120)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:138)
>  
> at 
> org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:126)
>  
> at 
> org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:118)
>  
> at 
> org.apache.camel.builder.ExpressionBuilder$40.evaluate(ExpressionBuilder.java:993)
>  
> at 
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36)
>  
> at 
> org.apache.camel.TestSupport.assertExpression(TestSupport.java:255) 
> at 
> org.apache.camel.ContextTestSupport.assertExpression(ContextTestSupport.java:314)
>  
> at 
> org.apache.camel.LanguageTestSupport.assertExpression(LanguageTestSupport.java:62)
>  
> at 
> org.apache.camel.LanguageTestSupport.assertExpression(LanguageTestSupport.java:69)
>  
> at 
> org.apache.camel.language.simple.SimpleTest.testOGNLBodyEmptyList(SimpleTest.java:267)
>  
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:497) 
> at junit.framework.TestCase.runTest(TestCase.java:176) 
> at junit.framework.TestCase.runBare(TestCase.java:141) 
> at org.apache.camel.TestSupport.runBare(TestSupport.java:58) 
> at junit.framework.TestResult$1.protect(TestResult.java:122) 
> at junit.framework.TestResult.runProtected(TestResult.java:142) 
> at junit.framework.TestResult.run(TestResult.java:125) 
> at junit.framework.TestCase.run(TestCase.java:129) 
> at junit.framework.TestSuite.runTest(TestSuite.java:252) 
> at junit.framework.TestSuite.run(TestSuite.java:247) 
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) 
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>  
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>  
> Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 
> at java.util.ArrayList.rangeCheck(ArrayList.java:653) 
> at java.util.ArrayList.get(ArrayList.java:429) 
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.lookupResult(BeanExpression.java:385)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.process(BeanExpression.java:334)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:114)
>  



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

[jira] [Commented] (CAMEL-10384) Shutdown broken when using Spring Boot

2016-10-14 Thread Claus Ibsen (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15574628#comment-15574628
 ] 

Claus Ibsen commented on CAMEL-10384:
-

You are welcome to work on a PR to fix this

> Shutdown broken when using Spring Boot
> --
>
> Key: CAMEL-10384
> URL: https://issues.apache.org/jira/browse/CAMEL-10384
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot
>Affects Versions: 2.17.3
>Reporter: Artur Markiewicz
>Priority: Minor
>
> Camel doesn't shutdown properly in a Spring Boot environment. Calling the 
> /shutdown endpoint causes Camel to hang-up after stopping the CamelContext. 
> The reason for this is the count-down latch in the 
> CamelSpringBootApplicationController. The overriden Main class modifies the 
> latch in the Main class itself, not the one in 
> CamelSpringBootApplicationController. As a result, the latch in 
> CamelSpringBootApplicationController is waiting forever preventing a proper 
> shutdown.
> {code:title=CamelSpringBootApplicationController .java|borderStyle=solid}
> public CamelSpringBootApplicationController(final ApplicationContext 
> applicationContext, final CamelContext camelContext) {
> this.main = new Main() {
>  
> ...
> @Override
> protected void doStop() throws Exception {
> LOG.debug("Controller is shutting down CamelContext");
> try {
> super.doStop();
> } finally {
> // Should be 
> CamelSpringBootApplicationController.this.latch.countDown();
> latch.countDown();
> }
> }
> };
> }
> {code}



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

[jira] [Updated] (CAMEL-10384) Shutdown broken when using Spring Boot

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-10384:

Labels:   (was: easyfix)

> Shutdown broken when using Spring Boot
> --
>
> Key: CAMEL-10384
> URL: https://issues.apache.org/jira/browse/CAMEL-10384
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot
>Affects Versions: 2.17.3
>Reporter: Artur Markiewicz
>Priority: Minor
>
> Camel doesn't shutdown properly in a Spring Boot environment. Calling the 
> /shutdown endpoint causes Camel to hang-up after stopping the CamelContext. 
> The reason for this is the count-down latch in the 
> CamelSpringBootApplicationController. The overriden Main class modifies the 
> latch in the Main class itself, not the one in 
> CamelSpringBootApplicationController. As a result, the latch in 
> CamelSpringBootApplicationController is waiting forever preventing a proper 
> shutdown.
> {code:title=CamelSpringBootApplicationController .java|borderStyle=solid}
> public CamelSpringBootApplicationController(final ApplicationContext 
> applicationContext, final CamelContext camelContext) {
> this.main = new Main() {
>  
> ...
> @Override
> protected void doStop() throws Exception {
> LOG.debug("Controller is shutting down CamelContext");
> try {
> super.doStop();
> } finally {
> // Should be 
> CamelSpringBootApplicationController.this.latch.countDown();
> latch.countDown();
> }
> }
> };
> }
> {code}



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

[jira] [Updated] (CAMEL-10384) Shutdown broken when using Spring Boot

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-10384:

Priority: Minor  (was: Major)

> Shutdown broken when using Spring Boot
> --
>
> Key: CAMEL-10384
> URL: https://issues.apache.org/jira/browse/CAMEL-10384
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot
>Affects Versions: 2.17.3
>Reporter: Artur Markiewicz
>Priority: Minor
>  Labels: easyfix
>
> Camel doesn't shutdown properly in a Spring Boot environment. Calling the 
> /shutdown endpoint causes Camel to hang-up after stopping the CamelContext. 
> The reason for this is the count-down latch in the 
> CamelSpringBootApplicationController. The overriden Main class modifies the 
> latch in the Main class itself, not the one in 
> CamelSpringBootApplicationController. As a result, the latch in 
> CamelSpringBootApplicationController is waiting forever preventing a proper 
> shutdown.
> {code:title=CamelSpringBootApplicationController .java|borderStyle=solid}
> public CamelSpringBootApplicationController(final ApplicationContext 
> applicationContext, final CamelContext camelContext) {
> this.main = new Main() {
>  
> ...
> @Override
> protected void doStop() throws Exception {
> LOG.debug("Controller is shutting down CamelContext");
> try {
> super.doStop();
> } finally {
> // Should be 
> CamelSpringBootApplicationController.this.latch.countDown();
> latch.countDown();
> }
> }
> };
> }
> {code}



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

[jira] [Resolved] (CAMEL-10385) simple ognl expression issue w/ list & spring boot

2016-10-14 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-10385.
-
   Resolution: Fixed
 Assignee: Claus Ibsen
Fix Version/s: 2.19.0
   2.18.1

Thanks for the PR

> simple ognl expression issue w/ list & spring boot
> --
>
> Key: CAMEL-10385
> URL: https://issues.apache.org/jira/browse/CAMEL-10385
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot
>Affects Versions: 2.17.0, 2.17.3, 2.18.0
>Reporter: Dmitriy Frolov
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> conflict running simple expression w/ list under spring boot.  
> SpringTypeConverter is registered as a fallback converter which gets picked 
> up during ognl while attempting to convert list -> map causing an exception 
> instead of a null response that is expected.  It is happening under 2.17 & 
> 2.18.
> sample expression: ${body.list[0].field} 
> 10:20:32.499 [main] TRACE o.a.c.i.c.DefaultTypeConverter | Converting 
> java.util.ArrayList -> java.util.Map 
> 10:20:32.500 [main] TRACE o.a.c.i.c.DefaultTypeConverter | Using converter: 
> org.apache.camel.impl.converter.ArrayTypeConverter@79d7035 to convert [class 
> java.util.ArrayList=>interface java.util.Map] 
> Caused by: org.apache.camel.TypeConversionException: Error during type 
> conversion from type: java.util.ArrayList to the required type: java.util.Map 
> with due Failed to convert from type [java.util.ArrayList] to type 
> [java.util.Map] 
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:629)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:150)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:121)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.lookupResult(BeanExpression.java:358)
>  
> at 
> org.apache.camel.language.bean.BeanExpression$OgnlInvokeProcessor.process(BeanExpression.java:334)
>  
> at 
> org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:114)
>  
> ... 55 common frames omitted 
> Caused by: org.springframework.core.convert.ConversionFailedException: Failed 
> to convert from type [java.util.ArrayList] to type [java.util.Map] 
> at 
> org.springframework.core.convert.support.ConversionUtils.invokeConverter(ConversionUtils.java:42)
>  
> at 
> org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.java:192)
>  
> at 
> org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.java:176)
>  
> at 
> org.apache.camel.spring.boot.SpringTypeConverter.convertTo(SpringTypeConverter.java:46)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.doConvertTo(BaseTypeConverterRegistry.java:346)
>  
> at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:133)
>  
> ... 59 common frames omitted 



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