-1
a)
I am happy with the current model, and DO NOT want any changes / implications
upon the Camel 2.x codebase. Its important for me that the current 2.x
codebase is kept stable as is.
Camel 2.10 is on the doorsteps, and Camel 2.x is now 3 years old. I
want to give reasurance to the community
t
On Wed, Jun 20, 2012 at 6:29 PM, Hadrian Zbarcea wrote:
> Guillaume, you pay a price no matter what, if you do something or if you
> don't. I really don't want to talk about a solution, but the
> DefaultComponent already has a @Deprecated preProcessUri(String uri)
> intended to convert a current u
On 6/15/12 11:29 PM, Claus Ibsen wrote:
Hi
Camel 2.10 is about to be cut soon.
And there is a few changes in the logs when Camel stops.
1)
There is a new TypeConverterRegistry utilization log, that prints stats
from the type converter.
2)
The uptime is now on the same line as the last log lin
I think camel accepts the invalid URIs is a tread off for making the URI
readable for the human. As we develop the components in the old days we
don't have the rule to for the URI be validated.
So we added lots of extra codes to handle the camel URI separately.
I'm open to validate the URI in t
Actually there's gonna be a lot of work. There are a bunch of issues,
the threading model being the critical one, I think.
Hadrian
On 06/20/2012 09:04 PM, Willem Jiang wrote:
Yeah, it's a interesting topic.
I know lots of third part libs which camel use are support Android.
As Camel can run w
Yeah, it's a interesting topic.
I know lots of third part libs which camel use are support Android.
As Camel can run without Spring, I think we will not do much work to let
the core run within Android.
On Wed Jun 20 22:41:36 2012, Henryk Konsek wrote:
I don't think there's much we can do for
+1
I would use the INFO logging level for this kind of information.
Christian
On Fri, Jun 15, 2012 at 5:29 PM, Claus Ibsen wrote:
> Hi
>
> Camel 2.10 is about to be cut soon.
>
> And there is a few changes in the logs when Camel stops.
>
> 1)
> There is a new TypeConverterRegistry utilization l
Cool.
Thanks for letting me know.
Christian
On Wed, Jun 20, 2012 at 11:00 PM, Hadrian Zbarcea wrote:
> Yes, it is :).
>
> Hadrian
>
>
>
>
> On 06/20/2012 04:52 PM, Christian Müller wrote:
>
>> Hadrian, do you know whether
>> jetty:http://...
>> is a valid URI?
>>
>> I'm to lazy to go through the
+1 To aim for spec compliant URIs in camel 3. We should not try to
achieve this at all costs though. So if there are hard cases where we
would loose features we should discuss them in detail.
For properties the question is if they should be compliant URIs before
or after the replacement. Proba
Yes, it is :).
Hadrian
On 06/20/2012 04:52 PM, Christian Müller wrote:
Hadrian, do you know whether
jetty:http://...
is a valid URI?
I'm to lazy to go through the entire spec. May you know it?
Christian
On Wed, Jun 20, 2012 at 10:40 PM, Hadrian Zbarceawrote:
+1. Agree on all counts. All
Hadrian, do you know whether
jetty:http://...
is a valid URI?
I'm to lazy to go through the entire spec. May you know it?
Christian
On Wed, Jun 20, 2012 at 10:40 PM, Hadrian Zbarcea wrote:
> +1. Agree on all counts. All valid points. On the second bullet I think we
> have even better options.
>
Hey Jothi!
Hope you are doing well...
I use the following settings:
export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m"
and it works great (I updated the WIKI and added the " signs).
You should run a
mvn clean install
or
mvn clean install -DskipTests
in the Camel root directory.
If it doesn't wo
+1 (non binding)
If we'll support all existing features I see no locks here.
Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Christian Müller w dniu 20 cze 2012, o godz. 21:57:
> +1
> see my comments on [2].
>
> Also because the Camel code base grows
+1. Agree on all counts. All valid points. On the second bullet I think
we have even better options.
Thanks
Hadrian
On 06/20/2012 03:47 PM, Christian Müller wrote:
+1 for forcing valid URI from Camel 3.0 on warts if:
- we can still support all options (if this is not the case, we have to
di
+1
see my comments on [2].
Also because the Camel code base grows and grows because we got some good
contributions and implemented new features, making the core code base as
much easy as possible is an important thing IMO. Throwing away all the
hacks is a good possibility.
Also doing the same thin
+1 for forcing valid URI from Camel 3.0 on warts if:
- we can still support all options (if this is not the case, we have to
discuss the concrete cases)
- communicate this API breaking change in the Camel 3.0 release notes
and provide the escaped char sequence for the most used chars (for
con
+1
On Jun 20, 2012, at 12:45, Hadrian Zbarcea wrote:
> Absolutely :)
> Hadrian
>
> On 06/20/2012 02:37 PM, Christian Müller wrote:
>> +1
>> And don't forget the 2.8.x branch ;-)
>> Because we have decided to support (at least) the last two release
>> branches, we should cut a 2.8.x version as w
Absolutely :)
Hadrian
On 06/20/2012 02:37 PM, Christian Müller wrote:
+1
And don't forget the 2.8.x branch ;-)
Because we have decided to support (at least) the last two release
branches, we should cut a 2.8.x version as well. I could do this, but not
before 1st July.
Best,
Christian
On Tue, J
+1
And don't forget the 2.8.x branch ;-)
Because we have decided to support (at least) the last two release
branches, we should cut a 2.8.x version as well. I could do this, but not
before 1st July.
Best,
Christian
On Tue, Jun 19, 2012 at 4:02 PM, Hadrian Zbarcea wrote:
> +1. It is past due ind
A new release candidate apache-camel-2.10.0 final is out with
approximately 473 issues resolved so far: improvements and bug fixes [1].
Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-251/
The tarballs are here
https://repository.apache.org/c
-1
I don't think camel endpoints are real Uris as they are not really
used to point to a resource, though they can fall back to a URI in
simple cases. The fact that we use URI-like syntax is I think because
it's easy to use and quite easily understandable. We could have use
json or whatever synt
+1, WIth the fact that converters exist, we aren't breaking anything in 2
/je
On Jun 20, 2012, at 10:29 AM, Hadrian Zbarcea wrote:
> +1
> Hadrian
>
> On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
>> Using URIs to identify and configure Endpoints is a notable Apache Camel
>> innovation. This fe
+1
Hadrian
On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
Using URIs to identify and configure Endpoints is a notable Apache Camel
innovation. This feature was present in Camel from its first release.
The definition of the URIs syntax in unambiguous and defined in RFC-2396
[1].
Some components
Guillaume, you pay a price no matter what, if you do something or if you
don't. I really don't want to talk about a solution, but the
DefaultComponent already has a @Deprecated preProcessUri(String uri)
intended to convert a current uri like String to an equivalent valid
form (and log the new f
Wouldn't it affect basic things such as the file component which uses
endpoints such as
file://inbox?expression=backup/${date:now:MMdd}/${file:name}
and also the properties component and all camel placeholders such as
properties:{{cool.end}}
I don't really think the change is worth it if
On Wed, Jun 20, 2012 at 5:00 PM, Henryk Konsek wrote:
>> We should probably name it NoopAsyncCallback as IMHO thats a better name.
>
> I'm used to naming Noop- callbacks as Empty-ones but Noop sounds fine
> as well :) .
>
>> Also we may consider a single static instance as its just a noop, eg
>> l
> We should probably name it NoopAsyncCallback as IMHO thats a better name.
I'm used to naming Noop- callbacks as Empty-ones but Noop sounds fine
as well :) .
> Also we may consider a single static instance as its just a noop, eg
> like Collections.emptyList() does.
I thought about it but decide
Bilgin, commit away :).
There is no set rule, but the preference is obviously to do it right
away and the original committer to do the backmerge as well (he should
be the one who knows best). Another advantage is that you get more time
to test the backport if you do it earlier. We're close to
Hadrian, I will do the change now on trunk (I haven't used my commit right
that much so far ;)
I got a question though: when do you usually backport the changes from
trunk to branches: as soon as the commit to trunk, or later - when the
branch is about to be released?
Bilgin
PS: I've seen
http:/
> I don't think there's much we can do for
> camel 2.x, but it is one of my secret goals to have a camel-3.0 that runs
> embedded. I hope we'll talk more about this in the coming months.
I think it's pretty interesting topic. Maybe we could create wiki page
where we will gather the current status
Bilgin, you are correct, it should. Would you have some time to work on
a patch?
Thanks,
Hadrian
On 06/20/2012 09:20 AM, Bilgin Ibryam wrote:
While I was using camel-guice component, I realized that Main class (used
to run Camel from GuiceCamelContext) is actually not using
enableHangupSupport
As I mentioned before, to me this is a no-brainer. We all advertised for
almost 5 years that Camel uses URIs. That is not true, it doesn't really.
Next there is the problem of parsing. In Camel it is ambiguous how a
configuration string (a la URI) looks like. You could say it's ok if the
parsi
On Wed, Jun 20, 2012 at 3:20 PM, Bilgin Ibryam wrote:
> While I was using camel-guice component, I realized that Main class (used
> to run Camel from GuiceCamelContext) is actually not using
> enableHangupSupport and as a result the app is shut down quickly. The other
> Main class implementations
While I was using camel-guice component, I realized that Main class (used
to run Camel from GuiceCamelContext) is actually not using
enableHangupSupport and as a result the app is shut down quickly. The other
Main class implementations in org.apache.camel.main and
org.apache.camel.spring packages u
On Tue, Jun 19, 2012 at 9:09 AM, Henryk Konsek wrote:
> Hi,
>
> What about replacing anonymous inner noop AsyncCallback with
> EmptyAsyncCallback? Just to make a codebase a little bit nicer.
>
> // Bad
> Object value = invocation.proceed(new AsyncCallback() {
> public void done(boolean doneSync) {
Well, I'm not sure why you consider that separate. I don't see the
point in forcing the user to use encoded characters which lessen the
readability if the uri is not correct at the end.
Also what's the drawback in encoding the uri ? At the end, the uri
encoding is correct, but it gives the user mo
Yes Henryk. Camel as of now does not run well (if at all) on embedded
devices for a number of reasons. I don't think there's much we can do
for camel 2.x, but it is one of my secret goals to have a camel-3.0 that
runs embedded. I hope we'll talk more about this in the coming months.
Hadrian
O
Proper uri syntax and validation are 2 separate issues. This discussion
is about the syntax. Since it's just syntax (proper encoding) I don't
see any risk of loosing features and I agree we shouldn't.
Hadrian
On 06/20/2012 03:02 AM, Guillaume Nodet wrote:
Do you have any particular example ?
The Apache Jenkins build system has built Camel.trunk.notest (build #1573)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1573/
to view the results.
Hi,
I've been wondering about possibility of running Camel on Android.
>From the technical point of view running embedded Camel router on
Android device is probably possible. And there are many areas in
Android that could serve as a decent source or destination of messages
- Rabbit MQ Android clie
Lack of separation between consumer and producer configuration is really hard.
Many of Configuration objects we have is one big bag with properties. Some of
them are exclusive or similar and should not be set at the same type, eg.
replyTo and replyToType in JmsConfiguration. Most of properties a
Do you have any particular example ?
I know for example activemq uses uri in an extended way with
parenthesis and commas and I'm not sure they are completely valid.
If getting back to real uris means loosing some features, that needs
to be made clear.
On Mon, Jun 11, 2012 at 4:32 PM, Hadrian Zbarc
42 matches
Mail list logo
