> Camel provides a pluggable data format so we can have implementations
> outside the camel-core
>
> But a selected few do not depend on 3rd party .jars which of course
> allow us to host the implementations directly in camel-core.
> Cool if you want to help then please take a look and see what yo
On Sun, Oct 4, 2009 at 12:45 PM, Christian Grobmeier
wrote:
>> Camel provides a pluggable data format so we can have implementations
>> outside the camel-core
>>
>> But a selected few do not depend on 3rd party .jars which of course
>> allow us to host the implementations directly in camel-core.
>
On Sat, Oct 3, 2009 at 6:48 PM, Vladimir Okhotnikov
wrote:
>
> Thank both you and Hadrian for your responses. I'm actually willing to
> provide a patch to add support for real zip data format, but I need your
> advice about particular route to take. So far, I see 3 options:
>
> 1. unmarshal().zip(
Hi
In recent code on Apache camel trunk we fixed a race condition
shutting down Camel with a JMS consumer.
However the stacktraces did not hint it was the failover transport.
Anyway you could try the latest snapshot code to see how goes.
And I suggest to ask/search the AMQ user forum as well as
I agree that unmarshal().compression() sounds better. OTOH, probably
unmarshal().compressed() would be even better.
I'm not sure now whether I should try creating the patch as I planned,
because what Christian suggests (extracting camel-compress) is obviously
better and superior solution. If he w
How about using .compress to compress and .decompress to extract something?
Could perhaps the notion of extracting several parts from a container be
handled with the existing splitting component?
I imagine a 2 phase extraction like in tar.gz:
.decompress(Gzip).split(Tar)
or for a zip file:
.de
This would work nice for tar.gz, but not so nice for zip and other formats
which tend to combine aggregation and compression in one operation. The main
question is, what exactly should do split(Zip) and what decompress(Zip) in
your scenario?
Christian Schneider wrote:
>
> How about using .compr
Hmm,
I think you are right as the Zip API is not separate it makes sense to
use only one DSL function. The question is then of course how would you
name it?
Would you rather name the operation split(Zip) or decompress(Zip)? If
the operation was named decompress the tar.gz example could be do
On Sat, 3 Oct, 2009 at 06:57, Claus wrote:
> If you are using Camel 2.0 you got the onCompletion...
The onCompletion block seems to suffer exactly the same issue as the
onException one: the transacted tag effectively disables it.
Moving the onException block *after* the transacted tag doesn't wor
Christian Schneider wrote:
>
> Hmm,
>
> I think you are right as the Zip API is not separate it makes sense to
> use only one DSL function. The question is then of course how would you
> name it?
>
> Would you rather name the operation split(Zip) or decompress(Zip)? If
> the operation was n
Vladimir Okhotnikov schrieb:
The approach seems okay. The only thing that bothers me is that I'm still
not sure the split/aggregate behavior is specific to compression, and will
not be useful for other data formats.
"split" and "aggregate" are already present in the DSL. That is why I
first t
Yep, didn't think about memory consumption.
It actually just occurred to me that with such requirements it would be much
more logical to use something like a File component (i.e. a file-based
component, like FtpComponent) - it already addresses sorting, split needs
etc. (Perhaps this is what Clau
In fact, with solid archives and the need to archived process files in some
particular order, you will suffer ether performance penalty or memory
penalty anyway - you will either have to store either out-of-order extracted
files somewhere or perform the decompression multiply times. Not sure if zi
Claus Ibsen-2 wrote:
>
> Hi
>
> I have just backported a fix for CAMEL-1878 to 1.x as well.
> You are welcome to try with a new 1.6.2-SNAPSHOT whether it fixes your
> bean problem.
>
>
Thanks! I'll give it a shot.
eric
--
View this message in context:
http://www.nabble.com/using-methodN
Hi
If you think that error handling is something that is easy then you
cant be more wrong. Its hard.
If you are using transacted routes then leave it to the underlying
transaction manager to handle the error.
If you mix and match with Camels onException and default error
handlers etc. then you ha
> It would be too fine grained having a single component for: tar, zip,
> rar, bzip2 and whatnot exists.
>
> Does Apache Commons supports a uniform API for these underlying
> compression libraries?
Yes. Apache Commons Compress is some kind of layer around. It contains
a factory and some interfaces
> I'm not sure now whether I should try creating the patch as I planned,
> because what Christian suggests (extracting camel-compress) is obviously
> better and superior solution. If he wishes to do it, I'll be happy to
> contribute whatever I can.
Of course, jump in and enjoy. However, plase thin
Christian Grobmeier schrieb:
Claus (or others): what is the policy with existing apache committers?
Is there a chance that I can get karma to the sandbox? I would like to
avoid developing this on GIT with Vlaidimir and then have it back
through the incubator.
I usually open a jira and provide
On Mon, Oct 5, 2009 at 7:33 AM, Christian Schneider
wrote:
> Christian Grobmeier schrieb:
>>
>> Claus (or others): what is the policy with existing apache committers?
>> Is there a chance that I can get karma to the sandbox? I would like to
>> avoid developing this on GIT with Vlaidimir and then h
>> I usually open a jira and provide my patch as an attachment there. You
>> simply state there with an option that you make this patch available with
>> the Apache License.
>> Then any camel committer can commit it to the trunk. As far as I know the
>> Incubator process only applies when the code
On Sun, Oct 4, 2009 at 10:15 PM, Vladimir Okhotnikov
wrote:
>
> Yep, didn't think about memory consumption.
>
> It actually just occurred to me that with such requirements it would be much
> more logical to use something like a File component (i.e. a file-based
> component, like FtpComponent) - it
On Mon, Oct 5, 2009 at 7:52 AM, Christian Grobmeier wrote:
>>> I usually open a jira and provide my patch as an attachment there. You
>>> simply state there with an option that you make this patch available with
>>> the Apache License.
>>> Then any camel committer can commit it to the trunk. As fa
> But we never really took of with this and its my impression that
> Commons VFS is not actively maintained anymore? Or do I mistake.
Its maintained, but at the moment a little bit silent
>> I hoped the sandbox was open to other apache committers. However,
>> we'll use GIT or Bazaar for preparing the patch then
>
> You can also have projects hosted at the FUSE forge.
> http://forge.fusesource.com/
>
> But it may be overkill as its meant for new projects, and not for minor
> patches
24 matches
Mail list logo
