Yes there are some cases where I did not create a compatibility classes.
But these should not be in the camel API. (org.apache.camel,
org.apache.camel.spi).
Of course I know that the API is not self contained and so people use
more than the API. I did it where I think the change will not affect
On Mon, Sep 5, 2011 at 4:54 PM, Guillaume Nodet wrote:
> Maybe one way to solve those problems would be to start a 3.0 branch
> and experiment / allow more api changes there and keep trunk stable
> for some time, then later switch when 3.0 begins to have more focus.
>
>
+1. I honestly don't expec
On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
wrote:
> Hi Claus,
>
> I am trying to give the community a smooth transition to 3.0 by my current
> changes.
>
> Whereever possible I use a deprecated class in the old place. So someone who
> changes to camel 2.9.0 should have no problems.
> He w
On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom wrote:
> With deprecate changes, we'll have no issues at all, so there I do not see it
> as a "change" at all.
>
Its not only deprecated changes. What we have is a mix of changes:
1) classes being deleted (without any prior warnings, they were not
@d
Regarding the Dan update (about the fact that CXF 2.4.3 will use Spring
3.0.6), it makes sense that Camel will upgrade to Spring 3.0.6 as well.
So, I'm agree:
- let Spring 3.0.6 in Karaf, starting from 2.2.3
- if people want to use Spring 3.0.5 (and applications that use this
version), they hav
On Monday, September 05, 2011 8:51:07 AM Jean-Baptiste Onofré wrote:
> I'm agree Andreas.
>
> It's exactly the purpose of Cave: to be able to decouple some "features"
> (like Spring*) from the core and the distribution.
>
> However, Cave is not fully ready, so we have to find a way waiting Cave.
Hi Christian,
Here is one thing, when you introducing a new change (moving the classes
around), you may updated the unit tests as well. But it could introduce
some side effect to break the old codes, which may not covered by these
unit tests.
It will take lot time for the user to fix that bu
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lalonde updated CAMEL-3142:
---
Attachment: camel-jpa_JpaPollingConsumer_forReview.tar
The attached patch adds a JpaPollingCo
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde edited comment on CAMEL-3142 at 9/5/11 9:12 PM:
[
https://issues.apache.org/jira/browse/CAMEL-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097313#comment-13097313
]
Ioannis Canellos commented on CAMEL-4213:
-
@Claus: Indeed the TCCL is set (at leas
With deprecate changes, we'll have no issues at all, so there I do not see it
as a "change" at all.
/je
On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:
> Claus,
>
> How exactly did you get to figure out what the community wants "NO CHANGES"
> in the the API an via what process were you nomi
Hi Guillaume,
there are several changes I did recently. The main issue perhaps is the
current issue I opened:
https://issues.apache.org/jira/browse/CAMEL-4417
This of course a very sensible area and I plan to do this very carefully
and will create a patch to discuss before I change something.
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde edited comment on CAMEL-3142 at 9/5/11 4:00 PM:
Maybe one way to solve those problems would be to start a 3.0 branch
and experiment / allow more api changes there and keep trunk stable
for some time, then later switch when 3.0 begins to have more focus.
On Mon, Sep 5, 2011 at 17:44, Claus Ibsen wrote:
> On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea
Can one point to the exact changes we're talking about here?
If those are fully compatible through using deprecation, I don't see
any major problem.
However, I don't think we should introduce incompatible changes unless
really required, especially as we *are* planning to do a 3.0 some time
in the n
On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian wrote:
> Claus,
>
> How exactly did you get to figure out what the community wants "NO CHANGES"
> in the the API an via what process were you nominated to express that opinion?
>
I guess writing all caps was a way of getting attention.
The phrase s
Thanks Willem,
I just restarted the 2.8.1 builds, hopefully it'll work better today.
Hadrian
On Sep 5, 2011, at 12:38 AM, Willem Jiang wrote:
> I just merged the patches which fixed the test error on camel 2.8.x branch.
> The build should be OK now.
>
> On Mon Sep 5 11:55:45 2011, Zbarcea Ha
Claus,
How exactly did you get to figure out what the community wants "NO CHANGES" in
the the API an via what process were you nominated to express that opinion?
The reality is that the API did change in every single minor release of Camel,
and my understanding is that this is an effort to actu
[
https://issues.apache.org/jira/browse/CAMEL-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097163#comment-13097163
]
Christian Schneider commented on CAMEL-4417:
I intend to create a stub class t
Am 05.09.2011 16:12, schrieb James Strachan:
al impl class like DefaultCamelContext.
An Endpoint maybe be able to create a more optimal Exchange object
since it knows the ultimate destination of the Exchange; e.g. to avoid
double-creation of header structures - such as creating a JMS Message
to
Hi Claus,
I am trying to give the community a smooth transition to 3.0 by my
current changes.
Whereever possible I use a deprecated class in the old place. So someone
who changes to camel 2.9.0 should have no problems.
He will see deprecation warnings though and this is a good thing. It
will
On 5 September 2011 14:04, Christian Schneider wrote:
> Hi all,
>
> I am currently trying to minimize the use of impl classes in components and
> check how to completely hide impl classes for 3.0.
>
> So I will have to move several classes from impl to support as they are used
> as base classes an
Hi
I am writing this mail with a "community hat" as well being a very
concerned Camel team member.
The API in camel-core had a fair number of changes recently, which is
a strong concern from a community point of view.
Basically the community views Camel 2.x as an mature and well
established proje
[
https://issues.apache.org/jira/browse/CAMEL-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
james strachan updated CAMEL-4417:
--
Fix Version/s: (was: 2.9.0)
3.0.0
> Move base classes used by components
[
https://issues.apache.org/jira/browse/CAMEL-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097145#comment-13097145
]
james strachan commented on CAMEL-4417:
---
Since this code change will break pretty mu
Hi
Just to be clear when I wear the "watchdog of the community hat".
The API in Camel 2.x should be kept to a minimum changes. For example
we cannot move DefaultEndpoint, DefaultExchange etc. They should stay
to ensure 100% backwards compatibility and not cause more trouble in
the community. Thes
Move base classes used by components from impl to support
-
Key: CAMEL-4417
URL: https://issues.apache.org/jira/browse/CAMEL-4417
Project: Camel
Issue Type: Improvement
Compon
[
https://issues.apache.org/jira/browse/CAMEL-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved CAMEL-4414.
Resolution: Fixed
> CamelLogger should not be a Processor and a log class at the sa
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde commented on CAMEL-3142:
*Status Update*
At the moment I have a J
Hi all,
I am currently trying to minimize the use of impl classes in components
and check how to completely hide impl classes for 3.0.
So I will have to move several classes from impl to support as they are
used as base classes anyway (e.g. DefaultEndpoint). A special case is
DefaultExchange
[
https://issues.apache.org/jira/browse/CAMEL-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated CAMEL-4416:
Fix Version/s: 2.9.0
> Upgrade to Spring 3.0.6.RELEASE
> --
Upgrade to Spring 3.0.6.RELEASE
---
Key: CAMEL-4416
URL: https://issues.apache.org/jira/browse/CAMEL-4416
Project: Camel
Issue Type: Task
Components: camel-spring
Reporter: Jean-Baptiste Onof
Use Karaf new spring features
-
Key: CAMEL-4415
URL: https://issues.apache.org/jira/browse/CAMEL-4415
Project: Camel
Issue Type: Improvement
Components: camel-bam, camel-jms, camel-jpa, camel-spring, cam
Hi
Thanks for the help.
Now i am able to invoke webservice method.
Now i want to send the response back to the client and process the request
message, which EIP pattern i have to use?
I tried with wireTap and enrich, i didn't got the expected result. Please
suggest.
Thanks,
Santosh
On Sun, S
CamelLogger should not be a Processor and a log class at the same time and it
should not have ServiceSupport
Key: CAMEL-4414
URL: https://issues.apache.or
[
https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved CAMEL-4381.
Resolution: Fixed
The issue when an exception occurs at starting a service is solve
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097044#comment-13097044
]
Claus Ibsen commented on CAMEL-3142:
Thanks for the polish, I have committed the patch
37 matches
Mail list logo
