Hi Daniel,
It sounds good. I will take care of the patch today.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.javaey
+1 again
Sent from a mobile device
Am 22.10.2012 22:06 schrieb "Henryk Konsek" :
> > The package name should be
> > org.apacheextras (2 'e's, 1 's').
>
> Apparently in one of my previous posts I accidentally removed 's' from
> the package name. Probably that confused Hadrian. Sorry for that.
>
>
> The package name should be
> org.apacheextras (2 'e's, 1 's').
Apparently in one of my previous posts I accidentally removed 's' from
the package name. Probably that confused Hadrian. Sorry for that.
Just to make things clear - we're talking about (and vote for)
renaming 'org.apachextras' (1e,
Hi all,
After digging through the code, it appears to me that the changes can be
confined to ManagedCamelContextMBean and ManagedCamelContext, which is
much less invasive than what I had thought.
I've created a feature request to add support for cold restarts via JMX,
and have attached a proposed
On Mon, Oct 22, 2012 at 4:51 PM, Hadrian Zbarcea wrote:
> -1 (strong)
>
> The package name should be
> org.apacheextras (2 'e's, 1 's'). If you check the whois database [1],
> apacheextras.org is owned by the ASF, whereas the other proposed domain is
> not registered. The claim that somebody 'expe
-1 (strong)
The package name should be
org.apacheextras (2 'e's, 1 's'). If you check the whois database [1],
apacheextras.org is owned by the ASF, whereas the other proposed domain
is not registered. The claim that somebody 'expects' a particular
package name is unfounded, I am curious how yo
Hi
Thanks for reporting. I have logged a ticket
https://issues.apache.org/jira/browse/CAMEL-5729
Next time please use the @user mailing list instead. See here
http://camel.apache.org/mailing-lists.html
On Mon, Oct 22, 2012 at 12:04 PM, ODarwish
wrote:
> The file is not deleted if it is submitt
The file is not deleted if it is submitted to digital signature end point
(crypto: sign), my route DSL is
Although the message (file) successfully submitted
Hi Camel!
Thanks for you hard work, camel is an excellent tool.
I would like to ask you for a help, I had difficulties to modify an outgoing
soap header from an exchange pipeline. I did not found any solution for it,
thus I've created a patch for the camel-ws component, please look at it
https:/