[
https://issues.apache.org/jira/browse/CAMEL-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114123#comment-13114123
]
Chad Beaulac commented on CAMEL-2624:
-
CAMEL-3471 should resolve this ticket. It seems
Support for an xml dsl in camel-bam
---
Key: CAMEL-4488
URL: https://issues.apache.org/jira/browse/CAMEL-4488
Project: Camel
Issue Type: New Feature
Components: camel-bam
Affects Versions: 2.8.0
Donald, you are mostly correct, this would require mostly repackaging of
the jars, i.e. splitting the core into multiple jars. We will probably
have to do something with the CamelContext, it became a bit of a
hodge-podge. In any case, the intent is for the migration to be still
simple and strai
On Sat, Sep 24, 2011 at 9:14 PM, Hadrian Zbarcea wrote:
> * cleanup the api an architecture to allow one to use camel as an
> integration framework *without* the routing part. For instance one should be
> able to use just a producer template and the components of choice with a
> lean runtime (with
Ioannis, what you suggest is similar to what Christian was suggesting
except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
calling these versions 3.0, 3.1, with the intention, probably, to
accommodate Claus' proposal.
Now, to answer Willem and Rob other messages in this thr
[
https://issues.apache.org/jira/browse/CAMEL-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Zhemzhitsky updated CAMEL-4487:
--
Attachment: MockEndpoint.patch
> MockEndpoint should reset defaultProcessor
> -
MockEndpoint should reset defaultProcessor
--
Key: CAMEL-4487
URL: https://issues.apache.org/jira/browse/CAMEL-4487
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions:
On Saturday, September 24, 2011 7:34:14 PM Christian Müller wrote:
> Hello Claus!
>
> Thank you for your work updating the WIKI page. I didn't know them...
>
> But I have to "stress" this topic a bit more, because I still have open
> questions:
> 1) Is it a problem when different committers use d
Exceptions are not propagated to the parent route when endpoint cannot be
resolved in the RoutingSlip EIP
-
Key: CAMEL-4486
URL: https://issues.apache.org/jira
Exceptions are not propagated to the parent route when they are thrown from the
RecipientList EIP
-
Key: CAMEL-4485
URL: https://issues.apache.org/jira/browse/CAMEL-44
That's exactly what I think, Hadrian.
A minor release has not to be 100% backwarts compatiple. Of course we try
our best to be 100% backwarts compatible in minor releases, but it should
not be a problem if we aren't, as long as we document the not backwarts
compatible changes.
A micro/bugfix rele
Excellent points Christian. My take on this inline.
Hadrian
On 09/24/2011 01:34 PM, Christian Müller wrote:
Hello Claus!
Thank you for your work updating the WIKI page. I didn't know them...
But I have to "stress" this topic a bit more, because I still have open
questions:
1) Is it a problem
Hello Claus!
Thank you for your work updating the WIKI page. I didn't know them...
But I have to "stress" this topic a bit more, because I still have open
questions:
1) Is it a problem when different committers use different merge tools (the
Java program, the Python script, simply Git, ...)?
2) W
I understand that there are two respectable views on the subject:
a) We should guarantee forward compatibility for 2.x as the major version
implies.
b) The API changes should not wait for the 3.0.0 release as its not going to
happen any time soon.
I was wondering if it would be possible to make a
If you take a look at the Jetty[1] or Spring[2], they are doing the
milestone release for the big version release.
I guess there is no big user to use that kind of milestone release in
production, but it tells the user we are moving forward, if you take
some time to try it , you will not spen
I don't think we're debating if, we're debating when. I get your point
and I would agree if this was any different than before. The reality
though is that *every* single minor release of Camel was *not* 100%
backwards compatible. We absolutely strive for backward compatibility
and 2.9.0 should
The fact that it's not 100% compatible IS why it's not a good idea to
call it 2.x. The point of version numbering schemes are to reflect
the compatibility between releases. If trunk is not a major release,
I don't know what is. And yes I would hope that the 3.x line tries to
keep as much backwar
Using custom expression in RecipientList EIP which throws exception, is not
triggering onException
--
Key: CAMEL-4484
URL: https://issues.apache.org/jira/browse/CAMEL-
[
https://issues.apache.org/jira/browse/CAMEL-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4482.
Resolution: Fixed
> Using custom expression in Splitter EIP which throws exception, is not
> trigg
[
https://issues.apache.org/jira/browse/CAMEL-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4483:
---
Priority: Major (was: Blocker)
Remaining Estimate: (was: 24h)
Original Estimat
[
https://issues.apache.org/jira/browse/CAMEL-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-4483:
--
Assignee: Claus Ibsen
> Global exception not invoked in case of Exception fired while iterating
[
https://issues.apache.org/jira/browse/CAMEL-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nilesh Soni resolved CAMEL-4483.
Resolution: Duplicate
Same as CAMEL-4482
> Global exception not invoked in case of Exception fired
Global exception not invoked in case of Exception fired while iterating through
File Splitter
-
Key: CAMEL-4483
URL: https://issues.apache.org/jira/browse/CAMEL-4483
Using custom expression in Splitter EIP which throws exception, is not
triggering onException
-
Key: CAMEL-4482
URL: https://issues.apache.org/jira/browse/CAMEL-4482
24 matches
Mail list logo
