It was quite hard for me to get confluence styling right/cleaned up.
On 14 April 2016 at 12:46, Claus Ibsen wrote:
> Hi
>
> Okay so the good thing is that the cache is only in use if you specify
> a cacheKey, so people can then easily turn on the cache by providing a
> key.
>
> I am adding compon
Hi
Okay so the good thing is that the cache is only in use if you specify
a cacheKey, so people can then easily turn on the cache by providing a
key.
I am adding component docs for the options that lacks those.
On Thu, Apr 14, 2016 at 11:57 AM, Bilgin Ibryam wrote:
> All changes sounds good t
All changes sounds good to me. I'd like it have default behaviour that
is expected by a Camel developer... like no caching and all the rest.
On 14 April 2016 at 10:06, Claus Ibsen wrote:
> Hi
>
> Okay done some improvements.
>
> I wonder if the caching should not be disabled by default. Its a bit
Hi
Okay done some improvements.
I wonder if the caching should not be disabled by default. Its a bit
annoying to have to specify a cache key for de-dups, if you are really
not using that. I am not sure I would like that enabled by default,
so I would have to disable it all the time.
Also I thin
On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen wrote:
> Hi
>
> Maybe the endpoint can be specified as both id an uri.
> Then if you want to refer to an existing by id as it does today, you
> just use ref:
>
> runEndpoint=ref:foo
> runEndpoint=direct:foo
>
> This also allows to route to seda / jms et
Hi
Maybe the endpoint can be specified as both id an uri.
Then if you want to refer to an existing by id as it does today, you
just use ref:
runEndpoint=ref:foo
runEndpoint=direct:foo
This also allows to route to seda / jms etc.
runEndpoint=seda:bar
runEndpoint=jms:queue:numbers
Though if you
While implementing the hystrix component, I had to choose whether to
use endpoint Ids or direct component for run/faillback endpoints.
I've chosen endpoints, as it allows defining any kind of endpoints
with all the options and then refer to it by its id. The downside is
that you have to add the en
Hi chaps,
I'm also not very happy with the way endpointId are part of the
hystrix URL but that was the only non-intrusive way I manged to
implement it atm. Keep in mind that we want both Java and XML dsl
solution. So if you have any ideas to make it easier to use, feel free
to work on it. I won't
There is some pros with being an endpoint configuration only, as it
can make it easy for tooling and some developers to use it (when they
are used to configure uris, and just use from -> to -> to etc). I
guess the bit unusual part is that you refer to endpoint by id's which
is not so commonly in us
On Mon, Apr 4, 2016 at 6:22 PM, Raul Kripalani wrote:
> That was my exact same thought when I took a stab at the camel-hystrix
> component myself:
> https://github.com/apache/camel/commits/feature/camel-hystrix.
>
> For me, Hystrix is not an endpoint but a mechanism to deal with failure, no
> matt
:-)
Maybe the xml dsl could have it's own namespace like cxf.
Then you can import it and declare the hystrix stuff outside of the camel
context.
Wouldn't this solve having hystrix dependencies in camel core.
Cheers
--
View this message in context:
http://camel.465427.n5.nabble.com/New-camel-h
That was my exact same thought when I took a stab at the camel-hystrix
component myself:
https://github.com/apache/camel/commits/feature/camel-hystrix.
For me, Hystrix is not an endpoint but a mechanism to deal with failure, no
matter if thrown by an endpoint, a processor, or any other element of
Hi bibryam
At first glance it looks a bit intrusive when the usual endpoints are
'wrapped' in the hystrix endpoint.
Could it be something like -> psudo code
http://camel.apache.org/schema/blueprint";>
.. other options
FYI,
I've pushed the camel-hystrix component to master.
Currently it doesn't support request collapsing and the threading
aspects needs more testing and possibly improving.
Here is a small example how the new component can be used:
https://github.com/bibryam/camel-hystrix-demo/blob/master/src/ma
Thanks Raul, I will go further and merge my implementation to master.
Before that I will see what ideas I can take from your branch.
Going forward, we may have to consdier what new versions of Java is
bringing to the table for Camel Java DSL in general anyway.
Cheers,
On 28 January 2016 at 14:12
Hi
Good to hear that you guys will pickup this and work on a
camel-hystrix component.
I agree with Bilgin that the component should be similar to how you
use all the other components using the endpoints and how they are
configured.
PS: Another cool component would be a Apache Storm component.
O
On Thu, Jan 28, 2016 at 2:20 PM, David Karlsen
wrote:
> Just a fyi. I think archaius is gone in Hystrix 1.5 (configuration is an
> interface with default imp with archaius). There is a RC out of Hystrix 1.5
>
Cool, thanks for the heads-up, David!
*Raúl Kripalani*
PMC & Committer @ Apache Ignite
Just a fyi. I think archaius is gone in Hystrix 1.5 (configuration is an
interface with default imp with archaius). There is a RC out of Hystrix 1.5
28. jan. 2016 15:12 skrev "Raul Kripalani" :
> Hey Bilgin,
>
> I agree with you. My implementation started as a experiment, to be honest.
>
> My visi
Hey Bilgin,
I agree with you. My implementation started as a experiment, to be honest.
My vision was deep and fluent integration between Camel and Hystrix, that's
why I started experimenting with a fluent DSL. To me, Hystrix is not just
an external thing to integrate in Camel, but it should play
Hi Raul,
More or less the same time you published the first email about
camel-hystrix component, I also created camel-hystrix component [1]
(it is not finished yet!). But I took the typical (boring ;-))
approach where the hystix support can be used as a regular component
through URI configuration.
20 matches
Mail list logo
