I fixed this for Camel 2.10.0. The fix is to late to go into Camel 2.9.1
because we should test it also with other JMS providers first.
I have no other issues which have to go into Camel 2.9.1.
Best,
Christian
On Mon, Feb 27, 2012 at 11:08 PM, Christian Müller <
christian.muel...@gmail.com> wrote
Ok, applied it only to trunk for Camel 2.10.0 because it's to late for
Camel 2.9.1
Best,
Christian
On Tue, Feb 28, 2012 at 9:02 AM, Claus Ibsen wrote:
> Hi
>
> Yeah the headers can most likely be copied today if the JMS brokers do
> not barf anymore.
>
> However I had hoped in the mean time we
Hi Claus-
I believe that, in general, more information available to the user via
JMX is better. Being able to confirm everything is wired up is very
valuable to users-- especially ones new to the framework. Using it to
change values is more of an operational hot-fix vs a core use case, in
m
Hi All!
In preparation for the larger task I decided to try to correct some bugs:-)
I attached a patch for CAMEL-3985 [1].
I checked the functionality empirically by sending a mail component with
three charset (UTF-8, UTF-16 and iso-8859-1) with non standard characters
(Polish and Chinese) in per
On Tue, Feb 28, 2012 at 3:35 PM, Babak Vahdat
wrote:
> Hi Claus,
>
> Would it make sense to extends the logic of:
>
> DefaultManagementLifecycleStrategy.onRoutesRemove()
>
> to also remove the corresponding route scoped error handler if any? In this
> way we could still keep on ManagedErrorHandler
And of course for this to work we would need to enrich the Interface:
org.apache.camel.processor.ErrorHandler
with more methods providing the informations like:
- is route/context scoped.
- the list/count of the bound routes to the given error handler.
- etc.
Babak
--
View this message in cont
Hi Claus,
Would it make sense to extends the logic of:
DefaultManagementLifecycleStrategy.onRoutesRemove()
to also remove the corresponding route scoped error handler if any? In this
way we could still keep on ManagedErrorHandler.
Babak
--
View this message in context:
http://camel.465427.n5
Oops! My answer to your proposal was indeed too fast, as what you proposed
doesn't fix the problem we're facing by camel-msv.
Again, the problem is *not* MSV itself but the *bridge* [1] Kohsuke
Kawaguchi has provided for it:
org.iso_relax.verifier.jaxp.validation
isorelax-jaxp-bridge
Hi
I am considering to remove error handlers mbeans from JMX as they are
painful to track properly for context and route scoped routes, in the
various DSLs (Java vs XML etc.). And the fact an error handler can be
used for multiple routes, as well being a default error handler etc.
Currently if yo
Hi Claus!
Please take a look at my last comment [1] to see if it makes sense to you.
[1] https://issues.apache.org/jira/browse/CAMEL-4959
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/ObjectConverter-problem-tp5517376p5521526.html
Sent from the Camel Development mail
Hi
Yeah this is correct. I am adding a special check for NaN in the type
converter so we can deal with this situation.
On Sun, Feb 26, 2012 at 10:58 PM, michal.warecki
wrote:
> Hmm, looks like more to work around the problem by changing the test instead
> of improving the code :-) There is no I
Hi Dan,
Thanks for the hint!
I'll look into it and will upgrade the other required dependencies [1] as
well. Probabaly this will end up with some code changes by this component.
[1]
https://svn.apache.org/repos/asf/camel/trunk/components/camel-msv/pom.xml
Babak
--
View this message in context:
Hi
Yeah the headers can most likely be copied today if the JMS brokers do
not barf anymore.
However I had hoped in the mean time we had fixed this and released
Camel 3.0, where we can optimize the logic
to only copy on demand. I once had some experimental code for this to
check the routes if the
13 matches
Mail list logo
