[jira] [Commented] (CAMEL-11473) camel-kafka - Use unique groupId by default
[
https://issues.apache.org/jira/browse/CAMEL-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16066997#comment-16066997
]
Jyrki Ruuskanen commented on CAMEL-11473:
-
With the current camel-kafka behavior, if a user wants multiple consumers to
receive messages from a (single partition) topic, i.e. a publish-subcribe
pattern, they have to create a unique id for each consumer and set that value
as the value of the groupId parameter.
Instead, this unique id could be created by the component when groupId is not
given. This behavior is also logical: when user creates a consumer with only
the topic parameter, the expected outcome is to get all messages from that
topic. Right now, that is an error (=groupId is required).
> camel-kafka - Use unique groupId by default
> ---
>
> Key: CAMEL-11473
> URL: https://issues.apache.org/jira/browse/CAMEL-11473
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> In the spirit of providing useful defaults instead of error messages
> camel-kafka consumer should generate a unique groupId if one is not given.
> This way {{from("kafka:host:9092?topic=test")}} consumers would behave in a
> pub-sub manner, and {{from("kafka:host:9092?topic=test=something}}
> consumers would behave like, well, like consumer groups on kafka do.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11473) Use unique groupId by default
Jyrki Ruuskanen created CAMEL-11473:
---
Summary: Use unique groupId by default
Key: CAMEL-11473
URL: https://issues.apache.org/jira/browse/CAMEL-11473
Project: Camel
Issue Type: Improvement
Components: camel-kafka
Reporter: Jyrki Ruuskanen
Priority: Minor
In the spirit of providing useful defaults instead of error messages
camel-kafka consumer should generate a unique groupId if one is not given.
This way {{from("kafka:host:9092?topic=test")}} consumers would behave in a
pub-sub manner, and {{from("kafka:host:9092?topic=test=something}}
consumers would behave like, well, like consumer groups on kafka do.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-10347) Camel-scr todos and polish
Jyrki Ruuskanen created CAMEL-10347: --- Summary: Camel-scr todos and polish Key: CAMEL-10347 URL: https://issues.apache.org/jira/browse/CAMEL-10347 Project: Camel Issue Type: Improvement Components: camel-scr Reporter: Jyrki Ruuskanen Priority: Minor Visibility / access: * Make context private. Use getter. * Get rid of registry member variable. Get registry through context when needed. * Make methods that are not supposed to be overriden final. Customization: * User can customize context's registry by overriding createRegistry() methods. Returns SimpleRegistry by default. * Remove hardcoded defaults from setupCamelContext(). Corrections: * Do not explicitly create an OsgiServiceRegistry for OsgiDefaultCamelContext. The context will create one anyway and combine it with whatever createRegistry(BundleContext) returns in a CompositeRegistry. * Make camel-archetype-scr integration test run with Maven 3.3.9. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-10339) Allow date offsets and timezones with Simple language
[
https://issues.apache.org/jira/browse/CAMEL-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyrki Ruuskanen updated CAMEL-10339:
Description:
Case 1:
Customer wants us to drop the files with the following naming scheme:
prefix-.data. Wouldn't it be nice if we could just say:
{noformat}
fileName=prefix-$simple{date-with-timezone:now:UTC:MMddHHmmss}.data
{noformat}
in the producer URI?
Case 2:
Customer wants us to clean up files from a destination that are more than 24
hours old. With the File component's new filterFile feature we should be able
to say:
{noformat}
filterFile=${file:modified} < ${date:now-24h}
{noformat}
in the consumer URI and pull them off the disk.
was:
Case 1:
Customer wants us to drop the files with the following naming scheme:
prefix-.data. Wouldn't it be nice if we could just say:
{noformat}
fileName=prefix-$simple{date:now:UTC:MMddHHmmss}.data
{noformat}
in the producer URI?
Case 2:
Customer wants us to clean up files from a destination that are more than 24
hours old. With the File component's new filterFile feature we should be able
to say:
{noformat}
filterFile=${file:modified} < ${date:now-24h}
{noformat}
in the consumer URI and pull them off the disk.
> Allow date offsets and timezones with Simple language
> -
>
> Key: CAMEL-10339
> URL: https://issues.apache.org/jira/browse/CAMEL-10339
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Case 1:
> Customer wants us to drop the files with the following naming scheme:
> prefix-.data. Wouldn't it be nice if we could just say:
> {noformat}
> fileName=prefix-$simple{date-with-timezone:now:UTC:MMddHHmmss}.data
> {noformat}
> in the producer URI?
> Case 2:
> Customer wants us to clean up files from a destination that are more than 24
> hours old. With the File component's new filterFile feature we should be able
> to say:
> {noformat}
> filterFile=${file:modified} < ${date:now-24h}
> {noformat}
> in the consumer URI and pull them off the disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10339) Allow date offsets and timezones with Simple language
Jyrki Ruuskanen created CAMEL-10339:
---
Summary: Allow date offsets and timezones with Simple language
Key: CAMEL-10339
URL: https://issues.apache.org/jira/browse/CAMEL-10339
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
Case 1:
Customer wants us to drop the files with the following naming scheme:
prefix-.data. Wouldn't it be nice if we could just say:
{noformat}
fileName=prefix-$simple{date:now:UTC:MMddHHmmss}.data
{noformat}
in the producer URI?
Case 2:
Customer wants us to clean up files from a destination that are more than 24
hours old. With the File component's new filterFile feature we should be able
to say:
{noformat}
filterFile=${file:modified} < ${date:now-24h}
{noformat}
in the consumer URI and pull them off the disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10298) Unnecessary restriction on readLockTimeout with readLockMinAge
Jyrki Ruuskanen created CAMEL-10298: --- Summary: Unnecessary restriction on readLockTimeout with readLockMinAge Key: CAMEL-10298 URL: https://issues.apache.org/jira/browse/CAMEL-10298 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor When using readLockMinAge parameter in the file component, readLockTimeout is required to be larger than readLockCheckInterval + readLockMinAge. This check is unnecessary. It was originally added with the use case described in CAMEL-8421 in mind, but it just ends up limiting and complicating readLockMinAge parameter's usage for no gain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9498) Always provide a writable local registry
[ https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136343#comment-15136343 ] Jyrki Ruuskanen commented on CAMEL-9498: Claus et al, I'd really appreciate some feedback on this PR. > Always provide a writable local registry > > > Key: CAMEL-9498 > URL: https://issues.apache.org/jira/browse/CAMEL-9498 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jyrki Ruuskanen >Priority: Minor > > Many Camel components need to reference objects in CamelContext's registry as > part of their configuration (for example httpClientConfigurer for http/http4 > and restletRealm for restlet). > These objects often apply to that particular CamelContext and not others, > thus the registry holding these bits could be local instead of, say, OSGi > service registry. Using a local registry prevents the risk of conflicting > keys and spares us from devising a naming policy for even trivial stuff. > To conveniently create and add these objects, even from inside RouteBuilder's > configure method, we need write access to said registry. > CamelContext should, in my opinion, provide a local SimpleRegistry that is > always available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9498) Always provide a writable local registry
[ https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Ruuskanen updated CAMEL-9498: --- Description: Many Camel components need to reference objects in CamelContext's registry as part of their configuration (for example httpClientConfigurer for http/http4 and restletRealm for restlet). These objects often apply to that particular CamelContext and not others, thus the registry holding these bits could be local instead of, say, OSGi service registry. Using a local registry prevents the risk of conflicting keys and spares us from devising a naming policy for even trivial stuff. To conveniently create and add these objects, even from inside RouteBuilder's configure method, we need write access to said registry. CamelContext should, in my opinion, provide a local SimpleRegistry that is always available. was: Many Camel components need to reference objects in CamelContext's registry as part of their configuration (for example httpClientConfigurer for http/http4 and restletRealm for restlet). These objects often apply to that particular CamelContext and not others, thus the registry holding these bits could be local. Using a local registry prevents the risk of conflicting keys and spares us from devising a naming policy for even trivial stuff. To conveniently create and add these objects, even inside RouteBuilder's configure method, we need write access to said registry. Component/s: (was: camel-scr) camel-core > Always provide a writable local registry > > > Key: CAMEL-9498 > URL: https://issues.apache.org/jira/browse/CAMEL-9498 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jyrki Ruuskanen >Priority: Minor > > Many Camel components need to reference objects in CamelContext's registry as > part of their configuration (for example httpClientConfigurer for http/http4 > and restletRealm for restlet). > These objects often apply to that particular CamelContext and not others, > thus the registry holding these bits could be local instead of, say, OSGi > service registry. Using a local registry prevents the risk of conflicting > keys and spares us from devising a naming policy for even trivial stuff. > To conveniently create and add these objects, even from inside RouteBuilder's > configure method, we need write access to said registry. > CamelContext should, in my opinion, provide a local SimpleRegistry that is > always available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9498) Always provide a writable local registry
[
https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103213#comment-15103213
]
Jyrki Ruuskanen commented on CAMEL-9498:
If we really want to solve this for everybody in one go, the most
straightforward solution is to add {monospaced}public SimpleRegistry
getLocalRegistry();{monospaced} to a CamelContext (sub)interface. To achieve
this we just have to:
# Make sure CompositeRegistry handles nesting correctly.
# Let every implementation of this (possibly new) CamelContext interface own a
local registry of type SimpleRegistry. getLocalRegistry() just returns this
registry.
# If a registry is given in the CamelContext constructor, CamelContext's
registry will be a CompositeRegistry with its localRegistry and the given
registry. Otherwise, registry = localRegistry.
Since access to the CamelContext is pretty much ubiquitous, above changes would
solve the add/override problem for tests and everywhere else, too.
What do you think?
> Always provide a writable local registry
>
>
> Key: CAMEL-9498
> URL: https://issues.apache.org/jira/browse/CAMEL-9498
> Project: Camel
> Issue Type: Improvement
> Components: camel-scr
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Many Camel components need to reference objects in CamelContext's registry as
> part of their configuration (for example httpClientConfigurer for http/http4
> and restletRealm for restlet).
> These objects often apply to that particular CamelContext and not others,
> thus the registry holding these bits could be local. Using a local registry
> prevents the risk of conflicting keys and spares us from devising a naming
> policy for even trivial stuff.
> To conveniently create and add these objects, even inside RouteBuilder's
> configure method, we need write access to said registry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9498) Always provide a writable local registry
[
https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103213#comment-15103213
]
Jyrki Ruuskanen edited comment on CAMEL-9498 at 1/16/16 7:03 PM:
-
If we really want to solve this for everybody in one go, the most
straightforward solution is to add {{SimpleRegistry getLocalRegistry();}} to
CamelContext (sub)interface. To achieve this we just have to:
# Make sure CompositeRegistry handles nesting correctly.
# Let every implementation of this (possibly new) CamelContext interface own a
local registry of type SimpleRegistry. getLocalRegistry() just returns this
registry.
# If a registry is given in the CamelContext constructor, CamelContext's
registry will be a CompositeRegistry with its localRegistry and the given
registry. Otherwise, registry = localRegistry.
Since access to the CamelContext is pretty much ubiquitous, above changes would
solve the add/override problem for tests and everywhere else, too.
What do you think?
was (Author: yuruki):
If we really want to solve this for everybody in one go, the most
straightforward solution is to add {{public SimpleRegistry
getLocalRegistry();}} to a CamelContext (sub)interface. To achieve this we just
have to:
# Make sure CompositeRegistry handles nesting correctly.
# Let every implementation of this (possibly new) CamelContext interface own a
local registry of type SimpleRegistry. getLocalRegistry() just returns this
registry.
# If a registry is given in the CamelContext constructor, CamelContext's
registry will be a CompositeRegistry with its localRegistry and the given
registry. Otherwise, registry = localRegistry.
Since access to the CamelContext is pretty much ubiquitous, above changes would
solve the add/override problem for tests and everywhere else, too.
What do you think?
> Always provide a writable local registry
>
>
> Key: CAMEL-9498
> URL: https://issues.apache.org/jira/browse/CAMEL-9498
> Project: Camel
> Issue Type: Improvement
> Components: camel-scr
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Many Camel components need to reference objects in CamelContext's registry as
> part of their configuration (for example httpClientConfigurer for http/http4
> and restletRealm for restlet).
> These objects often apply to that particular CamelContext and not others,
> thus the registry holding these bits could be local. Using a local registry
> prevents the risk of conflicting keys and spares us from devising a naming
> policy for even trivial stuff.
> To conveniently create and add these objects, even inside RouteBuilder's
> configure method, we need write access to said registry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9498) Always provide a writable local registry
[ https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101656#comment-15101656 ] Jyrki Ruuskanen commented on CAMEL-9498: Thanks for taking a look at this case. Please note that I'm not changing the way Camel works here. AbstractCamelRunner is just a helper class for the users of camel-scr. The beauty of having a local registry always available as in the PR is that we can run the exact same concrete camel runner both with or without OSGi (plain JUnit). If using a composite registry is not OK in this case the other alternative is to let camel-scr users pick the type of registry for themselves. Similar needs have come up in CamelTestSupport, if I recall correctly. Let me know if I must change the approach. In a more general note, I firmly believe that having a local registry for stuff that is only interesting locally makes sense. It makes sure whatever you do with the registry it won't have any effect outside the intended scope. > Always provide a writable local registry > > > Key: CAMEL-9498 > URL: https://issues.apache.org/jira/browse/CAMEL-9498 > Project: Camel > Issue Type: Improvement > Components: camel-scr >Reporter: Jyrki Ruuskanen >Priority: Minor > > Many Camel components need to reference objects in CamelContext's registry as > part of their configuration (for example httpClientConfigurer for http/http4 > and restletRealm for restlet). > These objects often apply to that particular CamelContext and not others, > thus the registry holding these bits could be local. Using a local registry > prevents the risk of conflicting keys and spares us from devising a naming > policy for even trivial stuff. > To conveniently create and add these objects, even inside RouteBuilder's > configure method, we need write access to said registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9498) Always provide a writable local registry
[ https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101656#comment-15101656 ] Jyrki Ruuskanen edited comment on CAMEL-9498 at 1/15/16 11:25 AM: -- Thanks for taking a look at this case. Please note that I'm not changing the way Camel works here. AbstractCamelRunner is just a helper class for the users of camel-scr. The beauty of having a local registry always available as in the PR is that we can run the exact same concrete camel runner and routebuilders both with OSGi or without OSGi (plain JUnit). If using a composite registry is not OK in this case the other alternative is to let camel-scr users pick the type of registry for themselves. Similar needs have come up in CamelTestSupport, if I recall correctly. Let me know if I must change the approach. In a more general note, I firmly believe that having a local registry for stuff that is only interesting locally makes sense. It makes sure whatever you do with the registry it won't have any effect outside the intended scope. was (Author: yuruki): Thanks for taking a look at this case. Please note that I'm not changing the way Camel works here. AbstractCamelRunner is just a helper class for the users of camel-scr. The beauty of having a local registry always available as in the PR is that we can run the exact same concrete camel runner both with or without OSGi (plain JUnit). If using a composite registry is not OK in this case the other alternative is to let camel-scr users pick the type of registry for themselves. Similar needs have come up in CamelTestSupport, if I recall correctly. Let me know if I must change the approach. In a more general note, I firmly believe that having a local registry for stuff that is only interesting locally makes sense. It makes sure whatever you do with the registry it won't have any effect outside the intended scope. > Always provide a writable local registry > > > Key: CAMEL-9498 > URL: https://issues.apache.org/jira/browse/CAMEL-9498 > Project: Camel > Issue Type: Improvement > Components: camel-scr >Reporter: Jyrki Ruuskanen >Priority: Minor > > Many Camel components need to reference objects in CamelContext's registry as > part of their configuration (for example httpClientConfigurer for http/http4 > and restletRealm for restlet). > These objects often apply to that particular CamelContext and not others, > thus the registry holding these bits could be local. Using a local registry > prevents the risk of conflicting keys and spares us from devising a naming > policy for even trivial stuff. > To conveniently create and add these objects, even inside RouteBuilder's > configure method, we need write access to said registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9498) Always provide a writable local registry
[ https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101781#comment-15101781 ] Jyrki Ruuskanen commented on CAMEL-9498: I would like to add that the PR hardly brings confusion to users since the local registry is empty by default and only accessible through getLocalRegistry(). Essentially we are just adding out-of-the-box flexibility. Making the OSGi service registry easier to write to will be a clear improvement, but it won't help people like us who like to run complete and complex Camel contexts in JUnit and OSGi without conditional code and additional setting up. > Always provide a writable local registry > > > Key: CAMEL-9498 > URL: https://issues.apache.org/jira/browse/CAMEL-9498 > Project: Camel > Issue Type: Improvement > Components: camel-scr >Reporter: Jyrki Ruuskanen >Priority: Minor > > Many Camel components need to reference objects in CamelContext's registry as > part of their configuration (for example httpClientConfigurer for http/http4 > and restletRealm for restlet). > These objects often apply to that particular CamelContext and not others, > thus the registry holding these bits could be local. Using a local registry > prevents the risk of conflicting keys and spares us from devising a naming > policy for even trivial stuff. > To conveniently create and add these objects, even inside RouteBuilder's > configure method, we need write access to said registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9498) Always provide a writable local registry
Jyrki Ruuskanen created CAMEL-9498: -- Summary: Always provide a writable local registry Key: CAMEL-9498 URL: https://issues.apache.org/jira/browse/CAMEL-9498 Project: Camel Issue Type: Improvement Components: camel-scr Reporter: Jyrki Ruuskanen Priority: Minor Many Camel components need to reference objects in CamelContext's registry as part of their configuration (for example httpClientConfigurer for http/http4 and restletRealm for restlet). These objects often apply to that particular CamelContext and not others, thus the registry holding these bits could be local. Using a local registry prevents the risk of conflicting keys and spares us from devising a naming policy for even trivial stuff. To conveniently create and add these objects, even inside RouteBuilder's configure method, we need write access to said registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[ https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978501#comment-14978501 ] Jyrki Ruuskanen commented on CAMEL-9262: Thanks man, that is exactly what I need. I should have guessed that such a pattern has been generalized in Camel a long time ago ;) I'll take a look at the wiki if maybe the error handling section should mention the failover load balancer pattern. > stopOnSuccess in Multicast, RecipientList > - > > Key: CAMEL-9262 > URL: https://issues.apache.org/jira/browse/CAMEL-9262 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jyrki Ruuskanen >Priority: Minor > > Let's say we have an endpoint where we should send a message and if sending > fails there are a number of fallback endpoints we should try stopping after > the first successful sending (=no exception thrown during sending). > This sounds like a case for doTry..doCatch, but then we can't use > defaultErrorHander and friends. > I think it would look quite right if we could say .stopOnSuccess() or > .shortCircuit() on multicast and have it stop after the first successful send. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976610#comment-14976610
]
Jyrki Ruuskanen commented on CAMEL-9262:
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
> stopOnSuccess in Multicast, RecipientList
> -
>
> Key: CAMEL-9262
> URL: https://issues.apache.org/jira/browse/CAMEL-9262
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Let's say we have an endpoint where we should send a message and if sending
> fails there are a number of fallback endpoints we should try stopping after
> the first successful sending (=no exception thrown during sending).
> This sounds like a case for doTry..doCatch, but then we can't use
> defaultErrorHander and friends.
> I think it would look quite right if we could say .stopOnSuccess() or
> .shortCircuit() on multicast and have it stop after the first successful send.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976610#comment-14976610
]
Jyrki Ruuskanen edited comment on CAMEL-9262 at 10/27/15 4:12 PM:
--
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
I guess handled(false) can be replaced with something like:
{{.throwException(new Exception("All producers failed"))}}, but it's not quite
the same.
was (Author: yuruki):
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
> stopOnSuccess in Multicast, RecipientList
> -
>
> Key: CAMEL-9262
> URL: https://issues.apache.org/jira/browse/CAMEL-9262
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Let's say we have an endpoint where we should send a message and if sending
> fails there are a number of fallback endpoints we should try stopping after
> the first successful sending (=no exception thrown during sending).
> This sounds like a case for doTry..doCatch, but then we can't use
> defaultErrorHander and friends.
> I think it would look quite right if we could say .stopOnSuccess() or
> .shortCircuit() on multicast and have it stop after the first successful send.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
Jyrki Ruuskanen created CAMEL-9262: -- Summary: stopOnSuccess in Multicast, RecipientList Key: CAMEL-9262 URL: https://issues.apache.org/jira/browse/CAMEL-9262 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor Let's say we have an endpoint where we should send a message and if sending fails there are a number of fallback endpoints we should try stopping after the first successful sending (=no exception thrown during sending). This sounds like a case for doTry..doCatch, but then we can't use defaultErrorHander and friends. I think it would look quite right if we could say .stopOnSuccess() or .shortCircuit() on multicast and have it stop after the first successful send. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9181) Simpler, less picky ScrHelper
Jyrki Ruuskanen created CAMEL-9181: -- Summary: Simpler, less picky ScrHelper Key: CAMEL-9181 URL: https://issues.apache.org/jira/browse/CAMEL-9181 Project: Camel Issue Type: Improvement Components: camel-scr Reporter: Jyrki Ruuskanen Priority: Minor Previous ScrHelper could break when there are certain XML libraries in the classpath (e.g. XOM or Saxon). Also, it doesn't work with component description files generated by the latest org.apache.felix/maven-scr-plugin version 1.21.0 (format has changed). This is a simpler, less picky implementation using StAX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9166) Some functionality broken in Camel-8857
[ https://issues.apache.org/jira/browse/CAMEL-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908163#comment-14908163 ] Jyrki Ruuskanen commented on CAMEL-9166: Thanks man for taking a look at this. The reason I'm interested in backward compatibility and avoiding ABI changes is the fact that we are using camel-scr in production with Fuse 6.x. The ability to use the same bundles (using camel-scr) across Fuse and Camel versions (Fuse 6.1 -> 6.2 -> 6.2.1 -> 6.?) makes things simpler. I don't know how far the Camel versions will be pushed in Fuse 6.x but I would hate to see breaking changes in Fuse 6.2.1 (Camel 2.15.3?). In other words, in my opinion camel-scr ABI should not change within Camel 2.15 (as now happened with 2.15.3). In 2.16 it's fine, there are changes that could make the component better. The current starting logic is a compromise between simple/silly and complex/correct. It doesn't actually try to start the Camel context every 5th second but 5 seconds after the last CamelComponent has been registered which typically only happens once. The correct way requires us to extract a complete list of required components from the routes in the context and wait for the list to be satisfied before starting. It's not clear to me how I can get that list. > Some functionality broken in Camel-8857 > --- > > Key: CAMEL-9166 > URL: https://issues.apache.org/jira/browse/CAMEL-9166 > Project: Camel > Issue Type: Bug > Components: camel-scr >Affects Versions: 2.15.3, 2.16.0 >Reporter: Jyrki Ruuskanen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > Changes in Camel-8857 cause properties prefixing to not work for Camel > context ID. See notes in > https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. > Also, backward compatibility to 2.12.0 is removed. See note in > https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. > Camel-8857 also had ABI changes that break existing bundles (requires > rebuilding them all). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9166) Some functionality broken in Camel-8857
[ https://issues.apache.org/jira/browse/CAMEL-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Ruuskanen updated CAMEL-9166: --- Description: Changes in Camel-8857 cause properties prefixing to not work for Camel context ID. See notes in https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. Also, backward compatibility to 2.12.0 is removed. See note in https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. Camel-8857 also had ABI changes that break existing bundles (required rebuilding them all). was: Changes in Camel-8857 cause properties prefixing to not work for Camel context ID. See notes in https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. Also, backward compatibility to 2.12.0 is removed. See note in https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. > Some functionality broken in Camel-8857 > --- > > Key: CAMEL-9166 > URL: https://issues.apache.org/jira/browse/CAMEL-9166 > Project: Camel > Issue Type: Bug > Components: camel-scr >Affects Versions: 2.15.3, 2.16.0 >Reporter: Jyrki Ruuskanen > > Changes in Camel-8857 cause properties prefixing to not work for Camel > context ID. See notes in > https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. > Also, backward compatibility to 2.12.0 is removed. See note in > https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. > Camel-8857 also had ABI changes that break existing bundles (required > rebuilding them all). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9166) Some functionality broken in Camel-8857
[ https://issues.apache.org/jira/browse/CAMEL-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Ruuskanen updated CAMEL-9166: --- Description: Changes in Camel-8857 cause properties prefixing to not work for Camel context ID. See notes in https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. Also, backward compatibility to 2.12.0 is removed. See note in https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. Camel-8857 also had ABI changes that break existing bundles (requires rebuilding them all). was: Changes in Camel-8857 cause properties prefixing to not work for Camel context ID. See notes in https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. Also, backward compatibility to 2.12.0 is removed. See note in https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. Camel-8857 also had ABI changes that break existing bundles (required rebuilding them all). > Some functionality broken in Camel-8857 > --- > > Key: CAMEL-9166 > URL: https://issues.apache.org/jira/browse/CAMEL-9166 > Project: Camel > Issue Type: Bug > Components: camel-scr >Affects Versions: 2.15.3, 2.16.0 >Reporter: Jyrki Ruuskanen > > Changes in Camel-8857 cause properties prefixing to not work for Camel > context ID. See notes in > https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. > Also, backward compatibility to 2.12.0 is removed. See note in > https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. > Camel-8857 also had ABI changes that break existing bundles (requires > rebuilding them all). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9166) Some functionality broken in Camel-8857
[ https://issues.apache.org/jira/browse/CAMEL-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908383#comment-14908383 ] Jyrki Ruuskanen commented on CAMEL-9166: Okay, ignore the first paragraph. OSGi wiring by convention considers minor releases until the next point release as compatible. Should we not strive to maintain binary compatibility within point releases if possible? > Some functionality broken in Camel-8857 > --- > > Key: CAMEL-9166 > URL: https://issues.apache.org/jira/browse/CAMEL-9166 > Project: Camel > Issue Type: Bug > Components: camel-scr >Affects Versions: 2.15.3, 2.16.0 >Reporter: Jyrki Ruuskanen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > Changes in Camel-8857 cause properties prefixing to not work for Camel > context ID. See notes in > https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. > Also, backward compatibility to 2.12.0 is removed. See note in > https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. > Camel-8857 also had ABI changes that break existing bundles (requires > rebuilding them all). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9166) Some functionality broken in Camel-8857
Jyrki Ruuskanen created CAMEL-9166: -- Summary: Some functionality broken in Camel-8857 Key: CAMEL-9166 URL: https://issues.apache.org/jira/browse/CAMEL-9166 Project: Camel Issue Type: Bug Components: camel-scr Affects Versions: 2.15.3, 2.16.0 Reporter: Jyrki Ruuskanen Changes in Camel-8857 cause properties prefixing to not work for Camel context ID. See notes in https://github.com/apache/camel/commit/aa59cec696c46d4f9398ae91410998bd40fabbaa. Also, backward compatibility to 2.12.0 is removed. See note in https://github.com/apache/camel/commit/c1b33e990ae5da7ca1e0268e79acc728393fd3ae. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8594) Camel and ReactiveX/RxJava
[ https://issues.apache.org/jira/browse/CAMEL-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Ruuskanen updated CAMEL-8594: --- Description: To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, front-ends and a variety of RX extensions, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. was: To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, frontends and a variety of extensions to RX, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. Camel and ReactiveX/RxJava -- Key: CAMEL-8594 URL: https://issues.apache.org/jira/browse/CAMEL-8594 Project: Camel Issue Type: Wish Reporter: Jyrki Ruuskanen Priority: Minor To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, front-ends and a variety of RX extensions, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8594) Camel and ReactiveX/RxJava
[ https://issues.apache.org/jira/browse/CAMEL-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Ruuskanen updated CAMEL-8594: --- Description: To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, frontends and a variety of extensions to RX, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. was: To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components and a variety of extensions to RX, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. Camel and ReactiveX/RxJava -- Key: CAMEL-8594 URL: https://issues.apache.org/jira/browse/CAMEL-8594 Project: Camel Issue Type: Wish Reporter: Jyrki Ruuskanen Priority: Minor To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, frontends and a variety of extensions to RX, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8594) Camel and ReactiveX/RxJava
Jyrki Ruuskanen created CAMEL-8594: -- Summary: Camel and ReactiveX/RxJava Key: CAMEL-8594 URL: https://issues.apache.org/jira/browse/CAMEL-8594 Project: Camel Issue Type: Wish Reporter: Jyrki Ruuskanen Priority: Minor To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components and a variety of extensions to RX, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8594) Camel and ReactiveX/RxJava
[ https://issues.apache.org/jira/browse/CAMEL-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394812#comment-14394812 ] Jyrki Ruuskanen commented on CAMEL-8594: Right, could the page be under https://cwiki.apache.org/confluence/display/CAMEL/RX? Proving the concept could start with developing the camel-rx module further to see how far we can go with the current components, and CamelContext and Exchange objects. Then we'll see if RX pipeline could be an option in Camel 2, requires architecture changes which means Camel 3, or is just not feasible. Camel and ReactiveX/RxJava -- Key: CAMEL-8594 URL: https://issues.apache.org/jira/browse/CAMEL-8594 Project: Camel Issue Type: Wish Reporter: Jyrki Ruuskanen Priority: Minor To me, ReactiveX and Camel looks like a perfect match. I'm wondering if all Camel routes could in future (Camel 3?) be based on RX? Camel would bring the components, front-ends and a variety of RX extensions, and routes/pipelines would be built as ObservableExchange sequences. This arrangement could greatly benefit both projects and simplify the Camel codebase as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8443) Add properties to route via DSL and XML, expose route properties via JMX
[ https://issues.apache.org/jira/browse/CAMEL-8443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350189#comment-14350189 ] Jyrki Ruuskanen commented on CAMEL-8443: Is toString representation of the route still available on JMX? We are currently using it, and I can imagine there are others who rely on it, as well. How is the optional language parameter handled on JMX? getDescription(String lang), maybe? Add properties to route via DSL and XML, expose route properties via JMX Key: CAMEL-8443 URL: https://issues.apache.org/jira/browse/CAMEL-8443 Project: Camel Issue Type: Improvement Components: camel-core, jmx Reporter: Jyrki Ruuskanen Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.0 Allow adding arbitrary String properties to a route, with .routeProperty(name, value) in Java DSL and routeProperty name=... value=.../ in XML. Expose getProperties(), getProperty(String name) and setProperty(String name, String value) for routes in JMX. Our use case: Add documentation to route in code and show it on a graph of Camel contexts, routes and endpoints in a running system. Graph is generated from JMX data. This would be nice data to show on hawtio as well. Although in this case we might want to use an explicit documentation variable rather than a reserved property name. Route has a properties map but that's used internally. These public properties would be held in a new map: publicProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8443) Add properties to route via DSL and XML, expose route properties via JMX
[ https://issues.apache.org/jira/browse/CAMEL-8443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350108#comment-14350108 ] Jyrki Ruuskanen edited comment on CAMEL-8443 at 3/6/15 8:33 AM: Yeah, that can be used to set the description (which ends up in OptionalIdentifiedDefinition), but how do I access it through JMX? Route JMX operation getDescription() is tied to route.toString() which doesn't seem to have any connection to OptionalIdentifiedDefinition.getDescription(). was (Author: yuruki): Yeah, that can be used to set the description (which ends up in OptionalIdentifiedDefinition), but how do I access it through JMX? Route JMX operation getDescription() is tied to route.toString() which doesn't seem to have any connection to OptionalIdentifiedDefinition.getDescription(). Add properties to route via DSL and XML, expose route properties via JMX Key: CAMEL-8443 URL: https://issues.apache.org/jira/browse/CAMEL-8443 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor Allow adding arbitrary String properties to a route, with .routeProperty(name, value) in Java DSL and routeProperty name=... value=.../ in XML. Expose getProperties(), getProperty(String name) and setProperty(String name, String value) for routes in JMX. Our use case: Add documentation to route in code and show it on a graph of Camel contexts, routes and endpoints in a running system. Graph is generated from JMX data. This would be nice data to show on hawtio as well. Although in this case we might want to use an explicit documentation variable rather than a reserved property name. Route has a properties map but that's used internally. These public properties would be held in a new map: publicProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8443) Add properties to route via DSL and XML, expose route properties via JMX
[ https://issues.apache.org/jira/browse/CAMEL-8443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350108#comment-14350108 ] Jyrki Ruuskanen commented on CAMEL-8443: Yeah, that can be used to set the description (which ends up in OptionalIdentifiedDefinition), but how do I access it through JMX? Route JMX operation getDescription() is tied to route.toString() which doesn't seem to have any connection to OptionalIdentifiedDefinition.getDescription(). Add properties to route via DSL and XML, expose route properties via JMX Key: CAMEL-8443 URL: https://issues.apache.org/jira/browse/CAMEL-8443 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor Allow adding arbitrary String properties to a route, with .routeProperty(name, value) in Java DSL and routeProperty name=... value=.../ in XML. Expose getProperties(), getProperty(String name) and setProperty(String name, String value) for routes in JMX. Our use case: Add documentation to route in code and show it on a graph of Camel contexts, routes and endpoints in a running system. Graph is generated from JMX data. This would be nice data to show on hawtio as well. Although in this case we might want to use an explicit documentation variable rather than a reserved property name. Route has a properties map but that's used internally. These public properties would be held in a new map: publicProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8443) Add properties to route via DSL and XML, expose route properties via JMX
Jyrki Ruuskanen created CAMEL-8443: -- Summary: Add properties to route via DSL and XML, expose route properties via JMX Key: CAMEL-8443 URL: https://issues.apache.org/jira/browse/CAMEL-8443 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor Allow adding arbitrary String properties to a route, with .routeProperty(name, value) in Java DSL and routeProperty name=... value=.../ in XML. Expose getProperties(), getProperty(String name) and setProperty(String name, String value) for routes in JMX. Our use case: Add documentation to route in code and show it on a graph of Camel contexts, routes and endpoints in a running system. Graph is generated from JMX data. This would be nice data to show on hawtio as well. Although in this case we might want to use an explicit documentation variable rather than a reserved property name. Route has a properties map but that's used internally. These public properties would be held in a new map: publicProperties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8439) Use setAutoStartup(false) instead of skipping start()
Jyrki Ruuskanen created CAMEL-8439: -- Summary: Use setAutoStartup(false) instead of skipping start() Key: CAMEL-8439 URL: https://issues.apache.org/jira/browse/CAMEL-8439 Project: Camel Issue Type: Improvement Components: camel-scr Reporter: Jyrki Ruuskanen Priority: Minor Instead of skipping Camel context's start() when active property is false, we should call Camel context's setAutoStartup(false). This way Camel context will start without starting any of the routes, and allows us to see and control the inactive context through JMX/Jolokia/hawtio. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8421) Add minimum age option to readLock=changed
[
https://issues.apache.org/jira/browse/CAMEL-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345357#comment-14345357
]
Jyrki Ruuskanen commented on CAMEL-8421:
Returning quick won't cut it. If the file is too young we need to wait for it
to mature, not skip it. Also, super wouldn't really add anything but delay to
the process when the file is old enough.
I'll refactor this into separate strategy, and then we'll see.
The problem about the FTP readLock unit tests remains, though. Do the tests
work on your setup?
Add minimum age option to readLock=changed
--
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files
or anything like that. We want to get the latest file as soon as it's
created. Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not
to read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route
startup will take close to forever. The current readLock=changed
implementation always sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it
hits the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8421) Add minimum age option to readLock=changed
[
https://issues.apache.org/jira/browse/CAMEL-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345652#comment-14345652
]
Jyrki Ruuskanen commented on CAMEL-8421:
Well, I created a new strategy FileOlderThanExclusiveReadLockStrategy which
extends MarkerFileExclusiveReadLockStrategy. I didn't get far until it started
to look wrong, the code is just too close to
FileChangedExclusiveReadLockStrategy.
Then extending FileChangedExclusiveReadLockStrategy came to mind, but having
basically all code in one method and the fields private doesn't really give the
subclass any advantage.
So, I came back to the conclusion that it's best to just add the readLockMinAge
option to FileChangedExclusiveReadLockStrategy. I updated the PR with some
polish and more tolerance in the unit tests. Unit tests for File run fine, but
FTP test support still won't work for me (mock endpoints just won't receive
anything).
Add minimum age option to readLock=changed
--
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files
or anything like that. We want to get the latest file as soon as it's
created. Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not
to read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route
startup will take close to forever. The current readLock=changed
implementation always sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it
hits the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8421) Add minimum age option to readLock=changed
[
https://issues.apache.org/jira/browse/CAMEL-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344942#comment-14344942
]
Jyrki Ruuskanen commented on CAMEL-8421:
The unit tests for the File component worked for me, but they are based on
timing so the results might be unstable. I might have to increase the
tolerances.
FTP unit tests, on the other hand, all failed (not just mine) on two machines
(win7 and archlinux) I tried them on. So I couldn't verify the tests. I ran the
tests with camel/components/camel-ftp mvn test -Dtest=*ReadLock*. FTP test
support doesn't seem to work out of the box at the moment.
The readability might improve if this was separated into its own
readLockStrategy like readLock=minage or readLock=olderthan. What do you think?
Add minimum age option to readLock=changed
--
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files
or anything like that. We want to get the latest file as soon as it's
created. Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not
to read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route
startup will take close to forever. The current readLock=changed
implementation always sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it
hits the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8421) Add minimum age option to readLock=changed
[
https://issues.apache.org/jira/browse/CAMEL-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344942#comment-14344942
]
Jyrki Ruuskanen edited comment on CAMEL-8421 at 3/3/15 11:26 AM:
-
The unit tests for the File component worked for me, but they are based on
timing so the results might be unstable. I might have to increase the
tolerances.
FTP unit tests, on the other hand, all failed (not just mine) on two machines
(win7 and archlinux) I tried them on. So I couldn't verify the tests. I ran the
tests with camel/components/camel-ftp mvn test -Dtest=\*ReadLock\*. FTP test
support doesn't seem to work out of the box at the moment.
The readability might improve if this was separated into its own
readLockStrategy like readLock=minage or readLock=olderthan. What do you think?
was (Author: yuruki):
The unit tests for the File component worked for me, but they are based on
timing so the results might be unstable. I might have to increase the
tolerances.
FTP unit tests, on the other hand, all failed (not just mine) on two machines
(win7 and archlinux) I tried them on. So I couldn't verify the tests. I ran the
tests with camel/components/camel-ftp mvn test -Dtest=*ReadLock*. FTP test
support doesn't seem to work out of the box at the moment.
The readability might improve if this was separated into its own
readLockStrategy like readLock=minage or readLock=olderthan. What do you think?
Add minimum age option to readLock=changed
--
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files
or anything like that. We want to get the latest file as soon as it's
created. Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not
to read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route
startup will take close to forever. The current readLock=changed
implementation always sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it
hits the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8421) Add minimum age option to readLock=changed
Jyrki Ruuskanen created CAMEL-8421:
--
Summary: Add minimum age option to readLock=changed
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Priority: Minor
I'm a fan of noop=true in file consumers since I don't have to worry about how
many readers I have and where. Finally I came across a scenario where current
features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files or
anything like that. We want to get the latest file as soon as it's created.
Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not to
read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route startup
will take close to forever. The current readLock=changed implementation always
sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it hits
the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8421) Add minimum age option to readLock=changed
[
https://issues.apache.org/jira/browse/CAMEL-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyrki Ruuskanen updated CAMEL-8421:
---
Description:
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files or
anything like that. We want to get the latest file as soon as it's created.
Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not to
read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route startup
will take close to forever. The current readLock=changed implementation always
sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it hits
the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
was:
I'm a fan of noop=true in file consumers since I don't have to worry about how
many readers I have and where. Finally I came across a scenario where current
features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files or
anything like that. We want to get the latest file as soon as it's created.
Consider the following route:
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedsortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
When this route is started it will go through the files in order and get the
last one. Then it will wait for new files. This works fine as long as the
writer is not slow.
Now, we had cases of incomplete files being read and I was requested to not to
read the file before it is 10 minutes old, just in case. If I increase
readLockCheckInterval to 10 minutes getting to the latest file at route startup
will take close to forever. The current readLock=changed implementation always
sleeps for at least one readLockCheckInterval per file.
If we had readLockMinAge option to define the minimum age for the target file
the consumer could acquire readLock on the first poll and breeze through the
files until too young a file is reached.
The route below would poll a file every 500ms (default poll delay), while the
current readLock=changed would take 1500ms (default poll delay + default
readLockCheckInterval) per file. Consumer goes through the files until it hits
the end and gets the last one as soon as it becomes old enough.
{code}
from(file:somewhere/data?noop=trueinclude=.*_something[.]xmlreadLock=changedreadLockMinAge=60sortBy=file:name)
.aggregate(constant(true), new
UseLatestAggregationStrategy()).completionFromBatchConsumer()
.to(amq:topic:something);
{code}
Add minimum age option to readLock=changed
--
Key: CAMEL-8421
URL: https://issues.apache.org/jira/browse/CAMEL-8421
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-ftp
Reporter: Jyrki Ruuskanen
Priority: Minor
I'm a fan of noop=true in file consumers since it means I don't have to worry
about how many readers I have and where. But eventually I came across a
scenario where current features are not sufficient.
Let's say we have a source system which writes files with name
timestamp_something.xml, and it won't use temp files or .done marker files
or
[jira] [Commented] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
[ https://issues.apache.org/jira/browse/CAMEL-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227632#comment-14227632 ] Jyrki Ruuskanen commented on CAMEL-7997: Initial version of the user guide published at https://camel.apache.org/camel-and-scr.html. New modules: camel-scr, camel-archetype-scr --- Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: camel-scr Reporter: Jyrki Ruuskanen Fix For: 2.15.0 Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
[ https://issues.apache.org/jira/browse/CAMEL-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213878#comment-14213878 ] Jyrki Ruuskanen commented on CAMEL-7997: The pull request has been updated. New modules: camel-scr, camel-archetype-scr --- Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: camel-scr Reporter: Jyrki Ruuskanen Fix For: 2.15.0 Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
[ https://issues.apache.org/jira/browse/CAMEL-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213878#comment-14213878 ] Jyrki Ruuskanen edited comment on CAMEL-7997 at 11/16/14 7:27 AM: -- The pull request (https://github.com/apache/camel/pull/329) has been updated. was (Author: yuruki): The pull request has been updated. New modules: camel-scr, camel-archetype-scr --- Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: camel-scr Reporter: Jyrki Ruuskanen Fix For: 2.15.0 Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
Jyrki Ruuskanen created CAMEL-7997: -- Summary: New modules: camel-scr, camel-archetype-scr Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: tooling Reporter: Jyrki Ruuskanen Priority: Minor Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184138#comment-14184138
]
Jyrki Ruuskanen commented on CAMEL-7875:
If the embedded registry is empty by default and used in the lookups first it
won't cause any surprises or unwanted side-effects. If the user doesn't use the
embedded registry, everything works exactly as before.
If the user decided to put beans in the embedded registry they should know that
the bean initializations are up to them, as it is for Simple and Jndi
registries now. These beans will stay in their CamelContext's scope and won't
cause problems elsewhere.
Pretty much the only visible change required for all of this is to provide
access to a SimpleRegistry inside CamelContext with public
getEmbeddedRegistry() method. Most of the remaining functionality already
exists in [Osgi]DefaultCamelContext(new SimpleRegistry()) code path.
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Assignee: Willem Jiang
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168081#comment-14168081
]
Jyrki Ruuskanen commented on CAMEL-7875:
Fair enough. If there are that many read-only Registry implementations we
obviously can't add a write method to Registry interface.
The thought of easier write access to CamelContext's registry came to me when a
component in a route required a bean in the registry (jetty securityHandler,
restlet restletRealm and others). The go-to object in Camel is CamelContext and
I was surprised to learn there is no method for adding beans there.
OK, I thought, I'll just create the CamelContext with a SimpleRegistry and pass
it to the RouteBuilders. This worked fine until I noticed that CamelTestSupport
doesn't offer a way to create the context with a SimpleRegistry. Well, I
dropped CamelTestSupport and nowadays create the tests as plain JUnit4 tests.
Still, instead of making every framework around CamelContext (such as
CamelTestSupport) flexible enough to suit everyone CamelContext could host its
own SimpleRegistry by default which would offer write access and which would be
included in the lookups (not unlike CompositeRegistry). Its usage could be
something like:
{code}
context.getEmbeddedRegistry().put(name, bean);
{code}
What do you think?
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Assignee: Willem Jiang
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160467#comment-14160467
]
Jyrki Ruuskanen commented on CAMEL-7875:
Created a pull request here:
https://github.com/apache/camel/pull/296/files
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155142#comment-14155142
]
Jyrki Ruuskanen commented on CAMEL-7875:
I've been just thinking about the possible ways to make it easier to add
objects into CamelContext's registry from routebuilder's configure method. At
the same time I'm trying to keep my routebuilders portable so that they would
run the same in org.apache.camel.main.Main and Karaf SCR bundle.
Your approach works fine in both as long as the CamelContext is created with a
SimpleRegistry and the routebuilder knows the registry key (itself).
The change to SimpleRegistry up there in the original post is of course not
possible because it would make the registry non-empty when it's instanciated,
and that would be odd to many (including me). But the point was to guarantee
that if routebuilder knows SimpleRegistry it would also know its key.
The best solution would be to have a method for adding stuff in the Registry
interface. Is there a reason why Registry should be read-only?
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151455#comment-14151455
]
Jyrki Ruuskanen commented on CAMEL-7875:
Adding beans to registry seems to be hard also when unit testing with
CamelTestSupport where CamelContext creation is locked inside the longish
doSetUp() method.
How about just biting the bullet and adding a bind(String name, Object bean)
method to the Registry interface and every implementation? Then the user
wouldn't have to care which registry flavor CamelContext is using behind the
scenes.
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151510#comment-14151510
]
Jyrki Ruuskanen commented on CAMEL-7875:
Ended up creating a helper method as a temporary workaround:
{code}
public static T extends Registry void addToRegistry(final T registry,
final String name, final Object bean) {
Registry reg = registry;
// Unwrap PropertyPlaceholderDelegateRegistry
if (registry instanceof PropertyPlaceholderDelegateRegistry) {
reg = ((PropertyPlaceholderDelegateRegistry) reg).getRegistry();
}
if (reg instanceof CompositeRegistry) {
// getRegistryList() not available in Camel 2.12
SimpleRegistry r = new SimpleRegistry();
r.put(name, bean);
((CompositeRegistry) reg).addRegistry(r);
} else if (reg instanceof JndiRegistry) {
((JndiRegistry) reg).bind(name, bean);
} else if (reg instanceof SimpleRegistry) {
((SimpleRegistry) reg).put(name, bean);
} else {
throw new IllegalArgumentException(Couldn't add bean. Unknown
registry type: + reg.getClass());
}
if (registry.lookupByName(name) != bean) {
throw new IllegalArgumentException(Couldn't add bean. Bean not
found from the registry.);
}
}
{code}
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150985#comment-14150985
]
Jyrki Ruuskanen commented on CAMEL-7875:
Ideally, from a user's perspective, I would expect CamelContext to allow a
direct put into its registry. Something like:
getContext().getRegistry().add(thisand, that);. But given the number of
different registry combinations that is probably not very easy to implement in
a clean fashion.
And of course there is the usual way of passing the (simple)registry reference
to the extended routebuilders. In the above self-referencing method we have to
do casting, which makes me feel unsure about it.
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150985#comment-14150985
]
Jyrki Ruuskanen edited comment on CAMEL-7875 at 9/28/14 9:48 AM:
-
Ideally, from a user's perspective, I would expect CamelContext to allow a
direct put into its registry. Something like:
getContext().getRegistry().add(thisand, that);. But given the number of
different registry combinations that is probably not very easy to implement in
a clean fashion.
Of course there is the usual way of passing the registry reference to the
routebuilders, but that is not very straightforward when working with
org.apache.camel.main.Main.
was (Author: yuruki):
Ideally, from a user's perspective, I would expect CamelContext to allow a
direct put into its registry. Something like:
getContext().getRegistry().add(thisand, that);. But given the number of
different registry combinations that is probably not very easy to implement in
a clean fashion.
And of course there is the usual way of passing the (simple)registry reference
to the extended routebuilders. In the above self-referencing method we have to
do casting, which makes me feel unsure about it.
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7875) Easier write access to Camel context registry
Jyrki Ruuskanen created CAMEL-7875:
--
Summary: Easier write access to Camel context registry
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through Camel
context reference in plain Java. Some beans are only needed by a certain
endpoint and it would make sense to set the bean up with the endpoint in
routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily access
the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi or
elsewhere.
All that is needed is this change in SimpleRegistry:
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyrki Ruuskanen updated CAMEL-7875:
---
Description:
I haven't found a nice way to add beans to Camel context registry through Camel
context reference in plain Java. Some beans are only needed by a certain
endpoint and it would make sense to set the bean up with the endpoint in
routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily access
the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi or
elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
was:
I haven't found a nice way to add beans to Camel context registry through Camel
context reference in plain Java. Some beans are only needed by a certain
endpoint and it would make sense to set the bean up with the endpoint in
routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily access
the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi or
elsewhere.
All that is needed is this change in SimpleRegistry:
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
Easier write access to Camel context registry
-
Key: CAMEL-7875
URL: https://issues.apache.org/jira/browse/CAMEL-7875
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Jyrki Ruuskanen
Priority: Minor
I haven't found a nice way to add beans to Camel context registry through
Camel context reference in plain Java. Some beans are only needed by a
certain endpoint and it would make sense to set the bean up with the endpoint
in routebuilder configure method.
If we added a reference to self in SimpleRegistry we could setup the Camel
context by DefaultCamelContext(new SimpleRegistry()) or
OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
access the registry from the routebuilder with SimpleRegistry registry =
(SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
Then we can set up beans in routebuilder configure and simply add them with
registry.put. And the same routebuilder could be used in plain Java, in OSGi
or elsewhere.
All that is needed is this change in SimpleRegistry:
{code}
public static final String NAME;
static {
NAME = java.util.UUID.randomUUID().tostring();
}
public SimpleRegistry() {
put.(NAME, this);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
