ApacheCon NA 2013 starts in less than two weeks!
I will be there from Feb. 25th until Mar. 1st as I mentioned here [1]. Feel
free to list yourself on the "Who Arrives When" page and/or share the
information here. I'm very interested to know who will join us and when!
After arriving in Portland we
Thanks Raul!
On Tue, Feb 12, 2013 at 10:05 AM, Raul Kripalani wrote:
> Hey Scott,
>
> Check their website. "Purchase" section, "Open Source" tab. You just
> contact them on their sales email.
> I sent the email from my Apache address and included a link to the Camel
> Team page.
>
> Regards,
> R
This was the today's discussion on IRC (irc://irc.codehaus.org/camel). Feel
free to join the next time and/or comment on the today's discussed items.
The next one is scheduled for 02/19/2013 7:00PM - 8:00PM CET. Feel free to
join and express your ideas/needs/whishes/...
02/12/2013 7:00PM - 8:00PM
Hi guys,
I've uploaded an updated patch. Let me know if there's anything else
that needs changing.
Take care,
Daniel
-Original Message-
From: Daniel Gredler [mailto:dgred...@dhlglobalmail.com]
Sent: Tuesday, February 12, 2013 12:13 PM
To: dev@camel.apache.org
Subject: RE: Support for
Hey Scott,
Check their website. "Purchase" section, "Open Source" tab. You just
contact them on their sales email.
I sent the email from my Apache address and included a link to the Camel
Team page.
Regards,
Raúl.
On Tue, Feb 12, 2013 at 5:51 PM, Scott England-Sullivan wrote:
> Hello all,
>
>
There is another security issue in CXF that may require a release. It's
being investigated now. The backup option is to make a copy of the cxf
features in camel temporarily. We'll know in a couple of days and redo
the release.
Cheers,
Hadrian
On 02/09/2013 09:47 AM, Hadrian Zbarcea wrote:
Cl
Hi Henryk, Claus,
Cool, thanks for the feedback! I'll update the patch and upload it.
Take care,
Daniel
-Original Message-
From: Claus Ibsen [mailto:claus.ib...@gmail.com]
Sent: Tuesday, February 12, 2013 9:09 AM
To: dev@camel.apache.org
Subject: Re: Support for zip (de)compression
O
Cool, Claus, thanks for the clarification!
Will commit my pending fixes in a few hours.
On Tue, Feb 12, 2013 at 2:49 PM, Claus Ibsen wrote:
> On Tue, Feb 12, 2013 at 2:38 PM, Raul Kripalani wrote:
> > Hi,
> >
> > I'm debugging why a pair of VM producer-consumer become disconnected in
> an
> > O
On Tue, Feb 12, 2013 at 2:38 PM, Raul Kripalani wrote:
> Hi,
>
> I'm debugging why a pair of VM producer-consumer become disconnected in an
> OSGi environment when the consumer bundle is restarted. See [1].
>
> I can trace it back to the SedaEndpoint being shutdown twice: 1) when the
> route is sh
On Tue, Feb 12, 2013 at 11:34 AM, Henryk Konsek wrote:
> Hi Daniel,
>
>> The current ZipDataFormat actually
>> implements "deflate" (de)compression.
>
> I like this idea, as I needed such component myself.
>
> I suggest however to rename it to camel-zipfile data format, because
> a) zip2 should be
Hi,
I'm debugging why a pair of VM producer-consumer become disconnected in an
OSGi environment when the consumer bundle is restarted. See [1].
I can trace it back to the SedaEndpoint being shutdown twice: 1) when the
route is shutdown and 2) when the context is shutdown.
Why doesn't ServiceSupp
Yes but then I think in Camel 3.0 we should better update the Javadoc of this
contract and restrict the usage through adding a check for the passed class
object which would guranntee a correct API usage:
if (!clazz.isInterface()) {
throw ...
}
To avoid the illusion for the end user the c
Hi Daniel,
> The current ZipDataFormat actually
> implements "deflate" (de)compression.
I like this idea, as I needed such component myself.
I suggest however to rename it to camel-zipfile data format, because
a) zip2 should be reserved for better version of existing zip
component b) 'zipfile' i
Github user scranton closed the pull request at:
https://github.com/apache/camel/pull/12
On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
wrote:
> Hi
>
> Looking at the public ClassResolver API (among others) it provides 4 methods
> taking over the concrete to be loaded Class type:
>
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolv
Thanks for your feedback Christian!
Currently I'm in Holiday. Will take care of this when I'm back in town
again.
Babak
Christian Mueller wrote
> +1
> I see your point. Doesn't make sense to me too.
>
> Best,
> Christian
>
> On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
> <
> babak.vahdat@
> Don't know for the moment any drawbacks.
Thank you for your feedback Charles.
Any further thoughts related to the discussed design approach will be
appreciated :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Don't know for the moment any drawbacks.
On Tue, Feb 12, 2013 at 9:02 AM, Henryk Konsek wrote:
> Hi Charles,
>
> > What you suggest corresponds to what we have done for "direct-vm"
> component
>
> Yes, I'm aware that vm and vm-direct components handle static
> references. I'm just wondering if
Hi Charles,
> What you suggest corresponds to what we have done for "direct-vm" component
Yes, I'm aware that vm and vm-direct components handle static
references. I'm just wondering if this approach has any drawbacks or
corner cases (probably OSGI-related) I'm not aware of. I don't want to
reinv
19 matches
Mail list logo