Well, if you want to have technical comments, you'd have to come up
with a technical solution first.
If you just say camel MUST be X, people will assume the possible
consequences and base their decision on it. If that 's not the
consequences you had in mind, proposing a solution will definitely
le
Hi,
When do you plan to release camel-extra 2.10? I want to contribute new
component to it (JGroups, which is LGPL) so I've just seen that
current version is still 2.10-SNAPSHOT.
I can make a release if you want me to (I got commiter rights to
camel-extra) but I won't be able to deploy artifacts
Could you also explain to us the benefits in addition to the impacts ?
On Thu, Jun 21, 2012 at 8:29 PM, Hadrian Zbarcea wrote:
> Vote canceled. The community needs more time to understand the impacts. The
> consensus is that current users of camel 2.x must not be impacted by this
> change.
>
>
>
Vote canceled. The community needs more time to understand the impacts.
The consensus is that current users of camel 2.x must not be impacted by
this change.
Hadrian
On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
Using URIs to identify and configure Endpoints is a notable Apache Camel
innova
I'm not sure if my last email made it through since I did it through
Nabble...
But I had followed up with wondering why this URI stuff cannot be an
additional style URI parse that is in addition to what is being done today.
Is there a technical reason why we cannot support both styles of URLs, th
Thanks Rob, sounds like the best course of action. Will do that.
Hadrian
On 06/21/2012 02:06 PM, Rob Davies wrote:
If you vote had more detail about what you was considering, then artistic
feelings wouldn't have come into it :)
Why don't you close this vote - and open a new discussion (with mo
This sounds reasonable to me
On 21 Jun 2012, at 18:36, Hadrian Zbarcea wrote:
> Sounds perfect. That's exactly what I had in mind. You are proposing the
> extra setting, which I am perfectly fine with.
>
> Thanks a bunch,
> Hadrian
>
> On 06/21/2012 01:00 PM, Hiram Chirino wrote:
>> How about w
If you vote had more detail about what you was considering, then artistic
feelings wouldn't have come into it :)
Why don't you close this vote - and open a new discussion (with more detail?) -
so we can try reach a consensus
On 21 Jun 2012, at 18:19, Hadrian Zbarcea wrote:
> Now finally someth
Sounds perfect. That's exactly what I had in mind. You are proposing the
extra setting, which I am perfectly fine with.
Thanks a bunch,
Hadrian
On 06/21/2012 01:00 PM, Hiram Chirino wrote:
How about we add setting to the camel context which controls if the
'UnsafeUriCharactersEncoder.encode' m
Don,
All valid questions. I agree that details should come sooner, but they
cannot come sooner than agreeing on a principle. That was the purpose of
this thread.
Hadrian
On 06/21/2012 12:39 PM, Donald Whytock wrote:
-1
The only real objection is that the word "MUST" begs the question "Or
Now finally something I could work with. More inline.
Hadrian
On 06/21/2012 12:41 PM, Hiram Chirino wrote:
-1 This change would NOT be transparent to 2.x users. Lets not hurt our
2.x Camel community!
I think it will will be transparent. It MUST. The intent is *precisely*
to not hurt the 2.x C
How about we add setting to the camel context which controls if the
'UnsafeUriCharactersEncoder.encode' method is used or not?
That way folks that feel that their camel configurations MUST always use
valid URI syntax can enable it. And the rest can continue to use the
current behavior.
Users are
-1 This change would NOT be transparent to 2.x users. Lets not hurt our
2.x Camel community! This should have been a discussion about how we could
improve Camel 3.x.
>From my point of view, Camel is all about being flexible and an integrating
as many technologies as possible and avoid exclusive o
-1
The only real objection is that the word "MUST" begs the question "Or
else what?" Will existing components in 2.x that use non-standard URI
structure not be carried into 3.x unless they're rewritten? Will new
components that have non-standard URI structure be rejected out of
hand, the idea be
+1 - This has been a common complaint from a lot of users about not being a
standard. We just did a presentation and had people raising their hands
asking why they are so different. I think this would be great.
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Camel-MUST-u
-1, as it's working for a long time and stable.
We may discuss this change or rename the URI to a more appropriate
name for Camel 3.x, but we should keep it as is for Camel 2.x line
Freeman
On 2012-6-20, at 上午8:37, Hadrian Zbarcea wrote:
Using URIs to identify and configure Endpoints is a not
-1 Camel does not need to use valid URIs - I see no real benefit for the user.
I'm concerned about any changes that could affect existing users.
On 20 Jun 2012, at 01:37, Hadrian Zbarcea wrote:
> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This featur
Yeah, URI escaping sucks, I'm -1 on changing the format and +1 on
changing the name of the configuration string to a quasi-URI,
URI-esque, wanna-be URI or whatever :-)
On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea wrote:
> Using URIs to identify and configure Endpoints is a notable Apache Came
Hi
Welcome to the community.
On Thu, Jun 21, 2012 at 3:11 PM, Guillaume GIAMARCHI
wrote:
> Hello,
>
> I'm developer and camel user and i sometimes find mistakes or just typing
> errors in online documentation.
>
> I would be glad to help to make it better.
>
This sounds good. We love help and c
I'm +1 to the idea. If we call it a URI, then it needs to be a URI. If
this vote does not pass, then we would need to find a new name
(configuration string?) and update the documentation and such to reflect
that this is NOT a URI.
In particular, I'm +1 for full validation for 3.0. For 2.
In theory yes, that's how it kinda worked for many years. In practice it
fails for all sorts of edge cases. The code that actually could be very
simple and clear is riddled with all sorts hacks. Look at the code.
Hadrian
On 06/21/2012 07:46 AM, Henryk Konsek wrote:
It seems that you want to f
Hi
Really a minor issue, not nice though:
Looking at both the TAR.GZ as well as ZIP artifacts, there're the following
two documentations (as usual) under the path
"apache-camel-2.10.0/doc/manual":
camel-manual-2.10-SNAPSHOT.html
camel-manual-2.10-SNAPSHOT.pdf
However no idea where the SNAPSHOT
Well, I don't have a binding vote anyway, but I am mostly curious on what's
the added value on doing such change.
I can see the some side effects like hard to read URIs etc, but I am
striving to see the added value.
Can you please provide some more info around that?
--
*Ioannis Canellos*
*
FuseS
Hi
-1
I've already once mentioned why I do think so:
https://issues.apache.org/jira/browse/CAMEL-4857
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Camel-MUST-use-valid-URIs-for-identifying-and-configuring-Endpoints-tp5714697p5714840.html
Sent from the Camel De
Hi
I upgraded the source code for Camel in Action book, and gave the
2.10.0 a test spin.
The few migration pains was that camel-test dependency is now
camel-test-spring if you use Spring for testing.
This is expected and also on the release notes.
The issue I found is that the DSL for the WireTa
> It seems that you want to force incompatibly between Camel 2.x and 3.0
> which is a NOT "a no brainer" for me.
Good point. We will end up with ugly and backward incompatible URIs.
What about introducing "implicit URI encoding" term? Can't we just
assume that semi-URIs strings passed to the Came
-1
I see no real reason to break stuff
On 19 June 2012 19:37, 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 i
Reading through this discussion, it seems like there are actually two levels to
what is being discussed:
1) The validation rules for a proper URI and whether they are respected and
enforced in Camel core.
2) The presentation of an endpoint's configuration as a URI to the user.
The rules for #1
On Thu, Jun 21, 2012 at 3:53 AM, Claus Ibsen wrote:
> -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 Cam
On 20 June 2012 15:53, Hadrian Zbarcea wrote:
> Bilgin, commit away :).
>
ok, it is in.
btw I was wrong: enableHangupSupport is used only for graceful shutdown.
My application wasn't running continuously because I used the duration
option, which shuts down Camel after the duration ends
Bilgin
The Apache Jenkins build system has built Camel.trunk.notest (build #1574)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1574/
to view the results.
On Thu, Jun 21, 2012 at 11:25 AM, mabahma wrote:
> Hi,
>
> I have the seme problem when addin the dependeny on camel 2.10-SNAPSHOT in
> one of my projects.
>
>
> org.apache.camel
> camel-core
> 2.10-SNAPSHOT
>
>
>
> I have the jar in my repository. i have this error in my po
Hi,
I have the seme problem when addin the dependeny on camel 2.10-SNAPSHOT in
one of my projects.
org.apache.camel
camel-core
2.10-SNAPSHOT
I have the jar in my repository. i have this error in my pom file : missing
artifact : came-core-2.10-SNAPSHOT.
Any idea ?
Th
33 matches
Mail list logo
