Hi Claus and Glen,
I agree that we might want to keep http3 for longer and the shared
documentation is also a good reason to not rename.
I also like Glen´s proposal to introduce a http3 component and perhaps
deprecate the the http component. So people understand that http is not
the default co
below is a very simple testcase for this problem, due to the random nature of
the bug, you can get different result each time you run the program.
However, if you create a new decoder in the pipelinefactory each time, you
get the correct result.
The idea of the test is: create two endpoint, listen
Hi
On Mon, Apr 9, 2012 at 11:03 PM, Glen Mazza wrote:
> I guess for those (and only those) components for which Camel wishes to
> maintain multiple versions (e.g., http3 & http4, mina1 & mina2), it might be
> best for such components to always have a version number as part of their
> names inste
I guess for those (and only those) components for which Camel wishes to
maintain multiple versions (e.g., http3 & http4, mina1 & mina2), it
might be best for such components to always have a version number as
part of their names instead of renaming whatever the standard version
becomes back to
After a NPE in Jenkins [1], the next build for Apache Camel [2] failed
because camel-core-2.10-SNAPSHOT.jar could not deleted. Could you please
kill the hanging thread/process.
[1]
https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.windows/327/console
[2]
https://builds.apache.
If we rename http4 to http for camel 3.0 I think it is acceptable as it
is a major version.
On the other hand if we do not do it then what would we do? Keep http4
forever and not have http. For new users this will look just weird.
Christian
Am 09.04.2012 22:04, schrieb Christian Müller:
My
My 0,02 $:
I would add a warning on page [1] that new user should prefer to use
camel-http4 over camel-http (as we did it already for iBatis). Camel-http
should mark as deprecated and will be deleted in Camel 3.x.
I would *NOT* rename camel-http to camel-http3 and camel-http4 to
camel-http. This wi
+1
On Apr 9, 2012, at 10:05 AM, Hadrian Zbarcea wrote:
> +1. I wanted to say the same thing. Dan beat me to it.
> Hadrian
>
> On 04/09/2012 12:02 PM, Daniel Kulp wrote:
>> On Monday, April 09, 2012 05:43:15 PM Claus Ibsen wrote:
>>> Its just that Apache iBatis moved out of Apache, and is no longe
Hi, all
I recently encountered a bug in camel-netty, see my previous post on
http://camel.465427.n5.nabble.com/buffer-corruption-in-camel-netty-td5551122.html
The main reason is that camel-netty's DefaultServerPipelineFactory stores
decoders/encoders in NettyConfiguration object and use them whe
Am 09.04.2012 18:21, schrieb Claus Ibsen:
Thus, from my perspective, there is no difference between this and the
iBatis case. In neither case is there a community behind the component to
support it. With iBatis, folks need to move to MyBatis. With http client,
they need to move to 4.x.
On Mon, Apr 9, 2012 at 6:02 PM, Daniel Kulp wrote:
> On Monday, April 09, 2012 05:43:15 PM Claus Ibsen wrote:
>> Its just that Apache iBatis moved out of Apache, and is no longer an
>> Apache project. And therefore people should use the product hosted by
>> MyBatis instead. And as Apache iBatis is
On Mon, Apr 9, 2012 at 6:10 PM, Jean-Baptiste Onofré wrote:
> If it's clearly "announced" that HTTP3 is EOL, in that case, it makes sense
> to do the same in Camel.
>
IMHO That doesnt really matter as much as we have *end users* who use
it, then let them use it.
Why take something away from them.
If it's clearly "announced" that HTTP3 is EOL, in that case, it makes
sense to do the same in Camel.
Regards
JB
On 04/09/2012 06:02 PM, Daniel Kulp wrote:
On Monday, April 09, 2012 05:43:15 PM Claus Ibsen wrote:
Its just that Apache iBatis moved out of Apache, and is no longer an
Apache proje
+1. I wanted to say the same thing. Dan beat me to it.
Hadrian
On 04/09/2012 12:02 PM, Daniel Kulp wrote:
On Monday, April 09, 2012 05:43:15 PM Claus Ibsen wrote:
Its just that Apache iBatis moved out of Apache, and is no longer an
Apache project. And therefore people should use the product hos
On Monday, April 09, 2012 05:43:15 PM Claus Ibsen wrote:
> Its just that Apache iBatis moved out of Apache, and is no longer an
> Apache project. And therefore people should use the product hosted by
> MyBatis instead. And as Apache iBatis is retired, then that is fine
> with me to remove camel-iba
It makes sense, we can rename/remove the http component as soon as
commons-httpclient 3 will be removed/fully deprecated.
Regards
JB
On 04/09/2012 05:43 PM, Claus Ibsen wrote:
On Mon, Apr 9, 2012 at 5:13 PM, Jean-Baptiste Onofré wrote:
Hi Glen,
currently, the component Camel code is exactly
On Mon, Apr 9, 2012 at 5:13 PM, Jean-Baptiste Onofré wrote:
> Hi Glen,
>
> currently, the component Camel code is exactly the same, only the HTTP
> client used is different.
>
> I noticed (and Claus too) an issue on this component (it always uses a
> CachedOutputStream which mean that a file is cr
Hi Glen,
currently, the component Camel code is exactly the same, only the HTTP
client used is different.
I noticed (and Claus too) an issue on this component (it always uses a
CachedOutputStream which mean that a file is created in tmp dir at every
call).
+1 to rename http4 to http and fl
Team, I noticed Camel is maintaining both an "HTTP" (using Apache HTTP
client 3.x) and an "HTTP4" component (using Apache HTTP client 4.x).
For Camel 3.0, can/should the former be removed so only one component is
maintained, with the latter component optionally being renamed to HTTP
in the pro
19 matches
Mail list logo
