OK. I have made those changes, added some extra exception handling logic
around the JMS constructs, and merged in to camel-sjms. Pull request
coming in on CAMEL-8973.
The only thing that I decided not to do was to use the StopWatch. That
functionality is very limited relative to what I needed
On Mon, Jul 13, 2015 at 3:24 PM, Jakub Korab
wrote:
> Yeah, that makes a lot of sense. I spent some time drilling through that
> component's logic and while it would be hard to marry up the two processing
> models and their use of Synchronizations, it definitely feels like something
> that belongs
Yeah, that makes a lot of sense. I spent some time drilling through that
component's logic and while it would be hard to marry up the two
processing models and their use of Synchronizations, it definitely feels
like something that belongs in the same JAR.
What's the best way to submit this? Sh
Thanks Claus. I'll make those changes and ping back when done.
Jakub
On 13/07/15 13:10, Claus Ibsen wrote:
Hi Jakub
Looks good a few comments
The component should extend UriEndpointComponent
And the endpoint should have @UriEndpoint and other
annotations for the options. You can take look how
Hi
And I think a good home for this is camel-sjms as its only using
standard JMS api. And we can have 2 or more components in the same JAR
- we have that in others.
And it may be able to reuse some logic to populate from JMS to Camel
Message to set headers and what different JMX message types the
Hi Jakub
Looks good a few comments
The component should extend UriEndpointComponent
And the endpoint should have @UriEndpoint and other
annotations for the options. You can take look how its done elsewhere.
We use ObjectHelper.notNull for validate if a parameter is configured
or not, you can use
Hi Claus,
I have a copy of it at https://github.com/jkorab/camel-jms-batch. Feel
free to take a look.
Thanks,
Jakub
On 01/07/15 19:26, Claus Ibsen wrote:
Hi
Ah cool. Maybe you could put it on a github repo we can use to take a peek at?
As JMS is "big thing" and also can be complicated, we
Hi
Ah cool. Maybe you could put it on a github repo we can use to take a peek at?
As JMS is "big thing" and also can be complicated, we should have some
time to review and see where it fits the best in the Camel family.
On Wed, Jul 1, 2015 at 11:03 AM, Jakub Korab
wrote:
> Hi all,
>
> I have wr
Hi all,
I have written a consumer-only component that combines aggregation logic
with transacted JMS sessions that I would like to contribute. The component
vastly speeds up message consumption and aggregation without message loss
on failure when compared with using a regular JMS component and agg
