[jira] [Updated] (CAMEL-15718) Camel lumberjack server component not thread safe
[
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
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
[
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
[ 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
[
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
[
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
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
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
[ 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
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
[ 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
[
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
[
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
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
[ 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
[
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
[
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
[
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
[
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
[ 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
[ 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
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
[ 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
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
[ 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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[
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
[ 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
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
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
[ 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
[
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
[
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
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
[
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
[ 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
[ 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
[
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[m [1m(default-cli)[m @
> [36mcamel-elasticsearch-rest-starter[0;1m ---[m
>
> 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
[ 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
[
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
[ 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
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
[ 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:
[ 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
[ 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
[ 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
[
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
[ 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
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
[
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
[
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)
[ 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
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[ 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
[ 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
[ 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
[
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
[
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[m [1m(default-cli)[m @
> [36mcamel-elasticsearch-rest-starter[0;1m ---[m
>
> 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
[
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
[
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[m [1m(default-cli)[m @
> [36mcamel-elasticsearch-rest-starter[0;1m ---[m
>
> 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
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[m [1m(default-cli)[m @
[36mcamel-elasticsearch-rest-starter[0;1m ---[m
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
[
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
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
[
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
[ 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
[ 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
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
[ 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
[ 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
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
[
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
[
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
[ 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
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
[ 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)
