Trim camel-web console to make it more lighter
--
Key: CAMEL-4413
URL: https://issues.apache.org/jira/browse/CAMEL-4413
Project: Camel
Issue Type: Improvement
Components: camel-web
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.
I can see two:
1/ stay with Spring 3.0.6.RELEASE in 2.2.x branch, and provide
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097044#comment-13097044
]
Claus Ibsen commented on CAMEL-3142:
Thanks for the polish, I have committed the
[
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
CamelLogger should not be a Processor and a log class at the same time and it
should not have ServiceSupport
Key: CAMEL-4414
URL:
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,
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,
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
[
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
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
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde commented on CAMEL-3142:
*Status Update*
At the moment I have a
[
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
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
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. These
[
https://issues.apache.org/jira/browse/CAMEL-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097145#comment-13097145
]
james strachan commented on CAMEL-4417:
---
Since this code change will break pretty
[
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
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
On 5 September 2011 14:04, Christian Schneider ch...@die-schneider.net 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
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
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
[
https://issues.apache.org/jira/browse/CAMEL-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097163#comment-13097163
]
Christian Schneider commented on CAMEL-4417:
I intend to create a stub class
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
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
On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian hzbar...@gmail.com 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.
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
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 claus.ib...@gmail.com wrote:
On Mon, Sep 5, 2011
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde edited comment on CAMEL-3142 at 9/5/11 4:00 PM:
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
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 nominated
[
https://issues.apache.org/jira/browse/CAMEL-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097313#comment-13097313
]
Ioannis Canellos commented on CAMEL-4213:
-
@Claus: Indeed the TCCL is set (at
[
https://issues.apache.org/jira/browse/CAMEL-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097140#comment-13097140
]
Mathieu Lalonde edited comment on CAMEL-3142 at 9/5/11 9:12 PM:
[
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
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
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.
I
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
On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom seij...@gmail.com 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,
On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
ch...@die-schneider.net 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
On Mon, Sep 5, 2011 at 4:54 PM, Guillaume Nodet gno...@gmail.com 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
38 matches
Mail list logo
