[jira] [Updated] (CAMEL-15718) Camel lumberjack server component not thread safe

2020-10-20 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15718:
---
   Component/s: (was: camel-core)
External issue URL: 
https://stackoverflow.com/questions/64433933/apache-camel-lumberjack-component-not-thread-safe
 Affects Version/s: 3.6.0

All session data in LumberjackSessionHandler are stored as field variables and 
thus shared between different threads/channels.

These variables needs to be moved to Channel attributes - 
[https://netty.io/4.0/api/io/netty/util/AttributeMap.html]

Like:
{code:java}
ctx.channel().attr(AttributeKey.valueOf("LumberjackSessionHandler.state")).set(new
 LumberjackSessionState());
{code}

> Camel lumberjack server component not thread safe
> -
>
> Key: CAMEL-15718
> URL: https://issues.apache.org/jira/browse/CAMEL-15718
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.6.0
> Environment: camel 3.5.0, filebeat 7.9.1, jdk 1.8.0_242, Debian 10, 
> Linux 4.19.0-6-amd64
>Reporter: Erik Zimmermann
>Priority: Major
>
> I am new to camel. I use a filebeat source that delivers logfile data over 
> the lumberjack v2 batch protocol. As a receiving server I use the camel 
> lumberjack component to further process the data in a camel pipeline.
> I realized that the LumberjackSessionHandler of camels lumberjack component 
> is not stateless but is being used by camel for all parallel lumberjack 
> connection requests. Thus, new incoming connections with their own batch 
> windows mess up any ongoing process of the already existing window, e.g. 
> window size settings and counting acknowledges.
> Many different combinations of multicast().parallelProcessing().threads(...) 
> with filebeats workers/pipelines showed the same result.
> The states of the stateful LumberjackSessionHandler are mixed up and the 
> handling of parallel windows is broken which results in unwanted/unfinished 
> acknowledges. As a result it hangs up the whole communication process to the 
> filebeat source.
> The LumberjackSessionHandler is not able to handle multiple threads, but 
> camel uses it as it would be able to. 
> How can I tell camel to use separate LumberjackSessionHandlers and processing 
> pipelines for each lumberjack batch request? Or do I misunderstand the 
> concept of how camel uses components?
> Sorry, I wasn't able to find a more specific "camel-lumberjack" component in 
> the list of issue proposals above so I selected camel-core...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15717) Skip archetype integration tests in deploy profile

2020-10-20 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15717:
--

 Summary: Skip archetype integration tests in deploy profile
 Key: CAMEL-15717
 URL: https://issues.apache.org/jira/browse/CAMEL-15717
 Project: Camel
  Issue Type: Task
  Components: build system
Reporter: Jan Bednar
Assignee: Jan Bednar


See problems during latest release 
http://camel.465427.n5.nabble.com/Apache-Camel-3-6-this-October-tp5887752p5889984.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14980) camel-kafka - SerializationException - consumer keeps leaving and rejoining the group

2020-10-15 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14980:


I think something like failture strategy is overcomplicating things. It is IMO 
not needed as Camel already have similar strategies implemented as errorHandler 
and user can use that with `bridgeErrorHandler=true`.

First step is fixing that catch block. Reconnect should be attempted only for 
instances of `RetriableException`. All other types of `KafkaException` should 
be delegated to `ExceptionHandler`. There is another user with same problem 
https://stackoverflow.com/questions/64366380/apache-camel-kafka-bridgeerrorhandler-not-working

> camel-kafka - SerializationException - consumer keeps leaving and rejoining 
> the group
> -
>
> Key: CAMEL-14980
> URL: https://issues.apache.org/jira/browse/CAMEL-14980
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.2.0
>Reporter: joseph m'bimbi-bene
>Assignee: Ramu
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: camel-kafka-errors.txt, poc_camel_kafka.tar.gz
>
>
> Hello everyone,
>  
> I found out i few days ago that if a `SerializationException` is thrown when 
> the consumer tries to poll messages, it will keep leaving and joining the 
> consumer-group indefinitely and without any informative log.
>  The exception cannot either be handled by any camel exception handler.
> After some searching in the code i found out the culprit:
> {code:java}
> // org.apache.camel.component.kafka.KafkaConsumer (ligns 406-415):
> catch (KafkaException e) {
>   // some kind of error in kafka, it may happen during
>   // unsubscribing or during normal processing
>   if (unsubscribing){             
> getExceptionHandler().handleException("Error unsubscribing " + threadId + 
> " from kafka topic " + topicName, e);   
>   }else {
>     LOG.debug("KafkaException consuming {} from topic {} causedby {}. Will 
> attempt to re-connect on next run", threadId, topicName, e.getMessage());
>     reConnect = true;
>   }
> }
> {code}
>  
> `SerializationException` extends from `KafkaException`, but it is definitely 
> not a recoverable exception.
> It logs with debug level, which makes it hard to track, there are SO many 
> things logging in debug.
> It it cannot be handled by any camel exception handling mechanism.
> I think it would be better to either:
>  - change that catch so that it pinpoints the subclasses of `KafkaException` 
> that are actually recoverable from rejoining (maybe `WakeupException` and a 
> couple others)
>  - add a `catch` block for `SerializationException` and maybe 
> `ConfigException` and `OAuthBearerConfigException` before, with a log error 
> andallow the user to handle those exceptions
>  - remove that catch block entirely and let users handle any KafkaException 
> however they see fit.
> Thank you



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15693) Camel-File-watch: Add an header as plain event type on the consumer side

2020-10-15 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15693:


Agree about changing that to String with very little note in migration guide. 
The impact on user should be minimal, as type conversion between String and 
Enum and vice versa should kick in most cases.

> Camel-File-watch: Add an header as plain event type on the consumer side
> 
>
> Key: CAMEL-15693
> URL: https://issues.apache.org/jira/browse/CAMEL-15693
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-file-watch
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.7.0
>
>
> Actually we have an enum as header. To avoid breaking existing users, I'll 
> add an header with just the plain event type. This would be nice for the ckc 
> related connector.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15622) endpoint-dsl - Bean name evaluated as string in sql component

2020-10-11 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15622:
---
Component/s: (was: camel-sql)
 camel-endpointdsl

> endpoint-dsl - Bean name evaluated as string in sql component
> -
>
> Key: CAMEL-15622
> URL: https://issues.apache.org/jira/browse/CAMEL-15622
> Project: Camel
>  Issue Type: Bug
>  Components: camel-endpointdsl
>Affects Versions: 3.5.0
>Reporter: Adam Ostrožlík
>Priority: Major
> Fix For: 3.6.0
>
>
> Hi,
> I have this stack:
>  * camel spring boot starter
>  * camel-sql component
>  * camel endpoint DSL
> I have this code:
> {code:java}
> .to(sql("classpath:sql/zentiva.sql").dataSource("zentivaDataSource"))
> {code}
> If I use instance of DataSource object and set it in 
> .datasource(dataSourceBean()) there is actually a problem that camel is 
> looking in springbootcamelcontext for the name of the result of 
> *dataSourceBean.toString()* which might be like HikariDataSource (null). 
> Lookup for wrong bean name happens in
> {code:java}
> org.apache.camel.support.CamelContextHelper#mandatoryLookupAndConvert
> {code}
> Route with bean instance is not working properly. As a workaround, we have to 
> use name of the bean.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15666) Configurer for UniVocity*Format is missing options from superclass

2020-10-09 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15666.

Resolution: Fixed

[dab61fe7e45a4002e7f88ec178244b30d7f8445f|https://github.com/apache/camel/commit/dab61fe7e45a4002e7f88ec178244b30d7f8445f]

> Configurer for UniVocity*Format is missing options from superclass
> --
>
> Key: CAMEL-15666
> URL: https://issues.apache.org/jira/browse/CAMEL-15666
> Project: Camel
>  Issue Type: Bug
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
> Fix For: 3.6.0
>
>
> String `className` argument in `PackageDataFormatMojo#doParseJavaClassSource` 
> contains full name including generic types and because of that:
>  * Mojo fails on windows build
> {code:java}
> java.nio.file.InvalidPathException: Illegal char <<> at index 65: 
> org/apache/camel/dataformat/univocity/AbstractUniVocityDataFormat.java
> {code}
>  * Options from classes with generics are excluded on linux build - 
> `Files.isRegularFile` returns false for invalid names in Linux.
> I will fix this today, so it can be part of 3.6 release.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15666) Configurer for UniVocity*Format is missing options from superclass

2020-10-09 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15666:
--

 Summary: Configurer for UniVocity*Format is missing options from 
superclass
 Key: CAMEL-15666
 URL: https://issues.apache.org/jira/browse/CAMEL-15666
 Project: Camel
  Issue Type: Bug
Reporter: Jan Bednar
Assignee: Jan Bednar
 Fix For: 3.6.0


String `className` argument in `PackageDataFormatMojo#doParseJavaClassSource` 
contains full name including generic types and because of that:
 * Mojo fails on windows build
{code:java}
java.nio.file.InvalidPathException: Illegal char <<> at index 65: 
org/apache/camel/dataformat/univocity/AbstractUniVocityDataFormat.java
{code}

 * Options from classes with generics are excluded on linux build - 
`Files.isRegularFile` returns false for invalid names in Linux.

I will fix this today, so it can be part of 3.6 release.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15640) Partition component/EIP

2020-10-05 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15640:
--

 Summary: Partition component/EIP
 Key: CAMEL-15640
 URL: https://issues.apache.org/jira/browse/CAMEL-15640
 Project: Camel
  Issue Type: New Feature
Reporter: Jan Bednar
Assignee: Jan Bednar


Sometimes you need to process messages in parallel and also ensure order of 
messages per key. Kafka is great for this with its partitioning and ActiveMQ 
with message groups, but in small single instance project may be broker 
overkill.

I needed that feature in one project and solved it with something what doesnt 
look nice, similar to this pseudo code:
{code:java}
final int consumers = 10;
from("direct:source")
.process(exchange ->
exchange.getMessage().setHeader("partition",
exchange.getMessage().getHeader("partition_key")
.hashCode() % consumers)
)
.toD("seda:partition_${header.partition}");

for (int i = 0; i < consumers; i++) {
from("seda:partition_" + i)
.to("direct:target");
}
{code}
It would be great to have something like Partition component (*or maybe better 
Partition EIP?*)

It can be similar to seda, but with following features.
 * Pluggable PartitionStrategy with pluggable Expression for partition key. 
Default can be HashPartitionStrategy.
 * Message will be assigned to Thread based on following algorithm: 
_target_thread_id = hash % concurrentConsumers_

 

 

*Community feedback/discussion about this feature welcomed.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15638) Print more details if camel-format-plugin:validate fails

2020-10-05 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15638.

Fix Version/s: 3.6.0
   Resolution: Implemented

[c3850ba80548b639a2bb636983d5b1c497971085|https://github.com/apache/camel/commit/c3850ba80548b639a2bb636983d5b1c497971085]

> Print more details if camel-format-plugin:validate fails
> 
>
> Key: CAMEL-15638
> URL: https://issues.apache.org/jira/browse/CAMEL-15638
> Project: Camel
>  Issue Type: Improvement
>  Components: tooling
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
> Fix For: 3.6.0
>
>
> Utilize some diff library to print details about failed check. Extend 
> `ResultCollector` with List.
> Eg this one looks good and is Apache 2 licensed.
> https://github.com/java-diff-utils/java-diff-utils



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15638) Print more details if camel-format-plugin:validate fails

2020-10-05 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15638:
--

 Summary: Print more details if camel-format-plugin:validate fails
 Key: CAMEL-15638
 URL: https://issues.apache.org/jira/browse/CAMEL-15638
 Project: Camel
  Issue Type: Improvement
  Components: tooling
Reporter: Jan Bednar
Assignee: Jan Bednar


Utilize some diff library to print details about failed check. Extend 
`ResultCollector` with List.

Eg this one looks good and is Apache 2 licensed.

https://github.com/java-diff-utils/java-diff-utils



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15604) MongoDB - Support allowDiskUse for find operation

2020-10-04 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15604.

Fix Version/s: 3.6.0
   Resolution: Fixed

[af7e383e9fc1d25ce9665f74d33672cc5b507952|https://github.com/apache/camel/commit/af7e383e9fc1d25ce9665f74d33672cc5b507952]

> MongoDB - Support allowDiskUse for find operation
> -
>
> Key: CAMEL-15604
> URL: https://issues.apache.org/jira/browse/CAMEL-15604
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-mongodb
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
> Fix For: 3.6.0
>
>
> MongoDB 4.3.1 added support for allowDiskUse flag with find queries.
> https://jira.mongodb.org/browse/SERVER-43683
> We currently set that flag only for for aggregation operations.
> Reported on mailing list
> http://camel.465427.n5.nabble.com/Camel-Mongodb-sorting-with-allowDiskUse-not-working-tc5886534.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15613) Camel Timer does not honor fixedRate=false

2020-10-01 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15613.

Resolution: Not A Bug

Timer component is working correctly. You have used delay EIP, which is non 
blocking by default since Camel 3.
https://camel.apache.org/components/latest/eips/delay-eip.html
https://github.com/apache/camel/commit/d17a41fb6182e2991c31cb256bc093bace6b5e26

Just replace
{code:java}
.delay(6)
{code}
with
{code:java}
.delay(6).syncDelayed()
{code}
and you will see the timer is actually correctly blocked.


> Camel Timer does not honor fixedRate=false
> --
>
> Key: CAMEL-15613
> URL: https://issues.apache.org/jira/browse/CAMEL-15613
> Project: Camel
>  Issue Type: Bug
>  Components: came-core
>Affects Versions: 3.5.0
>Reporter: Sreejesh
>Priority: Minor
> Attachments: code.zip
>
>
> Noticed a different behaviour of Camel timer with 3.5.0 when compared with 
> Camel version 2.24.3. In 3.5.0. Camel timer fires events as if it is  
> fixedRate is true (even if I explicitly make it false in the Camel URL).
>  
> The same code behaves differently in Camel 2.24.3.
>  
> I am attaching sample code for 3.5.0 version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15612) Unable to find converter when using shade-plugin

2020-10-01 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15612:


And here 
https://camel.apache.org/manual/latest/faq/how-to-create-executable-jar-camel-main.html

> Unable to find converter when using shade-plugin
> 
>
> Key: CAMEL-15612
> URL: https://issues.apache.org/jira/browse/CAMEL-15612
> Project: Camel
>  Issue Type: Bug
>Reporter: Shmakov Alexey
>Priority: Major
> Attachments: converterbug.zip
>
>
> Hello, we use shade-plugin for build and deploy services to k8s.
> After starting the service builded by the maven-shade-plugin, it is 
> impossible to find the standart converter from String to DOM Document. At the 
> same time, when launched through maven-camel-plugin, everything works fine. 
> Example project in attachment.
> Example route:
> {code:java}
> from("timer:foo?period=1000")
>.setBody(constant("simple xml"))
>           .process(x->{  
>                Document doc = x.getMessage().getBody(Document.class);         
>                  
>if (doc == null) x.setProperty("MSG", "impossible converted 
> String to DOM");  
>                else x.setProperty("MSG", "String to DOM converted");          
>   })
>          .log("${exchangeProperty.MSG}");
> {code}
>  
> Log out by camel-plugin: _String to DOM converted_
> Log out by shade-plugin: _impossible converted String to DOM_
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15604) MongoDB - Support allowDiskUse for find operation

2020-09-30 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15604:
--

 Summary: MongoDB - Support allowDiskUse for find operation
 Key: CAMEL-15604
 URL: https://issues.apache.org/jira/browse/CAMEL-15604
 Project: Camel
  Issue Type: Improvement
  Components: camel-mongodb
Reporter: Jan Bednar
Assignee: Jan Bednar


MongoDB 4.3.1 added support for allowDiskUse flag with find queries.
https://jira.mongodb.org/browse/SERVER-43683
We currently set that flag only for for aggregation operations.

Reported on mailing list
http://camel.465427.n5.nabble.com/Camel-Mongodb-sorting-with-allowDiskUse-not-working-tc5886534.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15595) Extend math operators in Simple language

2020-09-29 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15595:
---
Issue Type: New Feature  (was: Bug)
  Priority: Minor  (was: Major)
   Summary: Extend math operators in Simple language  (was: math (and 
other) calculation in route)

> Extend math operators in Simple language
> 
>
> Key: CAMEL-15595
> URL: https://issues.apache.org/jira/browse/CAMEL-15595
> Project: Camel
>  Issue Type: New Feature
>  Components: came-core
>Reporter: Luca Ferrari
>Priority: Minor
>
> at the moment simple calculations with maths operators like:
>  * addition
>  * multiplication
>  * division
>  * subtraction
>  * modulus
> are not supported in simple language. It is true that you could use groovy or 
> javascript, but given simple syntax overall prevalence in camel it would make 
> it easier to support this directly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15568) Dynamic route updates causes few requests to fails

2020-09-22 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15568:


This is not about core engine, but about all components, EIPs and services 
which would need custom logic to support that. Eg how to reload Jetty consumer? 
You cannot have app listening on the same port twice. Every component would 
need to be super smart in order to decide which change can be done on runtime 
on underlying library, what needs restart, it would need to compare old and new 
value to decide what kind of change this is. And every single component will 
have its own requirements to support runtime changes.

All this effort will make implementation of components unmaintanable for 
something, what container like OSGI already  does by design. And for something, 
what can be solved by your architectural decision (Eg NGINX reverse proxy, 
which will handle failover during that few millis of downtime). There are no 
plans to support that in near future ( eg comment in CAMEL-10138 ) . This is 
job for containers like OSGI which can do this natively.

This is my point of view. If you want broader discussion, or you think you have 
some idea how to do that without rewriting all components, please join 
camel.zulipchat.com

> Dynamic route updates causes few requests to fails 
> ---
>
> Key: CAMEL-15568
> URL: https://issues.apache.org/jira/browse/CAMEL-15568
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core-engine
>Affects Versions: 3.2.0
>Reporter: Minal Bhalodi
>Priority: Minor
>
> We are using Apache Camel 3.2.0. We update camel routes at runtime using 
> below code. 
> // update routes in camel contexts. Definitions are in XML files
> ModelCamelContext mcc = camelContext.adapt(ModelCamelContext.class);
>  mcc.addRouteDefinitions({{workflowDefinitionsList}}); {{// 
> workflowDefinitionsList is the list of XML routes}}
>  
> *Problem Statement*: Dynamic routes updates causes few requests to fail at 
> runtime. When these routes are being updated, we also call getRoute to serve 
> live traffic.
> Since addRouteDefinitions first delete routes given in 
> {{workflowDefinitionsList}} from camel context and then add those routes back 
> to camelcontext, These routes won't be available for few mili second and that 
> causes request to fails.
> Route route = exchange.getContext().getRoute(workflowRouteId);  // get route
> Since there can be only one CamelContext per Application, I am not sure how 
> can I resolve this issue. Is there any other method available where we can 
> PATCH routes changes at runtime. Dynamic route updates shouldn't cause few 
> requests to fails.
>  
>  
> {{Here is camel 3 code for addRouteDefinitions method where routes are being 
> removed and added:}}
> {code:java}
> public synchronized void addRouteDefinitions(Collection 
> routeDefinitions) throws Exception {
> if (routeDefinitions != null && !routeDefinitions.isEmpty()) {
> List list = new ArrayList();
> routeDefinitions.forEach((r) -> {
> if (this.routeFilter == null || 
> (Boolean)this.routeFilter.apply(r)) {
> list.add(r);
> }
> });
> this.removeRouteDefinitions(list);
> this.routeDefinitions.addAll(list);
> if (this.shouldStartRoutes()) {
> 
> ((ModelCamelContext)this.getCamelContext().adapt(ModelCamelContext.class)).startRouteDefinitions(list);
> }
> }
> }
> {code}
>  
>  
> We are not able to updates routes in camelcontext frequently because of this 
> issue. Everytime we update routes in camelcontext that causes us some FCI 
> since we have high traffic in our application. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15569) Executable fat jar built with Gradle fails with exception

2020-09-22 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15569:
---
External issue URL: 
https://stackoverflow.com/questions/64015236/apache-camel-timer-nullpointer-exception-at-fat-jar
   Summary: Executable fat jar built with Gradle fails with 
exception  (was: Nullpointer exception at Timer component)

> Executable fat jar built with Gradle fails with exception
> -
>
> Key: CAMEL-15569
> URL: https://issues.apache.org/jira/browse/CAMEL-15569
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 3.5.0
> Environment: *Java*
> openjdk version "1.8.0_265"
> OpenJDK Runtime Environment (build 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01)
> OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)
>  
> *Gradle 6.5*
>Reporter: Gonzalo Mendoza
>Assignee: Jan Bednar
>Priority: Major
> Attachments: Screenshot from 2020-09-22 16-42-44.png
>
>
> I'm trying to implement a timer using Camel 3.5 at Gradle project with 
> OpenJDK8 as next
> {code:java}
> from("timer://watchexpiration?fixedRate=true&period=60&delay=0")...
> {code}
> But, after build the fat jar using 
> 1. Build with:  {code}./gradlew build{code} 
> 2. Run with:  {code}java -jar build/libs/app.jar{code}
> After that  I receive the next error at console
> {code:java}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
> endpoint: timer://watchexpiration?delay=0&fixedRate=true&period=60 due 
> to: Error binding property (delay=0) with name: delay on bean: 
> timer://watchexpiration?delay=0&fixedRate=true&period=60 with value: 0
> at 
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:888)
> at 
> org.apache.camel.impl.engine.AbstractCamelContext.getEndpoint(AbstractCamelContext.java:777)
> at 
> org.apache.camel.support.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:58)
> at 
> org.apache.camel.reifier.AbstractReifier.resolveEndpoint(AbstractReifier.java:177)
> at 
> org.apache.camel.reifier.RouteReifier.doCreateRoute(RouteReifier.java:250)
> at 
> org.apache.camel.reifier.RouteReifier.createRoute(RouteReifier.java:112)
> {code}
> But If I run using {code}./gradlew run{code} then works fine as I expected. I 
> don't want to use any frameworks for this project. I feel this is just a 
> config issue or something is wrong with my configuration I guess.
> How can I fix it?
> *build.gradle*
> {code:java}
>  plugins {
> id 'java'
> id 'application'
> id 'com.github.sherter.google-java-format' version '0.8'
> }
> repositories {
> jcenter()
> }
> dependencies {
> implementation 'com.google.guava:guava:29.0-jre'
> testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.2'
> testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.2'
> // Camel
> compile group: 'org.apache.camel', name: 'camel-core', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-file', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-file-watch', version: 
> '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-xstream', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-gson', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-rest', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-servlet', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-http', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-jackson', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-quartz', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-timer', version: '3.5.0'
> compile group: 'org.slf4j', name: 'slf4j-simple', version: '1.7.30'
> compile group: 'org.slf4j', name: 'slf4j-api', version: '1.7.30'
> // Dev Libs
> compileOnly("org.projectlombok:lombok:1.18.12")
> annotationProcessor("org.projectlombok:lombok:1.18.12")
> compile group: 'org.apache.commons', name: 'commons-csv', version: '1.4'
> }
> application {
> mainClassName = 'com.eip.App'
> }
> configurations {
> // configuration that holds jars to include in the jar
> extraLibs
> }
> jar {
> manifest {
> attributes(
> 'Main-Class': 'com.beam.agent.App'
> )
> }
> from {
> configurations.runtimeClasspath.collect { it.isDirectory() ? it : 
> zipTree(it) }
> }
> }
> test {
> useJUnitPlatform()
> }
> googleJavaFormat {
> exclude '**/App.java'
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15569) Nullpointer exception at Timer component

2020-09-22 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15569.

Fix Version/s: (was: Future)
 Assignee: Jan Bednar
   Resolution: Information Provided

Please dont create Jira issue for something, what is clearly your error and not 
a bug in Apache Camel. We are active on mailing list, zulip and StackOverflow 
and ready to help you. Jira is here for reporting bugs.

First read this - [https://camel.apache.org/manual/latest/support.html]
{quote}Please refrain from immediately opening a ticket in the issue tracker 
unless you are certain it’s a problem in the Camel software. If you are in 
doubt, we appreciate asking the [mailing 
list|https://camel.apache.org/manual/latest/mailing-lists.html], or [Chat 
room|https://camel.zulipchat.com/] first.
{quote}
And then look at my answer to your question on SO - 
[https://stackoverflow.com/a/64018354/8576169]
{quote}Shadowing jars is quite magic, because you need to handle duplicate 
entries somehow. In Apache Camel there are many {{META-INF}} service files, 
which are getting overwritten with your simple {{jar}} approach. Use 
{{com.github.johnrengelman.shadow}} which is allowing you to customize merging 
process.
{code:java}
shadowJar {
mergeServiceFiles() // Tell plugin to merge duplicate service files
manifest {
attributes 'Main-Class': 'com.eip.App'
}
}
apply plugin: 'com.github.johnrengelman.shadow'
{code}
{quote}

> Nullpointer exception at Timer component
> 
>
> Key: CAMEL-15569
> URL: https://issues.apache.org/jira/browse/CAMEL-15569
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 3.5.0
> Environment: *Java*
> openjdk version "1.8.0_265"
> OpenJDK Runtime Environment (build 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01)
> OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)
>  
> *Gradle 6.5*
>Reporter: Gonzalo Mendoza
>Assignee: Jan Bednar
>Priority: Major
> Attachments: Screenshot from 2020-09-22 16-42-44.png
>
>
> I'm trying to implement a timer using Camel 3.5 at Gradle project with 
> OpenJDK8 as next
> {code:java}
> from("timer://watchexpiration?fixedRate=true&period=60&delay=0")...
> {code}
> But, after build the fat jar using 
> 1. Build with:  {code}./gradlew build{code} 
> 2. Run with:  {code}java -jar build/libs/app.jar{code}
> After that  I receive the next error at console
> {code:java}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
> endpoint: timer://watchexpiration?delay=0&fixedRate=true&period=60 due 
> to: Error binding property (delay=0) with name: delay on bean: 
> timer://watchexpiration?delay=0&fixedRate=true&period=60 with value: 0
> at 
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:888)
> at 
> org.apache.camel.impl.engine.AbstractCamelContext.getEndpoint(AbstractCamelContext.java:777)
> at 
> org.apache.camel.support.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:58)
> at 
> org.apache.camel.reifier.AbstractReifier.resolveEndpoint(AbstractReifier.java:177)
> at 
> org.apache.camel.reifier.RouteReifier.doCreateRoute(RouteReifier.java:250)
> at 
> org.apache.camel.reifier.RouteReifier.createRoute(RouteReifier.java:112)
> {code}
> But If I run using {code}./gradlew run{code} then works fine as I expected. I 
> don't want to use any frameworks for this project. I feel this is just a 
> config issue or something is wrong with my configuration I guess.
> How can I fix it?
> *build.gradle*
> {code:java}
>  plugins {
> id 'java'
> id 'application'
> id 'com.github.sherter.google-java-format' version '0.8'
> }
> repositories {
> jcenter()
> }
> dependencies {
> implementation 'com.google.guava:guava:29.0-jre'
> testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.2'
> testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.2'
> // Camel
> compile group: 'org.apache.camel', name: 'camel-core', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-file', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-file-watch', version: 
> '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-xstream', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-gson', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-rest', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-servlet', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-http', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-jackson', version: '3.5.0'
> compile group: 'org.apache.camel', name: 'camel-quartz', version: '3.5.

[jira] [Resolved] (CAMEL-15568) Dynamic route updates causes few requests to fails

2020-09-22 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15568.

Resolution: Not A Problem

Hot reload of routes is not supported usage of this API. There are projects in 
Camel ecosystem much more suitable for this, like camel-quarkus or camel-k. 
You can also deploy your app in some application server, which support hot 
deploy (like Karaf, Fuse).

If you need more help with this, please ask on mailing list, gitter, or 
StackOverflow. This is not a bug.
https://camel.apache.org/manual/latest/support.html

> Dynamic route updates causes few requests to fails 
> ---
>
> Key: CAMEL-15568
> URL: https://issues.apache.org/jira/browse/CAMEL-15568
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core-engine
>Affects Versions: 3.2.0
>Reporter: Minal Bhalodi
>Priority: Minor
>
> We are using Apache Camel 3.2.0. We update camel routes at runtime using 
> below code. 
> // update routes in camel contexts. Definitions are in XML files
> ModelCamelContext mcc = camelContext.adapt(ModelCamelContext.class);
>  mcc.addRouteDefinitions({{workflowDefinitionsList}}); {{// 
> workflowDefinitionsList is the list of XML routes}}
>  
> *Problem Statement*: Dynamic routes updates causes few requests to fail at 
> runtime. When these routes are being updated, we also call getRoute to serve 
> live traffic.
> Since addRouteDefinitions first delete routes given in 
> {{workflowDefinitionsList}} from camel context and then add those routes back 
> to camelcontext, These routes won't be available for few mili second and that 
> causes request to fails.
> Route route = exchange.getContext().getRoute(workflowRouteId);  // get route
> Since there can be only one CamelContext per Application, I am not sure how 
> can I resolve this issue. Is there any other method available where we can 
> PATCH routes changes at runtime. Dynamic route updates shouldn't cause few 
> requests to fails.
>  
>  
> {{Here is camel 3 code for addRouteDefinitions method where routes are being 
> removed and added:}}
> {code:java}
> public synchronized void addRouteDefinitions(Collection 
> routeDefinitions) throws Exception {
> if (routeDefinitions != null && !routeDefinitions.isEmpty()) {
> List list = new ArrayList();
> routeDefinitions.forEach((r) -> {
> if (this.routeFilter == null || 
> (Boolean)this.routeFilter.apply(r)) {
> list.add(r);
> }
> });
> this.removeRouteDefinitions(list);
> this.routeDefinitions.addAll(list);
> if (this.shouldStartRoutes()) {
> 
> ((ModelCamelContext)this.getCamelContext().adapt(ModelCamelContext.class)).startRouteDefinitions(list);
> }
> }
> }
> {code}
>  
>  
> We are not able to updates routes in camelcontext frequently because of this 
> issue. Everytime we update routes in camelcontext that causes us some FCI 
> since we have high traffic in our application. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14811) Remove JMX Connector configuration

2020-09-21 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14811:


Hi Sourabh, please dont. 2.25.x needs to be backwards compatible as much as 
possible. This as breaking change, which should be done only for major 
releases. 

> Remove JMX Connector configuration
> --
>
> Key: CAMEL-14811
> URL: https://issues.apache.org/jira/browse/CAMEL-14811
> Project: Camel
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> For 3.2.0, we should remove the JMX Connector configuration in 
> camel-management. Creating our own registry is not properly secure and 
> doesn't buy us anything extra over just using the default JVM JMX Settings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15556) Create automated PR for regenerated sources during Github Action

2020-09-19 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15556.

Resolution: Implemented

> Create automated PR for regenerated sources during Github Action
> 
>
> Key: CAMEL-15556
> URL: https://issues.apache.org/jira/browse/CAMEL-15556
> Project: Camel
>  Issue Type: Improvement
>  Components: build system
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> Now we have check, which fails if git tree is dirty. This is serving its 
> purpose, but it is hard to keep master green with many commits. Lets modify 
> master workflow, to create automated PR instead of failing. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15556) Create automated PR for regenerated sources during Github Action

2020-09-19 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15556:
--

 Summary: Create automated PR for regenerated sources during Github 
Action
 Key: CAMEL-15556
 URL: https://issues.apache.org/jira/browse/CAMEL-15556
 Project: Camel
  Issue Type: Improvement
  Components: build system
Reporter: Jan Bednar
Assignee: Jan Bednar


Now we have check, which fails if git tree is dirty. This is serving its 
purpose, but it is hard to keep master green with many commits. Lets modify 
master workflow, to create automated PR instead of failing. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15552) Dirty tree check step in Github Action should report more details

2020-09-18 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15552:


Switched to fork bedlaj/has-changes-action temporarilly with 
[4c1e3cdf4ccd64a66cc0ff8a86fbd6e7f6e82670|https://github.com/apache/camel/commit/4c1e3cdf4ccd64a66cc0ff8a86fbd6e7f6e82670].
 I am keeping this issue open to do not forget to change back to upstream, if 
[has-changes-action#2|https://github.com/UnicornGlobal/has-changes-action/pull/2]
 gets merged.

> Dirty tree check step in Github Action should report more details
> -
>
> Key: CAMEL-15552
> URL: https://issues.apache.org/jira/browse/CAMEL-15552
> Project: Camel
>  Issue Type: Improvement
>  Components: build system
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> If this step fails, it should report the modified files to make it easier to 
> fix. Upgrade UnicornGlobal/has-changes-action if 
> [has-changes-action#2|https://github.com/UnicornGlobal/has-changes-action/pull/2]
>  gets merged or find alternative approach otherwise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15552) Dirty tree check step in Github Action should report more details

2020-09-18 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15552:
--

 Summary: Dirty tree check step in Github Action should report more 
details
 Key: CAMEL-15552
 URL: https://issues.apache.org/jira/browse/CAMEL-15552
 Project: Camel
  Issue Type: Improvement
  Components: build system
Reporter: Jan Bednar
Assignee: Jan Bednar


If this step fails, it should report the modified files to make it easier to 
fix. Upgrade UnicornGlobal/has-changes-action if 
[has-changes-action#2|https://github.com/UnicornGlobal/has-changes-action/pull/2]
 gets merged or find alternative approach otherwise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15542) camel website - Front page missing icon for zulip chat

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15542:


Is this still the case? On my side it is OK after clearing browser cache and 
site-shot.com sees also correct version - 
https://www.site-shot.com/RALRCPkTEeqgSAJCrBEAAg . 

> camel website - Front page missing icon for zulip chat
> --
>
> Key: CAMEL-15542
> URL: https://issues.apache.org/jira/browse/CAMEL-15542
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Claus Ibsen
>Priority: Major
>
> On the top right corner there is a link to zulip chat (between github and 
> twitter icons)
> https://camel.apache.org/
> We should have an icon for the chat



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15546) File consumer shuffle query param is not working

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15546.

Resolution: Not A Problem

Please read the docs. This is clearly documented.
{quote}eagerMaxMessagesPerPoll - Allows for controlling whether the limit from 
maxMessagesPerPoll is eager or not. If eager then the limit is during the 
scanning of files. Where as false would scan all files, and then perform 
sorting. Setting this option to false allows for sorting all files first, and 
then limit the poll. Mind that this requires a higher memory usage as all file 
details are in memory to perform the sorting.{quote}

And next time prefer get in touch on other channels before opening a bug. 
https://camel.apache.org/manual/latest/support.html 
{quote}We prefer people to get in touch first using the mailing list, or Chat 
room. Or take time to read FAQs, or search in the mailing list archives to find 
answers. Unfortunately some people create a JIRA ticket as first thing. Please 
don’t do that! Only if you are sure it really is a bug, etc. JIRA tickets 
create noise for the Camel team to react on issues that are not bugs but 
already covered in FAQs, in the mailing lists, etc., or in the existing 
documentation. Also on the mailing lists there are more people active to help 
you better.{quote}

> File consumer shuffle query param is not working 
> -
>
> Key: CAMEL-15546
> URL: https://issues.apache.org/jira/browse/CAMEL-15546
> Project: Camel
>  Issue Type: Bug
>  Components: came-core
>Reporter: sravan
>Priority: Major
>
> when I use shuffle query param in file consumer, the consumer not picking 
> files randomly 
>  
> from("file:\\\folder?maxMessagesPerPoll=1&delete=true&readLockMinLength=0&readLock=changed&readLockTimeout=1000&readLockCheckInterval=1000&shuffle=true)
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (CAMEL-15545) Camel file route in clustering

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar closed CAMEL-15545.
--
Resolution: Invalid

Ask on mailing list, zulip or stackoverflow. See 
https://camel.apache.org/manual/latest/support.html . Also please stop cloning 
the issue, this one was already closed as invalid yesterday CAMEL-15537 and you 
will not get answer here.

> Camel file route in clustering
> --
>
> Key: CAMEL-15545
> URL: https://issues.apache.org/jira/browse/CAMEL-15545
> Project: Camel
>  Issue Type: Wish
>  Components: came-core
>Reporter: sravan
>Priority: Major
>
> I want to run the apache camel file route on multiple nodes and the source  
> folder is same for both nodes and expecting route process files parallelly 
>  
> when I tried the running camel on multiple nodes, files are processing in a 
> round-robin fashion,
> Example:- Node1 will pick 1 file (Node2 is waiting for node1 to process)
> after node1 processing, node2 will pick a new file (Node1 will wait for node2 
> to process file)
>  
> I want both nodes should process files parallelly 
> *Route :*
> from("file:\\\folder?maxMessagesPerPoll=1&delete=true&readLockMinLength=0&readLock=changed&readLockTimeout=1000&readLockCheckInterval=1000)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15544) Using parameter tempFileName or tempPrefix with relative location in parent directory will fail

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15544:


Yes, this should probably also fail earlier. Lets keep this issue open to 
analyze.

> Using parameter tempFileName or tempPrefix with relative location in parent 
> directory will fail
> ---
>
> Key: CAMEL-15544
> URL: https://issues.apache.org/jira/browse/CAMEL-15544
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Oliver Limberg
>Priority: Major
>
> When using either parameter tempFileName or tempPrefix with a relative path, 
> the component will not create the final target directory and moving/renaming 
> the file from the temp location will fail.
> Both tests below will fail when placing them in FtpProducerTempPrefixTest
> {code:java}
> @Test
> public void testWriteUsingRelativeTempPrefix() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + "&tempPrefix=../tmp/tmp_", 
> "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> @Test
> public void testWriteUsingRelativeTempFileName() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + 
> "&tempFileName=../tmp/${file:name.noext}.tmp", "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15544) Using parameter tempFileName or tempPrefix with relative location in parent directory will fail

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15544:


Your starting directory is `/upload/user/claus` and your temp files are saved 
in `/upload/user/tmp` so yes, you are navigating outside of starting path. 
Thanks for testing with `jailStartingDirectory=false`.

> Using parameter tempFileName or tempPrefix with relative location in parent 
> directory will fail
> ---
>
> Key: CAMEL-15544
> URL: https://issues.apache.org/jira/browse/CAMEL-15544
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Oliver Limberg
>Priority: Major
>
> When using either parameter tempFileName or tempPrefix with a relative path, 
> the component will not create the final target directory and moving/renaming 
> the file from the temp location will fail.
> Both tests below will fail when placing them in FtpProducerTempPrefixTest
> {code:java}
> @Test
> public void testWriteUsingRelativeTempPrefix() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + "&tempPrefix=../tmp/tmp_", 
> "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> @Test
> public void testWriteUsingRelativeTempFileName() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + 
> "&tempFileName=../tmp/${file:name.noext}.tmp", "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15544) Using parameter tempFileName or tempPrefix with relative location in parent directory will fail

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-15544 at 9/17/20, 2:50 PM:
--

Option jailStartingDirectory is true by default, preventing you from writing 
outside of starting path. Please test with `jailStartingDirectory=false` and if 
it works, please close this issue as this is desirable behavior.


was (Author: bedla):
Option jailStartingDirectory is true by default, preventing you from writing 
outside of starting path. Please test with `jailStartingDirectory=false` and if 
it works, please close this PR as this is desirable behavior.

> Using parameter tempFileName or tempPrefix with relative location in parent 
> directory will fail
> ---
>
> Key: CAMEL-15544
> URL: https://issues.apache.org/jira/browse/CAMEL-15544
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Oliver Limberg
>Priority: Major
>
> When using either parameter tempFileName or tempPrefix with a relative path, 
> the component will not create the final target directory and moving/renaming 
> the file from the temp location will fail.
> Both tests below will fail when placing them in FtpProducerTempPrefixTest
> {code:java}
> @Test
> public void testWriteUsingRelativeTempPrefix() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + "&tempPrefix=../tmp/tmp_", 
> "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> @Test
> public void testWriteUsingRelativeTempFileName() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + 
> "&tempFileName=../tmp/${file:name.noext}.tmp", "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15544) Using parameter tempFileName or tempPrefix with relative location in parent directory will fail

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15544:


Option jailStartingDirectory is true by default, preventing you from writing 
outside of starting path. Please test with `jailStartingDirectory=false` and if 
it works, please close this PR as this is desirable behavior.

> Using parameter tempFileName or tempPrefix with relative location in parent 
> directory will fail
> ---
>
> Key: CAMEL-15544
> URL: https://issues.apache.org/jira/browse/CAMEL-15544
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Oliver Limberg
>Priority: Major
>
> When using either parameter tempFileName or tempPrefix with a relative path, 
> the component will not create the final target directory and moving/renaming 
> the file from the temp location will fail.
> Both tests below will fail when placing them in FtpProducerTempPrefixTest
> {code:java}
> @Test
> public void testWriteUsingRelativeTempPrefix() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + "&tempPrefix=../tmp/tmp_", 
> "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> @Test
> public void testWriteUsingRelativeTempFileName() throws Exception {
> sendFile("ftp://admin@localhost:"; + getPort() + 
> "/upload/user/claus?binary=false&password=admin" + 
> "&tempFileName=../tmp/${file:name.noext}.tmp", "Hello World", "claus.txt");
> Thread.sleep(500);
> File file = new File(FTP_ROOT_DIR + "/upload/user/claus/claus.txt");
> assertTrue(file.exists(), "The uploaded file should exists");
> assertEquals("Hello World", IOConverter.toString(file, null));
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15543) Apache Camel File Append Not Working in Windows

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-15543 at 9/17/20, 1:57 PM:
--

This is fixed in 2.24.3. Please reopen if you have same issue in 2.24.3, 3.0.0, 
2.25.0 or later. The linked issue also mentions workaround, if you cant upgrade.


was (Author: bedla):
This is fixed in 2.24.3. Please reopen if you have same issue in 2.24.3, 3.0.0, 
2.25.0 or later.

> Apache Camel File Append Not Working in Windows
> ---
>
> Key: CAMEL-15543
> URL: https://issues.apache.org/jira/browse/CAMEL-15543
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.24.1
> Environment: Windows 10, JDK 11
>Reporter: Sreejesh
>Priority: Major
>
> I have a simple route where I write some string to an output file and then 
> trying to append the contents of the original file. But it ignores and it 
> overwrites the file.
>  
> *from("file://inputFolder")*
> *.routeId("InputFolderToTestSedaRoute")
> .setProperty("myFileConsumedBody", simple("${body}"))
> .setBody(constant("FIRST LINE!"))*
> *.to("file://\{{outputFolder}}")
> .setBody(simple("${exchangeProperty.myFileConsumedBody}"))*
> *.log("*** STEP 100: ${headers} :***")*
> *.delay(1)
> .to("file://outputFolder?fileExist=Append")
> ;*
> I added delay to observe what happens.
>  # If there is an input file named myFile.txt, Camel picks that file as 
> expected.
>  # It keeps the file to an custome exchange property as in the code.
>  # It opens a file named myFile.txt and writes the content "FIRST LINE!" in 
> it and waits for the delay to expire.
>  # I can open and verify the contents, everything looks good.
>  # Once delay expires, Camel overwrites the file myFile.txt with the original 
> content it picked from input folder (even though I have asked Camel to 
> append).
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15543) Apache Camel File Append Not Working in Windows

2020-09-17 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15543.

Resolution: Duplicate

This is fixed in 2.24.3. Please reopen if you have same issue in 2.24.3, 3.0.0, 
2.25.0 or later.

> Apache Camel File Append Not Working in Windows
> ---
>
> Key: CAMEL-15543
> URL: https://issues.apache.org/jira/browse/CAMEL-15543
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.24.1
> Environment: Windows 10, JDK 11
>Reporter: Sreejesh
>Priority: Major
>
> I have a simple route where I write some string to an output file and then 
> trying to append the contents of the original file. But it ignores and it 
> overwrites the file.
>  
> *from("file://inputFolder")*
> *.routeId("InputFolderToTestSedaRoute")
> .setProperty("myFileConsumedBody", simple("${body}"))
> .setBody(constant("FIRST LINE!"))*
> *.to("file://\{{outputFolder}}")
> .setBody(simple("${exchangeProperty.myFileConsumedBody}"))*
> *.log("*** STEP 100: ${headers} :***")*
> *.delay(1)
> .to("file://outputFolder?fileExist=Append")
> ;*
> I added delay to observe what happens.
>  # If there is an input file named myFile.txt, Camel picks that file as 
> expected.
>  # It keeps the file to an custome exchange property as in the code.
>  # It opens a file named myFile.txt and writes the content "FIRST LINE!" in 
> it and waits for the delay to expire.
>  # I can open and verify the contents, everything looks good.
>  # Once delay expires, Camel overwrites the file myFile.txt with the original 
> content it picked from input folder (even though I have asked Camel to 
> append).
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15536) Github action - fail if git tree is dirty after build

2020-09-16 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15536.

Resolution: Implemented

> Github action - fail if git tree is dirty after build
> -
>
> Key: CAMEL-15536
> URL: https://issues.apache.org/jira/browse/CAMEL-15536
> Project: Camel
>  Issue Type: Task
>  Components: build system
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> People are creating PRs with changes, which will be discarded after build 
> (mainly generated adoc files) and Github action currently passes without 
> errors. It would be nice to add one step to github action, which will check 
> for uncommited changes after build and fail, if working tree is dirty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-15536) Github action - fail if git tree is dirty after build

2020-09-16 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-15536:
--

Assignee: Jan Bednar

> Github action - fail if git tree is dirty after build
> -
>
> Key: CAMEL-15536
> URL: https://issues.apache.org/jira/browse/CAMEL-15536
> Project: Camel
>  Issue Type: Task
>  Components: build system
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> People are creating PRs with changes, which will be discarded after build 
> (mainly generated adoc files) and Github action currently passes without 
> errors. It would be nice to add one step to github action, which will check 
> for uncommited changes after build and fail, if working tree is dirty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-13923) Fix incorrectly escaped simple expressions in migrated manual pages

2020-09-16 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-13923.

Fix Version/s: 3.6.0
   Resolution: Fixed

> Fix incorrectly escaped simple expressions in migrated manual pages
> ---
>
> Key: CAMEL-13923
> URL: https://issues.apache.org/jira/browse/CAMEL-13923
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>  Labels: help-wanted
> Fix For: 3.6.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> E.g. section "USING DYNAMIC URIS" in 
> [https://camel.apache.org/manual/latest/content-enricher.html], but it can be 
> seen in many pages. There is already one user, who attempted to implement 
> these backslashes into his code (CAMEL-13922).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15536) Github action - fail if git tree is dirty after build

2020-09-16 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15536:
---
Issue Type: Task  (was: New Feature)
  Priority: Minor  (was: Major)

> Github action - fail if git tree is dirty after build
> -
>
> Key: CAMEL-15536
> URL: https://issues.apache.org/jira/browse/CAMEL-15536
> Project: Camel
>  Issue Type: Task
>  Components: build system
>Reporter: Jan Bednar
>Priority: Minor
>
> People are creating PRs with changes, which will be discarded after build 
> (mainly generated adoc files) and Github action currently passes without 
> errors. It would be nice to add one step to github action, which will check 
> for uncommited changes after build and fail, if working tree is dirty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15536) Github action - fail if git tree is dirty after build

2020-09-16 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15536:
--

 Summary: Github action - fail if git tree is dirty after build
 Key: CAMEL-15536
 URL: https://issues.apache.org/jira/browse/CAMEL-15536
 Project: Camel
  Issue Type: New Feature
  Components: build system
Reporter: Jan Bednar


People are creating PRs with changes, which will be discarded after build 
(mainly generated adoc files) and Github action currently passes without 
errors. It would be nice to add one step to github action, which will check for 
uncommited changes after build and fail, if working tree is dirty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15528) Project generated with camel-archetype-api-component cannot be compiled

2020-09-15 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15528:
---
Fix Version/s: 3.6.0

> Project generated with camel-archetype-api-component cannot be compiled
> ---
>
> Key: CAMEL-15528
> URL: https://issues.apache.org/jira/browse/CAMEL-15528
> Project: Camel
>  Issue Type: Bug
>  Components: camel-archetypes
>Affects Versions: 3.5.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
> Fix For: 3.6.0
>
>
> It is broken by CAMEL-15210 and CAMEL-15478 ( 
> 4df55c268b6f8755f6dafd81a4df825c902c61b5 )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15528) Project generated with camel-archetype-api-component cannot be compiled

2020-09-14 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15528.

Resolution: Fixed

> Project generated with camel-archetype-api-component cannot be compiled
> ---
>
> Key: CAMEL-15528
> URL: https://issues.apache.org/jira/browse/CAMEL-15528
> Project: Camel
>  Issue Type: Bug
>  Components: camel-archetypes
>Affects Versions: 3.5.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> It is broken by CAMEL-15210 and CAMEL-15478 ( 
> 4df55c268b6f8755f6dafd81a4df825c902c61b5 )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15527) Create integration tests for archetypes

2020-09-14 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15527.

Fix Version/s: 3.6.0
   Resolution: Implemented

Merged to master with 
[364a8ce88b24e7e21b2f11238c7defa4110da119|https://github.com/apache/camel/commit/364a8ce88b24e7e21b2f11238c7defa4110da119].
 One failing test will be fixed with CAMEL-15528

> Create integration tests for archetypes
> ---
>
> Key: CAMEL-15527
> URL: https://issues.apache.org/jira/browse/CAMEL-15527
> Project: Camel
>  Issue Type: Test
>  Components: camel-archetypes
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
> Fix For: 3.6.0
>
>
> We should make sure, the project generated with archetype can be actually 
> built to avoid regressions like:
>  # CAMEL-14234
>  # CAMEL-15525
>  # CAMEL-14142
> This can be done with +maven-archetype-plugin:integration-test+ goal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-13923) Fix incorrectly escaped simple expressions in migrated manual pages

2020-09-14 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-13923:
--

Assignee: Jan Bednar

> Fix incorrectly escaped simple expressions in migrated manual pages
> ---
>
> Key: CAMEL-13923
> URL: https://issues.apache.org/jira/browse/CAMEL-13923
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>  Labels: help-wanted
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> E.g. section "USING DYNAMIC URIS" in 
> [https://camel.apache.org/manual/latest/content-enricher.html], but it can be 
> seen in many pages. There is already one user, who attempted to implement 
> these backslashes into his code (CAMEL-13922).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-13923) Fix incorrectly escaped simple expressions in migrated manual pages

2020-09-13 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-13923:
---
Description: E.g. section "USING DYNAMIC URIS" in 
[https://camel.apache.org/manual/latest/content-enricher.html], but it can be 
seen in many pages. There is already one user, who attempted to implement these 
backslashes into his code (CAMEL-13922).  (was: E.g. section "USING DYNAMIC 
URIS" in [https://camel.apache.org/manual/latest/content-enricher.html], but it 
can be seen in many pages. There is already one user, which attempted to 
implement these backslashes into his code (CAMEL-13922).)

How it is going [~Menekam]?

> Fix incorrectly escaped simple expressions in migrated manual pages
> ---
>
> Key: CAMEL-13923
> URL: https://issues.apache.org/jira/browse/CAMEL-13923
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Jan Bednar
>Priority: Major
>  Labels: help-wanted
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> E.g. section "USING DYNAMIC URIS" in 
> [https://camel.apache.org/manual/latest/content-enricher.html], but it can be 
> seen in many pages. There is already one user, who attempted to implement 
> these backslashes into his code (CAMEL-13922).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-15504) Support alternative JNDI locations for TransactionManager

2020-09-12 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-15504:
--

Assignee: Jan Bednar

> Support alternative JNDI locations for TransactionManager
> -
>
> Key: CAMEL-15504
> URL: https://issues.apache.org/jira/browse/CAMEL-15504
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> Eg. Payara AS exports TransactionManager at JNDI.
> {code:java}
> java:appserver/TransactionManager
> {code}
> In Camel CDI is currently hardcoded JNDI
> {code:java}
> java:/TransactionManager
> {code}
> See 
> [https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]
> Current solution is to remap this with web.xml, it would be nice to find way 
> to make this configurable directly in Apache Camel.
>  
> 
> Alternate approach can be similar to Spring, which tries to resolve 
> TransactionManager from following JNDI names - 
> [https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
> {code:java}
> public static final String DEFAULT_USER_TRANSACTION_NAME = 
> "java:comp/UserTransaction";
> public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = 
> new String[] {"java:comp/TransactionManager", 
> "java:appserver/TransactionManager",  
> "java:pm/TransactionManager", "java:/TransactionManager"};
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15528) Project generated with camel-archetype-api-component cannot be compiled

2020-09-12 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15528:
---
Description: It is broken by CAMEL-15210 and CAMEL-15478 ( 
4df55c268b6f8755f6dafd81a4df825c902c61b5 )  (was: It is broken by CAMEL-15210 
and CAMEL-15478)

> Project generated with camel-archetype-api-component cannot be compiled
> ---
>
> Key: CAMEL-15528
> URL: https://issues.apache.org/jira/browse/CAMEL-15528
> Project: Camel
>  Issue Type: Bug
>  Components: camel-archetypes
>Affects Versions: 3.5.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> It is broken by CAMEL-15210 and CAMEL-15478 ( 
> 4df55c268b6f8755f6dafd81a4df825c902c61b5 )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15528) Project generated with camel-archetype-api-component cannot be compiled

2020-09-12 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15528:
--

 Summary: Project generated with camel-archetype-api-component 
cannot be compiled
 Key: CAMEL-15528
 URL: https://issues.apache.org/jira/browse/CAMEL-15528
 Project: Camel
  Issue Type: Bug
  Components: camel-archetypes
Affects Versions: 3.5.0
Reporter: Jan Bednar
Assignee: Jan Bednar


It is broken by CAMEL-15210 and CAMEL-15478



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15527) Create integration tests for archetypes

2020-09-12 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15527:
--

 Summary: Create integration tests for archetypes
 Key: CAMEL-15527
 URL: https://issues.apache.org/jira/browse/CAMEL-15527
 Project: Camel
  Issue Type: Test
  Components: camel-archetypes
Reporter: Jan Bednar
Assignee: Jan Bednar


We should make sure, the project generated with archetype can be actually built 
to avoid regressions like:
 # CAMEL-14234
 # CAMEL-15525
 # CAMEL-14142

This can be done with +maven-archetype-plugin:integration-test+ goal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work started] (CAMEL-15527) Create integration tests for archetypes

2020-09-12 Thread Jan Bednar (Jira)


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

Work on CAMEL-15527 started by Jan Bednar.
--
> Create integration tests for archetypes
> ---
>
> Key: CAMEL-15527
> URL: https://issues.apache.org/jira/browse/CAMEL-15527
> Project: Camel
>  Issue Type: Test
>  Components: camel-archetypes
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> We should make sure, the project generated with archetype can be actually 
> built to avoid regressions like:
>  # CAMEL-14234
>  # CAMEL-15525
>  # CAMEL-14142
> This can be done with +maven-archetype-plugin:integration-test+ goal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15504) Support alternative JNDI locations for TransactionManager

2020-09-06 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15504:
---
Description: 
Eg. Payara AS exports TransactionManager at JNDI.
{code:java}
java:appserver/TransactionManager
{code}
In Camel CDI is currently hardcoded JNDI
{code:java}
java:/TransactionManager
{code}
See 
[https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]

Current solution is to remap this with web.xml, it would be nice to find way to 
make this configurable directly in Apache Camel.

 

Alternate approach can be similar to Spring, which tries to resolve 
TransactionManager from following JNDI names - 
[https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
{code:java}
public static final String DEFAULT_USER_TRANSACTION_NAME = 
"java:comp/UserTransaction";
public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES =   
new String[] {"java:comp/TransactionManager", 
"java:appserver/TransactionManager",  
"java:pm/TransactionManager", "java:/TransactionManager"};
{code}
 

  was:
Eg. Payara AS exports TransactionManager at JNDI.
{code:java}
java:appserver/TransactionManager
{code}
In Camel CDI is currently hardcoded JNDI
{code:java}
java:/TransactionManager
{code}
See 
[https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]

Current solution is to remap this with web.xml, it would be nice to find way to 
make this configurable directly in Apache Camel.

 

Alternate approach can be similar to Spring, which tries to resolve 
TransactionManager from following JNDI names - 
[https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
{code:java}
public static final String DEFAULT_USER_TRANSACTION_NAME = 
"java:comp/UserTransaction";
public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES =   
new String[] {"java:comp/TransactionManager", 
"java:appserver/TransactionManager",  
"java:pm/TransactionManager", "java:/TransactionManager"};
{code}
 

Summary: Support alternative JNDI locations for TransactionManager  
(was: Make TransactionManager JNDI name configurable)

> Support alternative JNDI locations for TransactionManager
> -
>
> Key: CAMEL-15504
> URL: https://issues.apache.org/jira/browse/CAMEL-15504
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Reporter: Jan Bednar
>Priority: Minor
>
> Eg. Payara AS exports TransactionManager at JNDI.
> {code:java}
> java:appserver/TransactionManager
> {code}
> In Camel CDI is currently hardcoded JNDI
> {code:java}
> java:/TransactionManager
> {code}
> See 
> [https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]
> Current solution is to remap this with web.xml, it would be nice to find way 
> to make this configurable directly in Apache Camel.
>  
> 
> Alternate approach can be similar to Spring, which tries to resolve 
> TransactionManager from following JNDI names - 
> [https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
> {code:java}
> public static final String DEFAULT_USER_TRANSACTION_NAME = 
> "java:comp/UserTransaction";
> public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = 
> new String[] {"java:comp/TransactionManager", 
> "java:appserver/TransactionManager",  
> "java:pm/TransactionManager", "java:/TransactionManager"};
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15504) Make TransactionManager JNDI name configurable

2020-09-06 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-15504:
---
Description: 
Eg. Payara AS exports TransactionManager at JNDI.
{code:java}
java:appserver/TransactionManager
{code}
In Camel CDI is currently hardcoded JNDI
{code:java}
java:/TransactionManager
{code}
See 
[https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]

Current solution is to remap this with web.xml, it would be nice to find way to 
make this configurable directly in Apache Camel.

 

Alternate approach can be similar to Spring, which tries to resolve 
TransactionManager from following JNDI names - 
[https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
{code:java}
public static final String DEFAULT_USER_TRANSACTION_NAME = 
"java:comp/UserTransaction";
public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES =   
new String[] {"java:comp/TransactionManager", 
"java:appserver/TransactionManager",  
"java:pm/TransactionManager", "java:/TransactionManager"};
{code}
 

  was:
Eg. Payara AS exports TransactionManager at JNDI.
{code:java}
java:appserver/TransactionManager
{code}
In Camel CDI is currently hardcoded JNDI
{code:java}
java:/TransactionManager
{code}
See 
[https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]

Current solution is to remap this with web.xml, it would be nice to find way to 
make this configurable directly in Apache Camel.


> Make TransactionManager JNDI name configurable
> --
>
> Key: CAMEL-15504
> URL: https://issues.apache.org/jira/browse/CAMEL-15504
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Reporter: Jan Bednar
>Priority: Minor
>
> Eg. Payara AS exports TransactionManager at JNDI.
> {code:java}
> java:appserver/TransactionManager
> {code}
> In Camel CDI is currently hardcoded JNDI
> {code:java}
> java:/TransactionManager
> {code}
> See 
> [https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]
> Current solution is to remap this with web.xml, it would be nice to find way 
> to make this configurable directly in Apache Camel.
>  
> 
> Alternate approach can be similar to Spring, which tries to resolve 
> TransactionManager from following JNDI names - 
> [https://github.com/spring-projects/spring-framework/blob/master/spring-tx/src/main/java/org/springframework/transaction/jta/JtaTransactionManager.java]
> {code:java}
>   public static final String DEFAULT_USER_TRANSACTION_NAME = 
> "java:comp/UserTransaction";
>   public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES =   
> new String[] {"java:comp/TransactionManager", 
> "java:appserver/TransactionManager",  
> "java:pm/TransactionManager", "java:/TransactionManager"};
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15504) Make TransactionManager JNDI name configurable

2020-09-06 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15504:
--

 Summary: Make TransactionManager JNDI name configurable
 Key: CAMEL-15504
 URL: https://issues.apache.org/jira/browse/CAMEL-15504
 Project: Camel
  Issue Type: Improvement
  Components: camel-cdi
Reporter: Jan Bednar


Eg. Payara AS exports TransactionManager at JNDI.
{code:java}
java:appserver/TransactionManager
{code}
In Camel CDI is currently hardcoded JNDI
{code:java}
java:/TransactionManager
{code}
See 
[https://stackoverflow.com/questions/55353883/apache-camel-in-payara-lookup-failed-for-java-transactionmanager]

Current solution is to remap this with web.xml, it would be nice to find way to 
make this configurable directly in Apache Camel.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15420) camel-http dynamic aware removes Exchange.HTTP_QUERY header if Exchange.HTTP_PATH header not specified

2020-08-23 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15420:


2.24.x is EOL and there is no planned release for this branch. You can open 
backport PR against branch camel-2.25.x if it helps you.

> camel-http dynamic aware removes Exchange.HTTP_QUERY header if 
> Exchange.HTTP_PATH header not specified
> --
>
> Key: CAMEL-15420
> URL: https://issues.apache.org/jira/browse/CAMEL-15420
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common
>Affects Versions: 2.24.3, 3.4.3
>Reporter: Artem St
>Priority: Minor
> Fix For: 3.5.0, 3.4.4
>
> Attachments: HttpSendDynamicAwareHeadersTest.java
>
>
> If http path specified in endpoint uri instead of Exchange.HTTP_PATH header 
> than dynamic aware ignores Exchange.HTTP_QUERY and set it as null.
> Sending message to route
> {code:java}
> from("direct:dynamicAware")
>  .setHeader(Exchange.HTTP_PATH, constant("dynamicAware"))
>  .setHeader(Exchange.HTTP_QUERY, constant("par1=val1&par2=val2"))
>  .toD("http://localhost:"; + localServer.getLocalPort());{code}
> will return exchange with getIn().getHeader(Exchange.HTTP_QUERY) equal to 
> "par1=val1&par2=val2".
> But, sending message to route 
> {code:java}
> from("direct:dynamicAwareWithoutPathHeader")
>  .setHeader(Exchange.HTTP_QUERY, constant("par1=val1&par2=val2"))
>  .toD("http://localhost:"; + localServer.getLocalPort() + 
> "/dynamicAware");{code}
> removes header Exchange.HTTP_QUERY from result.
>  
> Here is full code of test: (also attached as a .java file)
> {code:java}
> public class HttpSendDynamicAwareHeadersTest extends BaseHttpTest {
>  private HttpServer localServer;
>  @BeforeEach
>  @Override
>  public void setUp() throws Exception {
>  localServer = ServerBootstrap.bootstrap().
>  setHttpProcessor(getBasicHttpProcessor()).
>  setConnectionReuseStrategy(getConnectionReuseStrategy()).
>  setResponseFactory(getHttpResponseFactory()).
>  setExpectationVerifier(getHttpExpectationVerifier()).
>  setSslContext(getSSLContext()).
>  registerHandler("/dynamicAware", new BasicValidationHandler(GET.name(), 
> null, null, null)).
>  create();
>  localServer.start();
>  super.setUp();
>  }
>  @AfterEach
>  @Override
>  public void tearDown() throws Exception {
>  super.tearDown();
>  if (localServer != null) {
>  localServer.stop();
>  }
>  }
>  @Override
>  protected RoutesBuilder createRouteBuilder() throws Exception {
>  return new RouteBuilder() {
>  @Override
>  public void configure() throws Exception {
>  from("direct:dynamicAware")
>  .setHeader(Exchange.HTTP_PATH, constant("dynamicAware"))
>  .setHeader(Exchange.HTTP_QUERY, constant("par1=val1&par2=val2"))
>  .toD("http://localhost:"; + localServer.getLocalPort());
>  from("direct:dynamicAwareWithoutPathHeader")
>  .setHeader(Exchange.HTTP_QUERY, constant("par1=val1&par2=val2"))
>  .toD("http://localhost:"; + localServer.getLocalPort() + "/dynamicAware");
>  }
>  };
>  }
>  @Test
>  public void testDynamicAwareHeaders() throws Exception {
>  Exchange e = fluentTemplate.to("direct:dynamicAware").send();
>  assertNotNull(e.getIn().getHeader(Exchange.HTTP_QUERY));
>  e = fluentTemplate.to("direct:dynamicAwareWithoutPathHeader").send();
>  assertNotNull(e.getIn().getHeader(Exchange.HTTP_QUERY));
>  }
> }{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-10173) Create a camel component for etcd v3

2020-07-26 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-10173 at 7/26/20, 8:51 PM:
--

Hi. Small part is being implemented in 
[https://github.com/apache/camel/pull/3983] . I would suggest to wait until it 
is merged and continue from there.


was (Author: bedla):
Hi. Small part is beeing implemented in 
[https://github.com/apache/camel/pull/3983] . I would suggest to wait until it 
is merged and continue from there.

> Create a camel component for etcd v3
> 
>
> Key: CAMEL-10173
> URL: https://issues.apache.org/jira/browse/CAMEL-10173
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Priority: Minor
>  Labels: gsoc2020
> Fix For: Future
>
>
> See https://github.com/coreos/jetcd



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-10173) Create a camel component for etcd v3

2020-07-26 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-10173:


Hi. Small part is beeing implemented in 
[https://github.com/apache/camel/pull/3983] . I would suggest to wait until it 
is merged and continue from there.

> Create a camel component for etcd v3
> 
>
> Key: CAMEL-10173
> URL: https://issues.apache.org/jira/browse/CAMEL-10173
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Priority: Minor
>  Labels: gsoc2020
> Fix For: Future
>
>
> See https://github.com/coreos/jetcd



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (CAMEL-14237) camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in Spring Boot

2020-07-25 Thread Jan Bednar (Jira)


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

Jan Bednar closed CAMEL-14237.
--
Fix Version/s: 3.4.0
   Resolution: Done

Great! Thanks for testing with actual versions. Seems this is indeed fixed in 
Apache Camel 3.4.0 with SB upgraded to 2.3.0 by CAMEL-15069

> camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in 
> Spring Boot
> --
>
> Key: CAMEL-14237
> URL: https://issues.apache.org/jira/browse/CAMEL-14237
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0.RC1, 3.0.0.RC2, 3.0.0.RC3, 3.0.0
>Reporter: Jan Bednar
>Priority: Minor
> Fix For: 3.4.0
>
>
> All write operations fails with 
> {noformat}
> org.elasticsearch.action.ActionRequestValidationException: Validation Failed: 
> 1: type is missing;{noformat}
> The issue here is we have upgraded dependencies to 7.3.2 to support elastic 7 
> (indexType was removed in Elastic 7), but somehow starter is packaged with 
> 6.8.4 dependencies, so the request validation fails. Not sure how this could 
> happen, all poms seems to be fine
> Using plain camel-elasticsearch-rest dependency instead of starter does not 
> help, because elasticsearch.client versions are somewhere overriden (probably 
> by camel-spring-boot-dependencies)
> The only way I was able to make this component work was by overriding elastic 
> dependency versions in my pom ( 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
>  ):
>  
> {noformat}
> 
>org.elasticsearch
>elasticsearch
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-high-level-client
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-client
>7.3.2
>  {noformat}
> Reproducer project can be found here 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
> Remove workaround in pom.xml on lines 75-88 and 91-105 to see this bug in 
> action.
> *mvn dependency:tree* on current camel master shows this:
> {code:java}
> maven-dependency-plugin:3.1.1:tree (default-cli) @ 
> camel-elasticsearch-rest-starter ---
>  
> org.apache.camel.springboot:camel-elasticsearch-rest-starter:jar:3.1.0-SNAPSHOT
>   
>   
> +- org.springframework.boot:spring-boot-starter:jar:2.2.1.RELEASE:compile 
>   
>
> |  +- 
> org.springframework.boot:spring-boot-starter-logging:jar:2.2.1.RELEASE:compile
>   
>  
> |  |  +- ch.qos.logback:logback-classic:jar:1.2.3:compile 
>   
>
> |  |  |  \- ch.qos.logback:logback-core:jar:1.2.3:compile 
>   
>
> |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.12.1:compile   
>   
>
> |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile 
>   
>
> |  |  \- org.slf4j:jul-to-slf4j:jar:1.7.29:compile
>   
>
> |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile 
>   
>
> |  +- org.springframework:spring-core:jar:5.2.1.RELEASE:compile   
>   
>
> |  |  \- org.springframework:spring-jcl:jar:5.2.1.RELEASE:compile 
>   
>
> |  \- org.yaml:snakeyaml:jar:1.25:compile 
>  

[jira] [Resolved] (CAMEL-15284) Fix Maven build on Windows

2020-07-09 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15284.

Fix Version/s: 3.5.0
   Resolution: Done

> Fix Maven build on Windows
> --
>
> Key: CAMEL-15284
> URL: https://issues.apache.org/jira/browse/CAMEL-15284
> Project: Camel
>  Issue Type: Task
>Affects Versions: 3.4.0, 3.5.0
> Environment: Windows
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
> Fix For: 3.5.0
>
>
> Currently camel-kudu and docs build from master fails on Windows.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15113) camel-rabbitmq - Auto declare dead letter queues with custom args

2020-07-09 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15113.

Fix Version/s: (was: 3.x)
   3.5.0
   Resolution: Fixed

Added skipDlqDeclare option and extended {{args}} option with {{dlq.queue}} and 
{{dlq.binding}} prefixes.

> camel-rabbitmq - Auto declare dead letter queues with custom args
> -
>
> Key: CAMEL-15113
> URL: https://issues.apache.org/jira/browse/CAMEL-15113
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 3.3.0
>Reporter: Sourabh Tiwari
>Assignee: Jan Bednar
>Priority: Major
>  Labels: help-wanted
> Fix For: 3.5.0
>
>
> There is no support to declare dead letter queues with custom arguments. I 
> can find a TODO in RabbitMQDeclareSupport class.
> [https://github.com/apache/camel/blob/88f46b1ce46f5cdace73b2721a1cb96a290d42dd/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitMQDeclareSupport.java#L41]
>  
> My requirement is to set a TTL on messages in dead letter queue while queue 
> is declared by Camel. 
> What I have tried:
> If I create DLQ separately by camel with TTL and use that queue name in 
> original queue then I get exception that TTL value can't be different. 
> Because the declare parameter in RabbitMQEndpoint class declares both 
> original queue and dead letter queue, there is no separate option if someone 
> don't want to declare dead letter queue.
> Let me know if there is any workaround except creating queues manually.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work started] (CAMEL-15284) Fix Maven build on Windows

2020-07-08 Thread Jan Bednar (Jira)


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

Work on CAMEL-15284 started by Jan Bednar.
--
> Fix Maven build on Windows
> --
>
> Key: CAMEL-15284
> URL: https://issues.apache.org/jira/browse/CAMEL-15284
> Project: Camel
>  Issue Type: Task
>Affects Versions: 3.4.0, 3.5.0
> Environment: Windows
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> Currently camel-kudu and docs build from master fails on Windows.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15284) Fix Maven build on Windows

2020-07-08 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15284:
--

 Summary: Fix Maven build on Windows
 Key: CAMEL-15284
 URL: https://issues.apache.org/jira/browse/CAMEL-15284
 Project: Camel
  Issue Type: Task
Affects Versions: 3.4.0, 3.5.0
 Environment: Windows
Reporter: Jan Bednar
Assignee: Jan Bednar


Currently camel-kudu and docs build from master fails on Windows.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-15113) camel-rabbitmq - Auto declare dead letter queues with custom args

2020-07-07 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-15113:
--

Assignee: Jan Bednar

> camel-rabbitmq - Auto declare dead letter queues with custom args
> -
>
> Key: CAMEL-15113
> URL: https://issues.apache.org/jira/browse/CAMEL-15113
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 3.3.0
>Reporter: Sourabh Tiwari
>Assignee: Jan Bednar
>Priority: Major
>  Labels: help-wanted
> Fix For: 3.x
>
>
> There is no support to declare dead letter queues with custom arguments. I 
> can find a TODO in RabbitMQDeclareSupport class.
> [https://github.com/apache/camel/blob/88f46b1ce46f5cdace73b2721a1cb96a290d42dd/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitMQDeclareSupport.java#L41]
>  
> My requirement is to set a TTL on messages in dead letter queue while queue 
> is declared by Camel. 
> What I have tried:
> If I create DLQ separately by camel with TTL and use that queue name in 
> original queue then I get exception that TTL value can't be different. 
> Because the declare parameter in RabbitMQEndpoint class declares both 
> original queue and dead letter queue, there is no separate option if someone 
> don't want to declare dead letter queue.
> Let me know if there is any workaround except creating queues manually.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15156) org.apache.camel.component.mail.MailBinding.populateMailMessage java.lang.NullPointerException:

2020-06-07 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15156.

Resolution: Not A Bug

maven-assembly-plugin does not work well with Apache Camel because it overrides 
type converter manifests. Use maven-shade-plugin. 
[https://camel.apache.org/manual/latest/faq/how-to-create-executable-jar-camel-main.html]
 . 

> org.apache.camel.component.mail.MailBinding.populateMailMessage 
> java.lang.NullPointerException:
> ---
>
> Key: CAMEL-15156
> URL: https://issues.apache.org/jira/browse/CAMEL-15156
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mail
>Affects Versions: 3.2.0, 3.3.0
> Environment: Stacktrace
> ---
> java.lang.NullPointerException: null
>  at 
> org.apache.camel.component.mail.MailBinding.populateMailMessage(MailBinding.java:133)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:
> ?]
>  at 
> org.apache.camel.component.mail.MailProducer.process(MailProducer.java:66) 
> ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:?]
>  at 
> org.apache.camel.processor.SendDynamicProcessor.lambda$process$0(SendDynamicProcessor.java:197)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-depende
> ncies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultProducerCache.doInAsyncProducer(DefaultProducerCache.java:309)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-depe
> ndencies.jar:?]
>  at 
> org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:182)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar
> :?]
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:395)
>  [TestCamelMail-1.0-SNAPSHOT-ja
> r-with-dependencies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-d
> ependencies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-depen
> dencies.jar:?]
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) 
> [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:?]
>  at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.
> jar:?]
>  at 
> org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:198)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.ja
> r:?]
>  at 
> org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:78) 
> [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:?]
>  at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_161]
>  at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_161]
> [1) thread #2 - timer://mytimer] TimerConsumer WARN Error processing 
> exchange. Exchange[ID-DEMHAS-KA-1591558798961-0-1]. Caused by: [j
> ava.lang.NullPointerException - null]
> java.lang.NullPointerException: null
>  at 
> org.apache.camel.component.mail.MailBinding.populateMailMessage(MailBinding.java:133)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:
> ?]
>  at 
> org.apache.camel.component.mail.MailProducer.process(MailProducer.java:66) 
> ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:?]
>  at 
> org.apache.camel.processor.SendDynamicProcessor.lambda$process$0(SendDynamicProcessor.java:197)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-depende
> ncies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultProducerCache.doInAsyncProducer(DefaultProducerCache.java:309)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-depe
> ndencies.jar:?]
>  at 
> org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:182)
>  ~[TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar
> :?]
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:395)
>  ~[TestCamelMail-1.0-SNAPSHOT-j
> ar-with-dependencies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-d
> ependencies.jar:?]
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-depen
> dencies.jar:?]
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) 
> [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.jar:?]
>  at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
>  [TestCamelMail-1.0-SNAPSHOT-jar-with-dependencies.
> jar

[jira] [Closed] (CAMEL-14704) Checkstyle could also do autoformatting

2020-05-07 Thread Jan Bednar (Jira)


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

Jan Bednar closed CAMEL-14704.
--
Resolution: Duplicate

> Checkstyle could also do autoformatting
> ---
>
> Key: CAMEL-14704
> URL: https://issues.apache.org/jira/browse/CAMEL-14704
> Project: Camel
>  Issue Type: Wish
>  Components: build system
>Reporter: Kirill Yankov
>Priority: Minor
>
> I am a new contributor. And as I see in docs and after trial the checkstyle 
> command only does checking of your sources, and outputs details of where you 
> need to correct. It would be nice to have check style which does formatting 
> in project's style automatically, so that you won't need to do it manually. I 
> have used corresponding plugin in scala sbt, there must be one for maven java.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15026) Camel throws exception on HHTP response Content-Type header with additional info

2020-05-07 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-15026:


I believe this is fixed with CAMEL-12424 in 2.21.1. Can you try to upgrade?

> Camel throws exception on HHTP response Content-Type header with additional 
> info
> 
>
> Key: CAMEL-15026
> URL: https://issues.apache.org/jira/browse/CAMEL-15026
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http4
>Affects Versions: 2.21.0
>Reporter: Benny Slater
>Priority: Major
>
> Camel throws an TypeConversionException when receiving a HTTP response, where 
> the Content-Type header includes extended information, e.g. version info.
> org.apache.http.headers - [CID=879adbb4-d406-40e7-8529-5a20427157bf] - 
> http-outgoing-0 << HTTP/1.1 400 Bad Request
> org.apache.http.headers - [CID=879adbb4-d406-40e7-8529-5a20427157bf] - 
> http-outgoing-0 << *Content-Type: application/json; charset=utf-8; v=1.0*
> ...
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: java.lang.String to the required type: java.lang.String with value 
> [Body is instance of java.io.InputStream] due utf-8; v=1.0
> 
> Caused by: java.io.UnsupportedEncodingException: utf-8; v=1.0
>  at sun.nio.cs.StreamDecoder.forInputStreamReader(StreamDecoder.java:71)
> The exception throw is TypeConversionException and the response to the caller 
> of route will get a 404 error back, even though the original response code 
> was 400.
> It appears that Camel doesn't handle the ; v=1.0 part of the content-type 
> header.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (CAMEL-15014) Failure in running Camel Spring project, when generated with archetypeVersion=3.2.0

2020-05-05 Thread Jan Bednar (Jira)


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

Jan Bednar closed CAMEL-15014.
--
Resolution: Duplicate

This is already fixed. 3.3 is expected to be released by weekend. 

> Failure in running Camel Spring project, when generated with 
> archetypeVersion=3.2.0
> ---
>
> Key: CAMEL-15014
> URL: https://issues.apache.org/jira/browse/CAMEL-15014
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring
>Affects Versions: 3.2.0
> Environment: openjdk version "1.8.0_191"
> OpenJDK Runtime Environment (build 1.8.0_191-b13)
> OpenJDK 64-Bit Server VM (build 25.191-b13, mixed mode)
>Reporter: Francesco
>Priority: Major
>
> When generating a Camel Spring project with the following archetypeVersion:
> {code:java}
> mvn archetype:generate \
> -DarchetypeGroupId=org.apache.camel.archetypes \
>  -DarchetypeArtifactId=camel-archetype-spring \
>  -DarchetypeVersion=3.2.0 \
>  -DgroupId=myGroupId \
>  -DartifactId=demo{code}
> Then when I run it with:
> {code:java}
> mvn camel:run{code}
> The following error is reported:
> {code:java}
> Cannot run OSGi Blueprint Main because camel-blueprint-main JAR is not 
> available on classpath -> [Help 1]{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15001) Support Metadata#excludeProperties for component properties

2020-05-04 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-15001.

Fix Version/s: 3.3.0
   Resolution: Implemented

Implemented in 
[master@92c0295|https://github.com/apache/camel/commit/92c029529ebd8dfcbcc09c4809eb2d2d7325527b].

> Support Metadata#excludeProperties for component properties
> ---
>
> Key: CAMEL-15001
> URL: https://issues.apache.org/jira/browse/CAMEL-15001
> Project: Camel
>  Issue Type: Improvement
>  Components: tooling
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
> Fix For: 3.3.0
>
>
> Tooling should support `@Metadata(excludeProperties)` on component class.
> Eg to exclude `bridgeErrorHandler`, which is not supported on JMS and 
> ActiveMQ component, from model.
> [https://stackoverflow.com/questions/61578332/jms-components-bridge-error-handler-not-working]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15001) Support Metadata#excludeProperties for component properties

2020-05-03 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-15001:
--

 Summary: Support Metadata#excludeProperties for component 
properties
 Key: CAMEL-15001
 URL: https://issues.apache.org/jira/browse/CAMEL-15001
 Project: Camel
  Issue Type: Improvement
  Components: tooling
Reporter: Jan Bednar
Assignee: Jan Bednar


Tooling should support `@Metadata(excludeProperties)` on component class.

Eg to exclude `bridgeErrorHandler`, which is not supported on JMS and ActiveMQ 
component, from model.

[https://stackoverflow.com/questions/61578332/jms-components-bridge-error-handler-not-working]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-14999) Camel 3 log showCaughtException is not working

2020-05-02 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14999.

Regression:   (was: Regression)
Resolution: Fixed

Fixed in 
[master@ffb362e|https://github.com/apache/camel/commit/ffb362eac47541d2df07247657f8d8de8e8cf591]
 
(+[master@1ded844|https://github.com/apache/camel/commit/1ded84449802a23ab93b3dfd93812db8b83d6fc0])

> Camel 3 log showCaughtException is not working
> --
>
> Key: CAMEL-14999
> URL: https://issues.apache.org/jira/browse/CAMEL-14999
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.1.0, 3.2.0
>Reporter: Laurent Chabot
>Assignee: Jan Bednar
>Priority: Minor
> Fix For: 3.3.0
>
>
> Take this simple case:
> {code:java}
> CamelContext ctx = new DefaultCamelContext();
> ctx.addRoutes(new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> from("direct:input")
> .doTry()
> .throwException(new Exception("Something wrong"))
> .doCatch(Exception.class)
> .end()
> .to("log:error?level=WARN&showCaughtException=true");
> }
> });
> ctx.start();
> ctx.createProducerTemplate().sendBody("direct:input", null);
> {code}
> In Camel 2.x (tested with 2.24.1 and 2.25.1), we get the expected log:
> {noformat}
> 13:58:06,685 | WARN  | main | error| 
> Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null], 
> CaughtExceptionType: java.lang.Exception, CaughtExceptionMessage: Something 
> wrong]
> {noformat}
> But in Camel 3.x (tested with 3.0.0, 3.1.0 and 3.2.0), the caught exception 
> is not shown:
> {noformat}
> 13:55:19,904 | WARN  | main | error| 
> Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]
> {noformat}
> However, with {{showAll=true}}, the caught exception is correctly shown:
> {noformat}
> 13:58:41,258 | WARN  | main | error| 
> Exchange[Id: ID-EBEBRPCLDV0019-1588420721258-0-1, ExchangePattern: InOnly, 
> Properties: {CamelExceptionCaught=java.lang.Exception: Something wrong, 
> CamelToEndpoint=log://error?level=WARN&showAll=true}, Headers: {}, BodyType: 
> null, Body: [Body is null], CaughtExceptionType: java.lang.Exception, 
> CaughtExceptionMessage: Something wrong, StackTrace: java.lang.Exception: 
> Something wrong
>   at LogTest$1.configure(LogTest.java:16)
>   [...]
> {noformat}
> I went through the different migration guides but couldn't find anything 
> about this.
> This is really blocking for our Camel 3.x migration; any workaround is 
> welcome! (preferably through endpoint parameters)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-14999) Camel 3 log showCaughtException is not working

2020-05-02 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-14999:
--

Assignee: Jan Bednar

> Camel 3 log showCaughtException is not working
> --
>
> Key: CAMEL-14999
> URL: https://issues.apache.org/jira/browse/CAMEL-14999
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.1.0, 3.2.0
>Reporter: Laurent Chabot
>Assignee: Jan Bednar
>Priority: Minor
> Fix For: 3.3.0
>
>
> Take this simple case:
> {code:java}
> CamelContext ctx = new DefaultCamelContext();
> ctx.addRoutes(new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> from("direct:input")
> .doTry()
> .throwException(new Exception("Something wrong"))
> .doCatch(Exception.class)
> .end()
> .to("log:error?level=WARN&showCaughtException=true");
> }
> });
> ctx.start();
> ctx.createProducerTemplate().sendBody("direct:input", null);
> {code}
> In Camel 2.x (tested with 2.24.1 and 2.25.1), we get the expected log:
> {noformat}
> 13:58:06,685 | WARN  | main | error| 
> Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null], 
> CaughtExceptionType: java.lang.Exception, CaughtExceptionMessage: Something 
> wrong]
> {noformat}
> But in Camel 3.x (tested with 3.0.0, 3.1.0 and 3.2.0), the caught exception 
> is not shown:
> {noformat}
> 13:55:19,904 | WARN  | main | error| 
> Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]
> {noformat}
> However, with {{showAll=true}}, the caught exception is correctly shown:
> {noformat}
> 13:58:41,258 | WARN  | main | error| 
> Exchange[Id: ID-EBEBRPCLDV0019-1588420721258-0-1, ExchangePattern: InOnly, 
> Properties: {CamelExceptionCaught=java.lang.Exception: Something wrong, 
> CamelToEndpoint=log://error?level=WARN&showAll=true}, Headers: {}, BodyType: 
> null, Body: [Body is null], CaughtExceptionType: java.lang.Exception, 
> CaughtExceptionMessage: Something wrong, StackTrace: java.lang.Exception: 
> Something wrong
>   at LogTest$1.configure(LogTest.java:16)
>   [...]
> {noformat}
> I went through the different migration guides but couldn't find anything 
> about this.
> This is really blocking for our Camel 3.x migration; any workaround is 
> welcome! (preferably through endpoint parameters)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14985) camel-qute (Qute Template)

2020-04-30 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14985:


camel-quarkus already have this extension. I think this can be closed 
[~marat.gubaidul...@gmail.com].

Implementation: [https://github.com/apache/camel-quarkus/pull/878]

Discussion, why this should be part rather of camel-quarkus, instead of 
camel-components: 
[https://github.com/apache/camel/pull/3605#issuecomment-595416181]

> camel-qute (Qute Template)
> --
>
> Key: CAMEL-14985
> URL: https://issues.apache.org/jira/browse/CAMEL-14985
> Project: Camel
>  Issue Type: New Feature
>Reporter: Marat Gubaidullin
>Priority: Minor
>  Labels: component, template
>
> The Qute component allows for processing a message using a 
> [Qute|https://quarkus.io/guides/qute-reference] template. 
> This can be ideal when using Templating to generate responses for requests in 
> Camel Quarkus.
> First experiment prototype 
> [code|https://github.com/mgubaidullin/camel/blob/qute-template/components/camel-qute]
> First experiment prototype 
> [documentation|https://github.com/mgubaidullin/camel/blob/qute-template/components/camel-qute/src/main/docs/qute-component.adoc]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-14970) Implement camel-javascript component

2020-04-26 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-14970:
--

 Summary: Implement camel-javascript component
 Key: CAMEL-14970
 URL: https://issues.apache.org/jira/browse/CAMEL-14970
 Project: Camel
  Issue Type: New Feature
Reporter: Jan Bednar


camel-script is removed in 3.x with CAMEL-13113 because of Nashorn Engine 
deprecation in JDK11. We should implement camel-javascript based on some 
supported engine (possibly graaljs?).

Some users are missing Javascript language in 3.x:

[https://camel.465427.n5.nabble.com/Re-Camel-script-eip-JavaScript-deprecated-tt5857880.html]

[https://stackoverflow.com/questions/61435521/camel-3-2-and-javascript]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to

2020-02-17 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14579:


{quote}>Use a header with the dynamic recipient and a static to then there is 
only a single endpoint.

How do I do this?
{quote}
{code:java}
//...
.setHeader("from", method(UUID.class, "randomUUID"))
.to("smtp://localhost:1234?to=t...@test.com") // You dont need dynamic endpoint 
here for "mail.smtp.from", "from" header takes precedence
//...{code}

> Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
> 
>
> Key: CAMEL-14579
> URL: https://issues.apache.org/jira/browse/CAMEL-14579
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mail
>Affects Versions: 3.0.1
>Reporter: Pascal Schumacher
>Priority: Minor
> Attachments: CamelMail_DyamicTo_MemoryLeak-3.1.0-SNAPSHOT.PNG, 
> CamelMail_RecipientList_MemoryLeak_3.0.1.PNG
>
>
> In Camel 3.0.1 there seems to be a memory leak when you use camel-mail to 
> send mails with a recipient list (see attached screenshot 
> CamelMail_RecipientList_MemoryLeak_3.0.1.PNG).
> Code to reproduce:
> {code:java}
> public class SendMailDynamicToMemoryLeakTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() {
> return new RouteBuilder() {
> public void configure() {
> from("scheduler:start?delay=1")
> .setBody(constant("Hello"))
> .setHeader("smtpFrom", method(UUID.class, "randomUUID"))
> 
> .recipientList(simple("smtp://localhost:1234?to=t...@test.com&mail.smtp.from=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com&mail.smtp.from=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
> 
> com.bitmechanic
> dumbster
> 1.9.0.2
> 
> {code}
> {code:java}
> public class TestMailServer {
> public static void main(String[] args) throws Exception {
> ServerOptions serverOptions = new ServerOptions();
> serverOptions.port = 1234;
> SmtpServerFactory.startServer(serverOptions);
> }
> }
> {code}
> To make reproduction easier I pushed everything to 
> https://github.com/PascalSchumacher/CamelSendMailMemoryLeak
> Run the TestMailServer class, then run SendMailDynamicToMemoryLeakTest.
> Using Camel 3.1.0-SNAPSHOT to run the test shows the same behavior.
> Using Camel 2.24.2 there is no memory leak.
> ---
> The original code is using toD (see commented out code in the test case 
> above) instead of a recipient list. For dynamic to there seems to be a slower 
> memory leak in Camel 3.0.1 (not completely sure, a lot of objects get garbage 
> collected, but overall object count seems to slowly increase.)
> Using Camel 2.24.2 there is no memory leak.
> Using Camel 3.1.0-SNAPSHOT with dynamic to there seems to be a memory leak, 
> see the attached screenshot CamelMail_DyamicTo_MemoryLeak-3.1.0-SNAPSHOT.PNG.
> I am not sure if the recipientList/toD behavior is limited to camel-mail or 
> if it would occur for other components too. I could not replicate the 
> behavior with camel-http, but this component uses optimized dynamic to and 
> this may prevent the occurrence of a memory leak.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-14369) Camel Syslog Consumer doesn't handle syslog message from netcat/python client

2020-01-07 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14369.

Resolution: Not A Bug

Your netcat test is invalid - You are sending some random string, but you need 
to follow syslog message format.

Camel Syslog Dataformat can handle either RFC-3164 or RFC-5424 compliant 
messages (this is documented), but python handler does not follow none of 
these. _logging.handlers.SysLogHandler_ uses timestamp format specified in 
RFC-5424, but excludes version, which is in RFC-5424 required. Because missing 
version field, Camel assumes it is RFC-3164 message and fails to decode 
timestamp.


 In python, you can use some RFC compliant logger - eg 
[https://github.com/jobec/rfc5424-logging-handler]

If you need to stick with _logging.handlers.SysLogHandler_, the 
[camel-grok|https://camel.apache.org/components/latest/grok-dataformat.html] 
should work for you.
{code:java}
.unmarshal().grok("%{SYSLOGLINE}"){code}

> Camel Syslog Consumer doesn't handle syslog message from netcat/python client
> -
>
> Key: CAMEL-14369
> URL: https://issues.apache.org/jira/browse/CAMEL-14369
> Project: Camel
>  Issue Type: Bug
>  Components: camel-syslog
>Affects Versions: 3.0.0
>Reporter: imran raza khan
>Priority: Major
>
> I developed syslog server in camel like below
>
> {code:java}
>  from("netty:udp://127.0.0.1:514?sync=false&allowDefaultCodec=false")
> .routeId("sysloglistener").routeGroup("sysloglistener-group")
> .unmarshal().syslog()
> .to("log:DEBUG?showBody=true&showHeaders=true");
> {code}
> I tested with simple netcat command and it throws error
>
> {code:java}
>  echo "Test syslog message from Netcat" | nc -w1 -u 127.0.0.1 514
> {code}
> **Error Trace:**
> 
> {code:java}
> 2020-01-06 23:27:08.756 DEBUG 2772 --- [ntExecutorGroup] 
> o.a.c.i.engine.DefaultReactiveExecutor   : Queuing reactive work: 
> Step[ID-imrans-MBP-1578349622523-0-5,DefaultErrorHandler[Unmarshal[org.apache.camel.component.syslog.SyslogDataFormat@270d43a7]]]
> 2020-01-06 23:27:08.757 DEBUG 2772 --- [ntExecutorGroup] 
> o.a.c.i.engine.DefaultReactiveExecutor   : Queuing reactive work: 
> CamelInternalProcessor - UnitOfWork - afterProcess - 
> DefaultErrorHandler[Unmarshal[org.apache.camel.component.syslog.SyslogDataFormat@270d43a7]]
>  - ID-imrans-MBP-1578349622523-0-5
> 2020-01-06 23:27:08.757 DEBUG 2772 --- [ntExecutorGroup] 
> o.a.c.i.engine.DefaultReactiveExecutor   : Queuing reactive work: 
> Step[ID-imrans-MBP-1578349622523-0-5,DefaultErrorHandler[Unmarshal[org.apache.camel.component.syslog.SyslogDataFormat@270d43a7]]]
> 2020-01-06 23:27:08.757 DEBUG 2772 --- [ntExecutorGroup] 
> o.a.c.i.engine.DefaultReactiveExecutor   : Queuing reactive work: 
> Callback[org.apache.camel.processor.CamelInternalProcessor$$Lambda$1103/433074890@3c888d6f]
> 2020-01-06 23:27:08.761 ERROR 2772 --- [ntExecutorGroup] 
> o.a.c.p.e.DefaultErrorHandler: Failed delivery for (MessageId: 
> ID-imrans-MBP-1578349622523-0-6 on ExchangeId: 
> ID-imrans-MBP-1578349622523-0-5). Exhausted after delivery attempt: 1 caught: 
> java.nio.BufferUnderflowException
> 
> Message History
> 
> ---
> RouteId  ProcessorId  Processor   
>  Elapsed (ms)
> [sysloglistener] [sysloglistener] 
> [from[netty://udp://127.0.0.1:514?allowDefaultCodec=false&sync=false] 
>  ] [ 2]
> [sysloglistener] [unmarshal1] 
> [unmarshal[org.apache.camel.model.dataformat.SyslogDataFormat@7ec1effa]   
>  ] [ 0]
> 
> Stacktrace
> 
> ---
> 
> java.nio.BufferUnderflowException: null
>   at java.nio.Buffer.nextGetIndex(Buffer.java:500) ~[na:1.8.0_121]
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135) ~[na:1.8.0_121]
>   at 
> org.apache.camel.component.syslog.SyslogConverter.parseMessage(SyslogConverter.java:147)
>  ~[camel-syslog-3.0.0.jar:3.0.0]
>   at 
> org.apache.camel.component.syslog.SyslogDataFormat.unmarshal(SyslogDataFormat.java:47)
>  ~[camel-syslog-3.0.0.jar:3.0.0]
>   at 
> org.apache.camel.support.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:62)
>  ~[camel-support-3.0.0.jar:3.0.0]
>   at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryState.run(RedeliveryErrorHandler.java:476)
>  ~[camel-base-3.0.0.jar:3.0.0]
>   at 
> org.apache.camel.impl.engi

[jira] [Comment Edited] (CAMEL-14299) camel-sql - Dynamic producer (toD) problem

2019-12-23 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-14299 at 12/23/19 8:52 PM:
--

[~davsclaus] I also dont see any direct introspection in code, but it is 
happening. After increasing logging level with property 
*bean-introspection-logging-level: info* then right before the exception is 
logged.
{code:java}
Invoked: 203 times (overall) [Method: setProperty, Target: HikariDataSource 
(HikariPool-1), Arguments: [dataSource, HikariDataSource (HikariPool-1)]]
{code}
To see the exception you need to comment out the timer route in the reproducer 
code. Full log with logged introspection is here [^CAMEL-14299.log]

 

[~Gurpal2000] Another workaround you can use in the meantime is to warmup sql 
component. Call 
{code:java}
getContext().getComponent("sql");
{code}
on the beginning of configure method in RouteBuilder 


was (Author: bedla):
I also dont see any direct introspection in code, but it is happening. After 
increasing logging level with property *bean-introspection-logging-level: info* 
then right before the exception is logged.
{code:java}
Invoked: 203 times (overall) [Method: setProperty, Target: HikariDataSource 
(HikariPool-1), Arguments: [dataSource, HikariDataSource (HikariPool-1)]]
{code}
To see the exception you need to comment out the timer route in the reproducer 
code. Full log with logged introspection is here [^CAMEL-14299.log]

> camel-sql - Dynamic producer (toD) problem
> --
>
> Key: CAMEL-14299
> URL: https://issues.apache.org/jira/browse/CAMEL-14299
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.0.0
>Reporter: Gurpal2000
>Priority: Minor
> Fix For: 3.1.0
>
> Attachments: CAMEL-14299.log, log.txt
>
>
> Spring Boot: 2.2.1
> Camel: 3.0.0
> *Works* using "to()"
>  
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .to("sql:insert into gbtemp (col1, col2) values (:#val1, 
> :#val2)?dataSource=#dataSource");
> {code}
> Does *not work* using ".toD()"
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .setHeader("insertSql", constant("insert into gbtemp (col1, col2) values 
> (:#val1, :#val2)"))
> .toD("sql:${header.insertSql}?dataSource=#dataSource");
> {code}
> This used to work fine under Camel 2.x
> Example error lines:
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create 
> component: sql
> Caused by: org.apache.camel.PropertyBindingException: Error binding 
> properties on bean: org.apache.camel.component.sql.SqlComponent@a72b3b2
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
> sql://insert...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14299) camel-sql - Dynamic producer (toD) problem

2019-12-23 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14299:


I also dont see any direct introspection in code, but it is happening. After 
increasing logging level with property *bean-introspection-logging-level: info* 
then right before the exception is logged.
{code:java}
Invoked: 203 times (overall) [Method: setProperty, Target: HikariDataSource 
(HikariPool-1), Arguments: [dataSource, HikariDataSource (HikariPool-1)]]
{code}
To see the exception you need to comment out the timer route in the reproducer 
code. Full log with logged introspection is here [^CAMEL-14299.log]

> camel-sql - Dynamic producer (toD) problem
> --
>
> Key: CAMEL-14299
> URL: https://issues.apache.org/jira/browse/CAMEL-14299
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.0.0
>Reporter: Gurpal2000
>Priority: Minor
> Fix For: 3.1.0
>
> Attachments: CAMEL-14299.log, log.txt
>
>
> Spring Boot: 2.2.1
> Camel: 3.0.0
> *Works* using "to()"
>  
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .to("sql:insert into gbtemp (col1, col2) values (:#val1, 
> :#val2)?dataSource=#dataSource");
> {code}
> Does *not work* using ".toD()"
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .setHeader("insertSql", constant("insert into gbtemp (col1, col2) values 
> (:#val1, :#val2)"))
> .toD("sql:${header.insertSql}?dataSource=#dataSource");
> {code}
> This used to work fine under Camel 2.x
> Example error lines:
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create 
> component: sql
> Caused by: org.apache.camel.PropertyBindingException: Error binding 
> properties on bean: org.apache.camel.component.sql.SqlComponent@a72b3b2
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
> sql://insert...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-14299) camel-sql - Dynamic producer (toD) problem

2019-12-23 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-14299:
---
Attachment: CAMEL-14299.log

> camel-sql - Dynamic producer (toD) problem
> --
>
> Key: CAMEL-14299
> URL: https://issues.apache.org/jira/browse/CAMEL-14299
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.0.0
>Reporter: Gurpal2000
>Priority: Minor
> Fix For: 3.1.0
>
> Attachments: CAMEL-14299.log, log.txt
>
>
> Spring Boot: 2.2.1
> Camel: 3.0.0
> *Works* using "to()"
>  
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .to("sql:insert into gbtemp (col1, col2) values (:#val1, 
> :#val2)?dataSource=#dataSource");
> {code}
> Does *not work* using ".toD()"
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .setHeader("insertSql", constant("insert into gbtemp (col1, col2) values 
> (:#val1, :#val2)"))
> .toD("sql:${header.insertSql}?dataSource=#dataSource");
> {code}
> This used to work fine under Camel 2.x
> Example error lines:
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create 
> component: sql
> Caused by: org.apache.camel.PropertyBindingException: Error binding 
> properties on bean: org.apache.camel.component.sql.SqlComponent@a72b3b2
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
> sql://insert...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-14299) camel-sql - Dynamic producer (toD) problem

2019-12-22 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-14299 at 12/22/19 10:16 PM:
---

I can reproduce this with your code. The datasource is auto configured with 
spring boot. During this initialization there are some calls to openConnection, 
which causes HikariConfig to seal. Then comes in place Camel Introspection 
trying to set DataSource to HikariConfig object, which is already sealed and 
cannot be modified (fails with exception *{{The configuration of the pool is 
sealed once started. Use HikariConfigMXBean for runtime changes.}}*).

Until we find solution, you can use one of these workarounds:

Replace *toD* with *to* and *CamelSqlQuery* header
{code:java}
  .setHeader("insertSql", constant("insert into tmp (col1, col2) values 
(:?val1, :?val2)")) //Notice ? instead of #
  .setHeader("CamelSqlQuery", header("insertSql"))
  .to("sql:insert?dataSource=#dataSource")
{code}
OR downgrade hikari in your pom to lower version , where sealing mechanism was 
not implemented
{code:java}

  com.zaxxer
  HikariCP
  2.7.4

{code}


was (Author: bedla):
I can reproduce this with your code. The datasource is auto configured with 
spring boot. During this initialization there are some calls to openConnection, 
which causes HikariConfig to seal. Then comes in place Camel Introspection 
trying to set DataSource to HikariConfig object, which is already sealed and 
cannot be modified.

Until we find solution, you can use one of these workarounds:

Replace *toD* with *to* and *CamelSqlQuery* header
{code:java}
  .setHeader("insertSql", constant("insert into tmp (col1, col2) values 
(:?val1, :?val2)")) //Notice ? instead of #
  .setHeader("CamelSqlQuery", header("insertSql"))
  .to("sql:insert?dataSource=#dataSource")
{code}
OR downgrade hikari in your pom to lower version , where sealing mechanism was 
not implemented
{code:java}

  com.zaxxer
  HikariCP
  2.7.4

{code}

> camel-sql - Dynamic producer (toD) problem
> --
>
> Key: CAMEL-14299
> URL: https://issues.apache.org/jira/browse/CAMEL-14299
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.0.0
>Reporter: Gurpal2000
>Priority: Minor
> Fix For: 3.0.1, 3.1.0
>
> Attachments: log.txt
>
>
> Spring Boot: 2.2.1
> Camel: 3.0.0
> *Works* using "to()"
>  
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .to("sql:insert into gbtemp (col1, col2) values (:#val1, 
> :#val2)?dataSource=#dataSource");
> {code}
> Does *not work* using ".toD()"
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .setHeader("insertSql", constant("insert into gbtemp (col1, col2) values 
> (:#val1, :#val2)"))
> .toD("sql:${header.insertSql}?dataSource=#dataSource");
> {code}
> This used to work fine under Camel 2.x
> Example error lines:
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create 
> component: sql
> Caused by: org.apache.camel.PropertyBindingException: Error binding 
> properties on bean: org.apache.camel.component.sql.SqlComponent@a72b3b2
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
> sql://insert...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14299) camel-sql - Dynamic producer (toD) problem

2019-12-22 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14299:


I can reproduce this with your code. The datasource is auto configured with 
spring boot. During this initialization there are some calls to openConnection, 
which causes HikariConfig to seal. Then comes in place Camel Introspection 
trying to set DataSource to HikariConfig object, which is already sealed and 
cannot be modified.

Until we find solution, you can use one of these workarounds:

Replace *toD* with *to* and *CamelSqlQuery* header
{code:java}
  .setHeader("insertSql", constant("insert into tmp (col1, col2) values 
(:?val1, :?val2)")) //Notice ? instead of #
  .setHeader("CamelSqlQuery", header("insertSql"))
  .to("sql:insert?dataSource=#dataSource")
{code}
OR downgrade hikari in your pom to lower version , where sealing mechanism was 
not implemented
{code:java}

  com.zaxxer
  HikariCP
  2.7.4

{code}

> camel-sql - Dynamic producer (toD) problem
> --
>
> Key: CAMEL-14299
> URL: https://issues.apache.org/jira/browse/CAMEL-14299
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.0.0
>Reporter: Gurpal2000
>Priority: Minor
> Fix For: 3.0.1, 3.1.0
>
> Attachments: log.txt
>
>
> Spring Boot: 2.2.1
> Camel: 3.0.0
> *Works* using "to()"
>  
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .to("sql:insert into gbtemp (col1, col2) values (:#val1, 
> :#val2)?dataSource=#dataSource");
> {code}
> Does *not work* using ".toD()"
> {code:java}
> from("file://d:/tmp/?fileName=test&noop=true")
> .setHeader("val1", constant(1))
> .setHeader("val2", constant("yo"))
> .setHeader("insertSql", constant("insert into gbtemp (col1, col2) values 
> (:#val1, :#val2)"))
> .toD("sql:${header.insertSql}?dataSource=#dataSource");
> {code}
> This used to work fine under Camel 2.x
> Example error lines:
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create 
> component: sql
> Caused by: org.apache.camel.PropertyBindingException: Error binding 
> properties on bean: org.apache.camel.component.sql.SqlComponent@a72b3b2
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: 
> sql://insert...
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-14291) Salesforce component uses wrong order of received messages

2019-12-11 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14291.

Resolution: Not A Bug

The order of events is not guaranteed - 
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_message_order.htm]

If you expect events sorted by createdDate, you need to sort it yourself (Eg 
with [Resequence 
EIP|https://camel.apache.org/manual/latest/resequence-eip.html])

> Salesforce component uses wrong order of received messages
> --
>
> Key: CAMEL-14291
> URL: https://issues.apache.org/jira/browse/CAMEL-14291
> Project: Camel
>  Issue Type: Bug
>  Components: camel-salesforce
>Affects Versions: 3.0.0.RC3
>Reporter: Andrey Tyurin
>Priority: Major
>
> When several events are received from Salesforce they are processed in wrong 
> order for createdDate field:
>  
> 2019-12-11 14:01:40.751 [SalesforceHttpClient@4eac29e0-142] DEBUG 
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5 
> - Received messages 
> [{data={event={createdDate={color:#ff}2019-12-11T22:01:40.258Z{color}, 
> replayId=15230, type=deleted}, sobject=\\{Id=0JRf403pfDYGAY}}, 
> channel=/topic/ExtRoutPsr}, 
> {data={event={createdDate={color:#ff}2019-12-11T22:01:40.073Z{color}, 
> replayId=10779, type=updated}, sobject=\\{Status=3, IsDeleted=false, 
> UserId=005f401gXxkAAE, ServiceChannelId=0N9f400M9YjCAK, 
> DeclineReason=null, WorkItemId=500f40NOxKNAA1, Id=0Bzf405akscCAA, 
> PendingServiceRoutingId=0JRf403pfDYGAY}}, 
> channel=/topic/ExtRoutAgentWork}, \\{channel=/meta/connect, id=29, 
> successful=true}]
> {color:#ff}2019-12-11 14:01:40.751{color} 
> [SalesforceHttpClient@4eac29e0-142] DEBUG 
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper - 
> Received Message: 
> {data={event={createdDate={color:#ff}2019-12-11T22:01:40.258Z{color}, 
> replayId=15230, type=deleted}, sobject=\{Id=0JRf403pfDYGAY}}, 
> channel=/topic/ExtRoutPsr}
> {color:#ff}2019-12-11 14:01:40.752{color} 
> [SalesforceHttpClient@4eac29e0-142] DEBUG 
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper - 
> Received Message: 
> {data={event={createdDate={color:#ff}2019-12-11T22:01:40.073Z,{color} 
> replayId=10779, type=updated}, sobject=\{Status=3, IsDeleted=false, 
> UserId=005f401gXxkAAE, ServiceChannelId=0N9f400M9YjCAK, 
> DeclineReason=null, WorkItemId=500f40NOxKNAA1, Id=0Bzf405akscCAA, 
> PendingServiceRoutingId=0JRf403pfDYGAY}}, channel=/topic/ExtRoutAgentWork}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-14269) ConsumerTemplate not finding DefaultComponent

2019-12-06 Thread Jan Bednar (Jira)


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

Jan Bednar edited comment on CAMEL-14269 at 12/6/19 8:08 PM:
-

Definitely, You cannot mix different versions of camel dependencies. Old 
camel-aws have been splitted into more specialized dependencies per service. 
See migration guide regarding aws migration 
[https://camel.apache.org/manual/latest/camel-3-migration-guide.html#_aws]


was (Author: bedla):
Definitely, You cannot mix different versions of camel dependencies. Old 
camel-aws have been splitted into more specialized components per service. See 
migration guide regarding aws migration 
[https://camel.apache.org/manual/latest/camel-3-migration-guide.html#_aws]

> ConsumerTemplate not finding DefaultComponent
> -
>
> Key: CAMEL-14269
> URL: https://issues.apache.org/jira/browse/CAMEL-14269
> Project: Camel
>  Issue Type: Bug
>  Components: came-core
>Affects Versions: 3.0.0
>Reporter: brian yang
>Priority: Major
>
> I have updated my project to use camel 3.0.0
> The following code gives me error
> ConsumerTemplate consumer = exchange.getContext().createConsumerTemplate();
> consumer.receive(s3Endpoint);
> throws exception java.lang.ClassNotFoundException: 
> org.apache.camel.impl.DefaultComponent
>  
> however, based on documentation all org.apache.camel.impl should be moved to 
> org.apache.camel.support . so consumer.receive(s3Endpoint); should look at 
> org.apache.camel.support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14269) ConsumerTemplate not finding DefaultComponent

2019-12-06 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14269:


Definitely, You cannot mix different versions of camel dependencies. Old 
camel-aws have been splitted into more specialized components per service. See 
migration guide regarding aws migration 
[https://camel.apache.org/manual/latest/camel-3-migration-guide.html#_aws]

> ConsumerTemplate not finding DefaultComponent
> -
>
> Key: CAMEL-14269
> URL: https://issues.apache.org/jira/browse/CAMEL-14269
> Project: Camel
>  Issue Type: Bug
>  Components: came-core
>Affects Versions: 3.0.0
>Reporter: brian yang
>Priority: Major
>
> I have updated my project to use camel 3.0.0
> The following code gives me error
> ConsumerTemplate consumer = exchange.getContext().createConsumerTemplate();
> consumer.receive(s3Endpoint);
> throws exception java.lang.ClassNotFoundException: 
> org.apache.camel.impl.DefaultComponent
>  
> however, based on documentation all org.apache.camel.impl should be moved to 
> org.apache.camel.support . so consumer.receive(s3Endpoint); should look at 
> org.apache.camel.support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-14269) ConsumerTemplate not finding DefaultComponent

2019-12-06 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14269.

Resolution: Invalid

You need to check your camel dependencies and validate you have upgraded all of 
them. You have most probably dependency to 2.x somewhere. Try with mvn 
dependency:tree and validate all camel-* dependencies have the same version. We 
have many passing tests for ConsumerTemplate, so this is probably on your side. 
If this does not help, please come to mailing list or gitter, share your 
pom.xml and details about your environment, we will help you there 
[https://camel.apache.org/community/support/]

> ConsumerTemplate not finding DefaultComponent
> -
>
> Key: CAMEL-14269
> URL: https://issues.apache.org/jira/browse/CAMEL-14269
> Project: Camel
>  Issue Type: Bug
>  Components: came-core
>Affects Versions: 3.0.0
>Reporter: brian yang
>Priority: Major
>
> I have updated my project to use camel 3.0.0
> The following code gives me error
> ConsumerTemplate consumer = exchange.getContext().createConsumerTemplate();
> consumer.receive(s3Endpoint);
> throws exception java.lang.ClassNotFoundException: 
> org.apache.camel.impl.DefaultComponent
>  
> however, based on documentation all org.apache.camel.impl should be moved to 
> org.apache.camel.support . so consumer.receive(s3Endpoint); should look at 
> org.apache.camel.support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14242) camel-rabbitmq - Binding parameters with x- is not possible

2019-12-03 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14242:


For integration tests you need to start local instance of rabbitmq, there is 
docker image ready for this, see readme ( 
https://github.com/apache/camel/blob/master/components/camel-rabbitmq/readme.txt
 ). While looking into this, you might be interested in 
[RabbitMQDeclareSupport#formatSpecialQueueArguments|https://github.com/apache/camel/blob/master/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitMQDeclareSupport.java#L76]
 which handles the conversion of x-max-priority from String to Integer and 
debug, why the conversion is not happening in your case.

> camel-rabbitmq - Binding parameters with x- is not possible
> ---
>
> Key: CAMEL-14242
> URL: https://issues.apache.org/jira/browse/CAMEL-14242
> Project: Camel
>  Issue Type: Bug
>  Components: camel-rabbitmq
>Affects Versions: 3.0.0
>Reporter: michael elbaz
>Priority: Minor
>
> I can' use some rabbitMq parameter eg: *x-max-priority* please provide an 
> working exemple. 
> It was before possible doing that using deprecated parameter 
> *&queueArgsConfigurer=#rabbitMqQueueArgsConfigurer*  
> {code:java}
> @Bean("rabbitMqQueueArgsConfigurer")
> public ArgsConfigurer rabbitMqQueueArgsConfigurer() {
> return map -> map.put("x-max-priority", 10);
> }
> {code}
> See this one:
> [https://stackoverflow.com/a/44651087/4271976|https://stackoverflow.com/a/44651087/4271976]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-14237) camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in Spring Boot

2019-12-03 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-14237:
--

Assignee: (was: Jan Bednar)

Unassigning from myself, because I havent found a way how to properly override 
version defined in SB BOM. Someone smarter needs to take a look at this. 
Whatever I try, it fails on dependency conflict validation in 
+org.apache.camel:bom-generator-maven-plugin+.

What we need is to somehow force into starters 7.3.2 version of 
+org.elasticsearch.client:elasticsearch-rest-client+, 
+org.elasticsearch.client:elasticsearch-rest-high-level-client+ and 
+org.elasticsearch:elasticsearch+. It is needed, because 
+camel-elasticsearch-rest+ component is not compatible with 6.8.4 version 
inherited from SB BOM.

 

> camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in 
> Spring Boot
> --
>
> Key: CAMEL-14237
> URL: https://issues.apache.org/jira/browse/CAMEL-14237
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0.RC1, 3.0.0.RC2, 3.0.0.RC3, 3.0.0
>Reporter: Jan Bednar
>Priority: Major
>
> All write operations fails with 
> {noformat}
> org.elasticsearch.action.ActionRequestValidationException: Validation Failed: 
> 1: type is missing;{noformat}
> The issue here is we have upgraded dependencies to 7.3.2 to support elastic 7 
> (indexType was removed in Elastic 7), but somehow starter is packaged with 
> 6.8.4 dependencies, so the request validation fails. Not sure how this could 
> happen, all poms seems to be fine
> Using plain camel-elasticsearch-rest dependency instead of starter does not 
> help, because elasticsearch.client versions are somewhere overriden (probably 
> by camel-spring-boot-dependencies)
> The only way I was able to make this component work was by overriding elastic 
> dependency versions in my pom ( 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
>  ):
>  
> {noformat}
> 
>org.elasticsearch
>elasticsearch
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-high-level-client
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-client
>7.3.2
>  {noformat}
> Reproducer project can be found here 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
> Remove workaround in pom.xml on lines 75-88 and 91-105 to see this bug in 
> action.
> *mvn dependency:tree* on current camel master shows this:
> {code:java}
> maven-dependency-plugin:3.1.1:tree (default-cli) @ 
> camel-elasticsearch-rest-starter ---
>  
> org.apache.camel.springboot:camel-elasticsearch-rest-starter:jar:3.1.0-SNAPSHOT
>   
>   
> +- org.springframework.boot:spring-boot-starter:jar:2.2.1.RELEASE:compile 
>   
>
> |  +- 
> org.springframework.boot:spring-boot-starter-logging:jar:2.2.1.RELEASE:compile
>   
>  
> |  |  +- ch.qos.logback:logback-classic:jar:1.2.3:compile 
>   
>
> |  |  |  \- ch.qos.logback:logback-core:jar:1.2.3:compile 
>   
>
> |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.12.1:compile   
>   
>
> |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile 
>   
>
> |  |  \- org.slf4j:jul-to-slf4j:jar:1.7.29:compile
>   
>
> |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile 
>   
>
> |  +- org.springframework:spring-core:jar:5.2.1.RELEASE:compile   
>   

[jira] [Commented] (CAMEL-14224) Camel-Websocket: The sendToAll method in the Producer is really slow

2019-12-02 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14224:


All tests (except one for hystrix) are passing on CI ( 
[https://builds.apache.org/job/Camel/job/master/1716/testReport/] ) . I was 
never able to run tests directly in Intellij, the project is simply too huge 
for IDE and it randomly fails. You need to test it with maven.

 
{code:java}
cd components/whatever
mvn clean install # build and test all in submodule
mvn clean install -Dtest=YourTestClassName # build module and run single test 
{code}
 

> Camel-Websocket: The sendToAll method in the Producer is really slow
> 
>
> Key: CAMEL-14224
> URL: https://issues.apache.org/jira/browse/CAMEL-14224
> Project: Camel
>  Issue Type: Bug
>  Components: camel-websocket
>Affects Versions: 2.24.2
> Environment: 
>Reporter: michael elbaz
>Priority: Major
> Fix For: 3.1.0
>
>
> I don't know what the idea behind but in this class 
> ([Producer|https://github.com/apache/camel/blob/master/components/camel-websocket/src/main/java/org/apache/camel/component/websocket/WebsocketProducer.java])
>  sendToAll method the Thread.sleep in the while loop make all the process 
> crazy slow just try to run this code
> {code:java}
> @Override
> public void configure() throws Exception {
> String uri = 
> "websocket://127.0.0.1:8443/test?sendToAll=true&sendTimeout=0";
> from(uri).to(uri);
> }
> {code}
> and send multiple message to the server and you will see how slow is it for 
> my point there is two defect:
> # Give the availability to send to all *expect* the sender
> # Fix the while loop
> During my test to have decent performance i set this parameter `sendTimeout` 
> to 0 but i got this exception then: 
> {code:java}
> org.apache.camel.component.websocket.WebsocketSendException: Failed to 
> deliver message within 0 millis to one or more recipients.. 
> Exchange[ID-DESKTOP-S8PM2C4-1574865248397-0-3]
>   at 
> org.apache.camel.component.websocket.WebsocketProducer.sendToAll(WebsocketProducer.java:149)
>  ~[camel-websocket-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.component.websocket.WebsocketProducer.process(WebsocketProducer.java:52)
>  ~[camel-websocket-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>  ~[camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148) 
> [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148) 
> [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  [camel-core-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.component.websocket.WebsocketConsumer.sendMessage(WebsocketConsumer.java:75)
>  [camel-websocket-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.component.websocket.WebsocketConsumer.sendMessage(WebsocketConsumer.java:59)
>  [camel-websocket-2.24.2.jar:2.24.2]
>   at 
> org.apache.camel.component.websocket.DefaultWebsocket.onMessage(DefaultWebsocket.java:66)
>  [camel-websocket-2.24.2.jar:2.24.2]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_201]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_201]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_201]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_201]
>   at 
> org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70)
>  [websocket-common-9.4.22.v20191022.jar:9.4.22.v20191022]
>   at 
> org.eclipse.jetty.websocket.common.events

[jira] [Assigned] (CAMEL-14237) camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in Spring Boot

2019-12-02 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-14237:
--

Assignee: Jan Bednar

Closer look reveals the version is overriden from 
org.springframework.boot:spring-boot-dependencies pom import.

> camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in 
> Spring Boot
> --
>
> Key: CAMEL-14237
> URL: https://issues.apache.org/jira/browse/CAMEL-14237
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0.RC1, 3.0.0.RC2, 3.0.0.RC3, 3.0.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> All write operations fails with 
> {noformat}
> org.elasticsearch.action.ActionRequestValidationException: Validation Failed: 
> 1: type is missing;{noformat}
> The issue here is we have upgraded dependencies to 7.3.2 to support elastic 7 
> (indexType was removed in Elastic 7), but somehow starter is packaged with 
> 6.8.4 dependencies, so the request validation fails. Not sure how this could 
> happen, all poms seems to be fine
> Using plain camel-elasticsearch-rest dependency instead of starter does not 
> help, because elasticsearch.client versions are somewhere overriden (probably 
> by camel-spring-boot-dependencies)
> The only way I was able to make this component work was by overriding elastic 
> dependency versions in my pom ( 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
>  ):
>  
> {noformat}
> 
>org.elasticsearch
>elasticsearch
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-high-level-client
>7.3.2
>  
>  
>org.elasticsearch.client
>elasticsearch-rest-client
>7.3.2
>  {noformat}
> Reproducer project can be found here 
> [https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
> Remove workaround in pom.xml on lines 75-88 and 91-105 to see this bug in 
> action.
> *mvn dependency:tree* on current camel master shows this:
> {code:java}
> maven-dependency-plugin:3.1.1:tree (default-cli) @ 
> camel-elasticsearch-rest-starter ---
>  
> org.apache.camel.springboot:camel-elasticsearch-rest-starter:jar:3.1.0-SNAPSHOT
>   
>   
> +- org.springframework.boot:spring-boot-starter:jar:2.2.1.RELEASE:compile 
>   
>
> |  +- 
> org.springframework.boot:spring-boot-starter-logging:jar:2.2.1.RELEASE:compile
>   
>  
> |  |  +- ch.qos.logback:logback-classic:jar:1.2.3:compile 
>   
>
> |  |  |  \- ch.qos.logback:logback-core:jar:1.2.3:compile 
>   
>
> |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.12.1:compile   
>   
>
> |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile 
>   
>
> |  |  \- org.slf4j:jul-to-slf4j:jar:1.7.29:compile
>   
>
> |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile 
>   
>
> |  +- org.springframework:spring-core:jar:5.2.1.RELEASE:compile   
>   
>
> |  |  \- org.springframework:spring-jcl:jar:5.2.1.RELEASE:compile 
>   
>
> |  \- org.yaml:snakeyaml:jar:1.25:compile 
>

[jira] [Created] (CAMEL-14237) camel-elasticsearch-rest: Index, BulkIndex, Bulk operations not working in Spring Boot

2019-12-01 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-14237:
--

 Summary: camel-elasticsearch-rest: Index, BulkIndex, Bulk 
operations not working in Spring Boot
 Key: CAMEL-14237
 URL: https://issues.apache.org/jira/browse/CAMEL-14237
 Project: Camel
  Issue Type: Bug
Affects Versions: 3.0.0, 3.0.0.RC3, 3.0.0.RC2, 3.0.0.RC1
Reporter: Jan Bednar


All write operations fails with 
{noformat}
org.elasticsearch.action.ActionRequestValidationException: Validation Failed: 
1: type is missing;{noformat}
The issue here is we have upgraded dependencies to 7.3.2 to support elastic 7 
(indexType was removed in Elastic 7), but somehow starter is packaged with 
6.8.4 dependencies, so the request validation fails. Not sure how this could 
happen, all poms seems to be fine

Using plain camel-elasticsearch-rest dependency instead of starter does not 
help, because elasticsearch.client versions are somewhere overriden (probably 
by camel-spring-boot-dependencies)

The only way I was able to make this component work was by overriding elastic 
dependency versions in my pom ( 
[https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]
 ):

 
{noformat}

   org.elasticsearch
   elasticsearch
   7.3.2
 
 
   org.elasticsearch.client
   elasticsearch-rest-high-level-client
   7.3.2
 
 
   org.elasticsearch.client
   elasticsearch-rest-client
   7.3.2
 {noformat}
Reproducer project can be found here 
[https://github.com/bedlaj/camel3-elastic-sb-workaround/blob/master/pom.xml#L91]

Remove workaround in pom.xml on lines 75-88 and 91-105 to see this bug in 
action.

*mvn dependency:tree* on current camel master shows this:
{code:java}
maven-dependency-plugin:3.1.1:tree (default-cli) @ 
camel-elasticsearch-rest-starter ---  
   
org.apache.camel.springboot:camel-elasticsearch-rest-starter:jar:3.1.0-SNAPSHOT 

   
+- org.springframework.boot:spring-boot-starter:jar:2.2.1.RELEASE:compile   

   
|  +- 
org.springframework.boot:spring-boot-starter-logging:jar:2.2.1.RELEASE:compile  

 
|  |  +- ch.qos.logback:logback-classic:jar:1.2.3:compile   

   
|  |  |  \- ch.qos.logback:logback-core:jar:1.2.3:compile   

   
|  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.12.1:compile 

   
|  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile   

   
|  |  \- org.slf4j:jul-to-slf4j:jar:1.7.29:compile  

   
|  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile   

   
|  +- org.springframework:spring-core:jar:5.2.1.RELEASE:compile 

   
|  |  \- org.springframework:spring-jcl:jar:5.2.1.RELEASE:compile   

   
|  \- org.yaml:snakeyaml:jar:1.25:compile   

   
+- org.apache.camel:camel-elasticsearch-rest:jar:3.1.0-SNAPSHOT:compile 

   
|  +- org.apache.camel:camel-support:jar:3.1.0-SNAPSHOT:compile 

   
|  |  +- org.apache.camel:camel-api:jar:3.1.0-SNAPSHOT:compi

[jira] [Resolved] (CAMEL-14234) Project generated with camel-archetype-spring-boot cannot be built

2019-11-29 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14234.

Fix Version/s: 3.1.0
   3.0.1
   Resolution: Fixed

> Project generated with camel-archetype-spring-boot cannot be built
> --
>
> Key: CAMEL-14234
> URL: https://issues.apache.org/jira/browse/CAMEL-14234
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
> Fix For: 3.0.1, 3.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As a workaround until new patch release users needs to replace in their 
> pom.xml
> {code:java}
> 
> 
>   org.apache.camel
>   camel-spring-boot-dependencies
>   3.0.0
>   pom
>   import
> 
> {code}
> with
> {code:java}
> 
> 
>   org.apache.camel.springboot
>   camel-spring-boot-dependencies
>   3.0.0
>   pom
>   import
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-14234) Project generated with camel-archetype-spring-boot cannot be built

2019-11-29 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-14234:
--

 Summary: Project generated with camel-archetype-spring-boot cannot 
be built
 Key: CAMEL-14234
 URL: https://issues.apache.org/jira/browse/CAMEL-14234
 Project: Camel
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Jan Bednar
Assignee: Jan Bednar


As a workaround until new patch release users needs to replace in their pom.xml
{code:java}


  org.apache.camel
  camel-spring-boot-dependencies
  3.0.0
  pom
  import

{code}
with
{code:java}


  org.apache.camel.springboot
  camel-spring-boot-dependencies
  3.0.0
  pom
  import

{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work started] (CAMEL-14234) Project generated with camel-archetype-spring-boot cannot be built

2019-11-29 Thread Jan Bednar (Jira)


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

Work on CAMEL-14234 started by Jan Bednar.
--
> Project generated with camel-archetype-spring-boot cannot be built
> --
>
> Key: CAMEL-14234
> URL: https://issues.apache.org/jira/browse/CAMEL-14234
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> As a workaround until new patch release users needs to replace in their 
> pom.xml
> {code:java}
> 
> 
>   org.apache.camel
>   camel-spring-boot-dependencies
>   3.0.0
>   pom
>   import
> 
> {code}
> with
> {code:java}
> 
> 
>   org.apache.camel.springboot
>   camel-spring-boot-dependencies
>   3.0.0
>   pom
>   import
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-14128) Include latin-ext variant of Open Sans on website

2019-11-04 Thread Jan Bednar (Jira)


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

Jan Bednar resolved CAMEL-14128.

Resolution: Fixed

> Include latin-ext variant of Open Sans on website
> -
>
> Key: CAMEL-14128
> URL: https://issues.apache.org/jira/browse/CAMEL-14128
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As discussed with Zoran few months ago in commit: 
> [https://github.com/apache/camel/commit/500b7c442ac88ce59ff6d0c56a5b607fbe3a7206#commitcomment-34820028]
>  
> In reaction to this discussion I have developed 
> [openfonts|https://github.com/bedlaj/openfonts], which is few months stable, 
> so we can switch to this dependency



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-14128) Include latin-ext variant of Open Sans on website

2019-11-03 Thread Jan Bednar (Jira)


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

Jan Bednar updated CAMEL-14128:
---
Description: 
As discussed with Zoran few months ago in commit: 
[https://github.com/apache/camel/commit/500b7c442ac88ce59ff6d0c56a5b607fbe3a7206#commitcomment-34820028]

 

In reaction to this discussion I have developed 
[openfonts|https://github.com/bedlaj/openfonts], which is few months stable, so 
we can switch to this dependency

  was:
As discussed with Zoran few months ago in commit: 
[https://github.com/apache/camel/commit/500b7c442ac88ce59ff6d0c56a5b607fbe3a7206#commitcomment-34820028]

 

In reaction to this discussion I have developed 
[openfonts|[https://github.com/bedlaj/openfonts]], which is few months stable, 
so we can switch to this dependency


> Include latin-ext variant of Open Sans on website
> -
>
> Key: CAMEL-14128
> URL: https://issues.apache.org/jira/browse/CAMEL-14128
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> As discussed with Zoran few months ago in commit: 
> [https://github.com/apache/camel/commit/500b7c442ac88ce59ff6d0c56a5b607fbe3a7206#commitcomment-34820028]
>  
> In reaction to this discussion I have developed 
> [openfonts|https://github.com/bedlaj/openfonts], which is few months stable, 
> so we can switch to this dependency



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-14128) Include latin-ext variant of Open Sans on website

2019-11-03 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-14128:
--

 Summary: Include latin-ext variant of Open Sans on website
 Key: CAMEL-14128
 URL: https://issues.apache.org/jira/browse/CAMEL-14128
 Project: Camel
  Issue Type: Improvement
  Components: website
Reporter: Jan Bednar
Assignee: Jan Bednar


As discussed with Zoran few months ago in commit: 
[https://github.com/apache/camel/commit/500b7c442ac88ce59ff6d0c56a5b607fbe3a7206#commitcomment-34820028]

 

In reaction to this discussion I have developed 
[openfonts|[https://github.com/bedlaj/openfonts]], which is few months stable, 
so we can switch to this dependency



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14110) Implement Nitrite component

2019-11-01 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14110:


I am polishing last bits. It will be PR ready this weekend, probably tomorrow.

> Implement Nitrite component
> ---
>
> Key: CAMEL-14110
> URL: https://issues.apache.org/jira/browse/CAMEL-14110
> Project: Camel
>  Issue Type: New Feature
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Major
>
> Persistent single file store embedded document DB.
> [https://github.com/dizitart/nitrite-database]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14115) InvalidPayloadException when doing GET

2019-10-30 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14115:


camel-http was deprecated many years ago. Switch to [camel-http4 component| 
https://github.com/apache/camel/blob/camel-2.23.2/components/camel-http4/src/main/docs/http4-component.adoc],
 which handles this case just fine.

> InvalidPayloadException when doing GET
> --
>
> Key: CAMEL-14115
> URL: https://issues.apache.org/jira/browse/CAMEL-14115
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http
>Affects Versions: 2.23.2
> Environment: Windows Server 2016
> Camel runs with Spring Boot
>Reporter: Henrik Karlsson
>Priority: Major
>
> When doing a GET request to a REST API with a Java object as body the request 
> fails with InvalidPayloadException:
> org.apache.camel.InvalidPayloadException: No body available of type: 
> java.io.InputStream but has value: 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7 of type: 
> se.ri.plini.coworker.svc014.entity.Event on: 
> Message[ID-sp-integrat-u1a-1572450030405-0-5]. Caused by: No type converter 
> available to convert from type: se.ri.plini.coworker.svc014.entity.Event to 
> the required type: java.io.InputStream with value 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7. 
> Exchange[ID-sp-integrat-u1a-1572450030405-0-4]. Caused by: 
> [org.apache.camel.NoTypeConversionAvailableException - No type converter 
> available to convert from type: se.ri.plini.coworker.svc014.entity.Event to 
> the required type: java.io.InputStream with value 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7]org.apache.camel.InvalidPayloadException:
>  No body available of type: java.io.InputStream but has value: 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7 of type: 
> se.ri.plini.coworker.svc014.entity.Event on: 
> Message[ID-sp-integrat-u1a-1572450030405-0-5]. Caused by: No type converter 
> available to convert from type: se.ri.plini.coworker.svc014.entity.Event to 
> the required type: java.io.InputStream with value 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7. 
> Exchange[ID-sp-integrat-u1a-1572450030405-0-4]. Caused by: 
> [org.apache.camel.NoTypeConversionAvailableException - No type converter 
> available to convert from type: se.ri.plini.coworker.svc014.entity.Event to 
> the required type: java.io.InputStream with value 
> se.ri.plini.coworker.svc014.entity.Event@38cbb5c7] at 
> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:117)
>  at 
> org.apache.camel.component.http.HttpProducer.createRequestEntity(HttpProducer.java:494)
>  at 
> org.apache.camel.component.http.HttpProducer.createMethod(HttpProducer.java:418)
>  at 
> org.apache.camel.component.http.HttpProducer.process(HttpProducer.java:99) at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>  at 
> org.apache.camel.processor.SendDynamicProcessor$1.doInAsyncProducer(SendDynamicProcessor.java:178)
>  at 
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:445) 
> at 
> org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:160)
>  at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:138) at 
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101) at 
> org.apache.camel.processor.TryProcessor.process(TryProcessor.java:113) at 
> org.apache.camel.processor.TryProcessor.process(TryProcessor.java:84) at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:138) at 
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101) at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>  at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148) 
> at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:113) at 
> org.apache.camel.processor.TryProcessor.process(TryProcessor.java:84) at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>  at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:138) at 
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101) at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(Redelive

[jira] [Created] (CAMEL-14110) Implement Nitrite component

2019-10-28 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-14110:
--

 Summary: Implement Nitrite component
 Key: CAMEL-14110
 URL: https://issues.apache.org/jira/browse/CAMEL-14110
 Project: Camel
  Issue Type: New Feature
Reporter: Jan Bednar
Assignee: Jan Bednar


Persistent single file store embedded document DB.

[https://github.com/dizitart/nitrite-database]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-13926) Add annotation to Bindy dataformat for custom column name

2019-09-30 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-13926:


DataField annotation have columnName attribute, which should work exactly this 
way, or am I missing something here?

> Add annotation to Bindy dataformat for custom column name
> -
>
> Key: CAMEL-13926
> URL: https://issues.apache.org/jira/browse/CAMEL-13926
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-bindy
>Reporter: Mikael Andersson Wigander
>Priority: Minor
> Fix For: 3.x
>
>
> Add option to name a column to be used instead of property name as in the 
> following example:
>  
>   
> {code:java}
> @CsvRecord(separator = ",") public class Order { @DataField(pos = 1) private 
> int orderNr; @Link private Client client; @DataField(pos = 5) private String 
> isinCode; @DataField(name = "Name", pos = 6) private String instrumentName; 
> @DataField(pos = 7, precision = 2) private BigDecimal amount; @DataField(pos 
> = 8) private String currency; @DataField(pos = 9, pattern = "dd-MM-") 
> private Date orderDate; }{code}
> It affects the @DataField annotation and only for marshalling to csv.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14005) HTTP Component documentation about SSL configuration is misleading

2019-09-23 Thread Jan Bednar (Jira)


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

Jan Bednar commented on CAMEL-14005:


{{HttpComponent#setSslContextParameters}} exists: 
https://static.javadoc.io/org.apache.camel/camel-http/3.0.0-RC1/org/apache/camel/component/http/HttpComponent.html#setSslContextParameters-org.apache.camel.support.jsse.SSLContextParameters-

Perhaps you are using Camel 2.x? If so, then refer this page instead 
https://camel.apache.org/components/2.x/http4-component.html

> HTTP Component documentation about SSL configuration is misleading
> --
>
> Key: CAMEL-14005
> URL: https://issues.apache.org/jira/browse/CAMEL-14005
> Project: Camel
>  Issue Type: Task
>  Components: camel-http
>Reporter: Mantas Gridinas
>Assignee: Andrea Cosentino
>Priority: Trivial
>
> HTTP component's documentation (at 
> https://camel.apache.org/components/latest/http-component.html) suggests that 
> you should use {{HttpComponent#setSslContextParameters}}, but the method does 
> not seem to exist. How do you configure SSL with HttpComponent?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-13920) Find a way to propagate base markup syntax from javadoc to website

2019-09-08 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-13920:
--

   Component/s: (was: documentation)
tooling
  Assignee: (was: Jan Bednar)
Remaining Estimate: (was: 0h)

Initial support added in PR3137. Keeping this Jira open, because in PR was 
discussion about converting HTML javadocs to Ascidoctor, which is IMHO worth to 
explore. With current solution we dont detect inline markups, e.g. links, these 
are still stripped from javadoc. Solution proposed by [~zregvart] in PR will 
allow full support, but there could be some non trivial changes in tooling.

> Find a way to propagate base markup syntax from javadoc to website
> --
>
> Key: CAMEL-13920
> URL: https://issues.apache.org/jira/browse/CAMEL-13920
> Project: Camel
>  Issue Type: Improvement
>  Components: tooling
>Reporter: Jan Bednar
>Priority: Minor
>  Time Spent: 20m
>
> HTML tags seems to be stripped out when creating json schema from javadoc. 
> Can we include some of safe tags, or replace them with markup, or find some 
> other way to propagate formating from javadoc to website?
> This can be seen specialy in [file 
> component|https://camel.apache.org/components/latest/file-component.html] for 
> readLock option. 
> [Javadoc|https://github.com/apache/camel/blob/master/components/camel-file/src/main/java/org/apache/camel/component/file/GenericFileEndpoint.java#L842]
>  for this option contains nice  list of allowed values, but on website 
> (and also in file.json) are tags excluded. This tends to description, which 
> is really hard to read on website. 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (CAMEL-13923) Fix incorrectly escaped simple expressions in migrated manual pages

2019-09-01 Thread Jan Bednar (Jira)
Jan Bednar created CAMEL-13923:
--

 Summary: Fix incorrectly escaped simple expressions in migrated 
manual pages
 Key: CAMEL-13923
 URL: https://issues.apache.org/jira/browse/CAMEL-13923
 Project: Camel
  Issue Type: Task
  Components: documentation
Reporter: Jan Bednar


E.g. section "USING DYNAMIC URIS" in 
[https://camel.apache.org/manual/latest/content-enricher.html], but it can be 
seen in many pages. There is already one user, which attempted to implement 
these backslashes into his code (CAMEL-13922).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Assigned] (CAMEL-13920) Find a way to propagate base markup syntax from javadoc to website

2019-09-01 Thread Jan Bednar (Jira)


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

Jan Bednar reassigned CAMEL-13920:
--

Assignee: Jan Bednar

Working on prototype and will open PR for discussion.

> Find a way to propagate base markup syntax from javadoc to website
> --
>
> Key: CAMEL-13920
> URL: https://issues.apache.org/jira/browse/CAMEL-13920
> Project: Camel
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> HTML tags seems to be stripped out when creating json schema from javadoc. 
> Can we include some of safe tags, or replace them with markup, or find some 
> other way to propagate formating from javadoc to website?
> This can be seen specialy in [file 
> component|https://camel.apache.org/components/latest/file-component.html] for 
> readLock option. 
> [Javadoc|https://github.com/apache/camel/blob/master/components/camel-file/src/main/java/org/apache/camel/component/file/GenericFileEndpoint.java#L842]
>  for this option contains nice  list of allowed values, but on website 
> (and also in file.json) are tags excluded. This tends to description, which 
> is really hard to read on website. 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


  1   2   3   >