[jira] [Assigned] (CAMEL-4378) camel-zookeper - Add osgi unit tests
[ https://issues.apache.org/jira/browse/CAMEL-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CAMEL-4378: --- Assignee: Freeman Fang > camel-zookeper - Add osgi unit tests > > > Key: CAMEL-4378 > URL: https://issues.apache.org/jira/browse/CAMEL-4378 > Project: Camel > Issue Type: Sub-task >Reporter: Claus Ibsen >Assignee: Freeman Fang >Priority: Minor > Fix For: 2.9.0 > > > We need osgi unit tests in > - camel-itest-karaf (easy as it just verify the component can be installed) > - camel-itest-osgi (testing the component in use in osgi) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4377) camel-zookeper - Add features.xml
[ https://issues.apache.org/jira/browse/CAMEL-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CAMEL-4377: --- Assignee: Freeman Fang > camel-zookeper - Add features.xml > - > > Key: CAMEL-4377 > URL: https://issues.apache.org/jira/browse/CAMEL-4377 > Project: Camel > Issue Type: Sub-task >Reporter: Claus Ibsen >Assignee: Freeman Fang >Priority: Minor > Fix For: 2.9.0 > > > The new camel-zookeper component need to be added to the features.xml file. A > possible osgi bundle is needed for zookeper if its not already osgi compliant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4227) Seda component doesn't block on its blocking queue
[ https://issues.apache.org/jira/browse/CAMEL-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-4227. Resolution: Fixed Thanks for the patch. I have marked CollectionProducer as @deprecated. I updated wiki page with the new option as well. > Seda component doesn't block on its blocking queue > -- > > Key: CAMEL-4227 > URL: https://issues.apache.org/jira/browse/CAMEL-4227 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.7.2 >Reporter: Michael Allman >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.9.0 > > Attachments: seda-blockWhenFull-patch.zip > > > While one can put an upper bound on the size of the blocking queue that the > seda component uses to queue messages, the seda component throws an exception > when it reaches that limit instead of blocking. My understanding of a > blocking queue is that the upper bound lets you put an upper bound on the > queue and block when it becomes full. The fact that the seda component throws > an exception makes the upper bound useless in practice, unless there is > supposed to be some kind of easy workaround. We have not found one, and it > looks like we will be rolling our own async component to compensate. :( > The basic issue is that SedaProducer calls BlockingQueue.add() instead of > BlockingQueue.put(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4227) Seda component doesn't block on its blocking queue
[ https://issues.apache.org/jira/browse/CAMEL-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-4227: -- Assignee: Claus Ibsen > Seda component doesn't block on its blocking queue > -- > > Key: CAMEL-4227 > URL: https://issues.apache.org/jira/browse/CAMEL-4227 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.7.2 >Reporter: Michael Allman >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.9.0 > > Attachments: seda-blockWhenFull-patch.zip > > > While one can put an upper bound on the size of the blocking queue that the > seda component uses to queue messages, the seda component throws an exception > when it reaches that limit instead of blocking. My understanding of a > blocking queue is that the upper bound lets you put an upper bound on the > queue and block when it becomes full. The fact that the seda component throws > an exception makes the upper bound useless in practice, unless there is > supposed to be some kind of easy workaround. We have not found one, and it > looks like we will be rolling our own async component to compensate. :( > The basic issue is that SedaProducer calls BlockingQueue.add() instead of > BlockingQueue.put(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4376) Deprecate DefaultEndpoint constructors that create partially constructed endpoints
[ https://issues.apache.org/jira/browse/CAMEL-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090763#comment-13090763 ] Claus Ibsen commented on CAMEL-4376: And I would not change anything in a patch release such as camel 2.8.1. If we are to do anything then do that only in 2.9 release. > Deprecate DefaultEndpoint constructors that create partially constructed > endpoints > --- > > Key: CAMEL-4376 > URL: https://issues.apache.org/jira/browse/CAMEL-4376 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.8.1, 2.9.0 > > > There are 2 DefaultEndpoint constructors that are not necessary, are not > really used (and as the doc says they should not be used anyway) that I > intend to remove. One issue is that during endpoint construction because the > component and context are set later services from the context such as type > converters are not yet available which may lead to errors (or unnecessarily > complicated code). > protected DefaultEndpoint(String, CamelContext); > protected DefaultEndpoint(String); > possibly > protected DefaultEndpoint(); > There are also a number of components defining constructors that just mimic > those that are not necessary and not used either. Those can be removed now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4376) Deprecate DefaultEndpoint constructors that create partially constructed endpoints
[ https://issues.apache.org/jira/browse/CAMEL-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090762#comment-13090762 ] Claus Ibsen commented on CAMEL-4376: The default ctr should definitely be there as people use that to create endpoints in eg spring xml file For example < set some options here > > Deprecate DefaultEndpoint constructors that create partially constructed > endpoints > --- > > Key: CAMEL-4376 > URL: https://issues.apache.org/jira/browse/CAMEL-4376 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.8.1, 2.9.0 > > > There are 2 DefaultEndpoint constructors that are not necessary, are not > really used (and as the doc says they should not be used anyway) that I > intend to remove. One issue is that during endpoint construction because the > component and context are set later services from the context such as type > converters are not yet available which may lead to errors (or unnecessarily > complicated code). > protected DefaultEndpoint(String, CamelContext); > protected DefaultEndpoint(String); > possibly > protected DefaultEndpoint(); > There are also a number of components defining constructors that just mimic > those that are not necessary and not used either. Those can be removed now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4378) camel-zookeper - Add osgi unit tests
camel-zookeper - Add osgi unit tests Key: CAMEL-4378 URL: https://issues.apache.org/jira/browse/CAMEL-4378 Project: Camel Issue Type: Sub-task Reporter: Claus Ibsen Priority: Minor Fix For: 2.9.0 We need osgi unit tests in - camel-itest-karaf (easy as it just verify the component can be installed) - camel-itest-osgi (testing the component in use in osgi) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4377) camel-zookeper - Add features.xml
camel-zookeper - Add features.xml - Key: CAMEL-4377 URL: https://issues.apache.org/jira/browse/CAMEL-4377 Project: Camel Issue Type: Sub-task Reporter: Claus Ibsen Priority: Minor Fix For: 2.9.0 The new camel-zookeper component need to be added to the features.xml file. A possible osgi bundle is needed for zookeper if its not already osgi compliant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4374. - Resolution: Fixed Applied the patch into trunk. > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090746#comment-13090746 ] Willem Jiang commented on CAMEL-4374: - As there a lots of change on the camel-test between 2.8.0 and 2.9-SNAPSHOT, I'm not plan to merge the patch into camel-2.8.x, user can work around the issue by applying the patch that Andreas provided if they are using Camel 2.8.x. > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CAMEL-4374: Fix Version/s: (was: 2.8.1) > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090744#comment-13090744 ] Willem Jiang commented on CAMEL-4374: - The SpringTestSupport of camel-testng is not synced with the one of camel-test. I just updated the codes and it fix the bug that Andreas met. > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-2472) A Zookeeper Component for Camel
[ https://issues.apache.org/jira/browse/CAMEL-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved CAMEL-2472. Resolution: Fixed > A Zookeeper Component for Camel > --- > > Key: CAMEL-2472 > URL: https://issues.apache.org/jira/browse/CAMEL-2472 > Project: Camel > Issue Type: New Feature >Reporter: Stephen Gargan >Assignee: Hadrian Zbarcea > Fix For: 2.9.0 > > Attachments: zookeeper-3.3.0.jar, zookeeper.patch, zookeeper.patch > > > I've put together a basic component implementation for interacting with a > Zookeeper Cluster (http://hadoop.apache.org/zookeeper/). Its a reasonably > complete implementation, providing much of the available functionality of the > 3.3.0 api. The main features being the abilities to > - Creation of nodes in any of the ZooKeeper create modes. > - Get and Set the data contents of arbitrary cluster nodes. > - Create and retrieve the list the child nodes attached to a particular node. > - A Distributed RoutePoilcy that leverages a Leader election coordinated by > ZK to determine if exchanges should get processed. > It's build against the Head of Zookeepers current release stream, 3.3.0. > Zookeeper (Like the rest of the Hadoop project) uses a custom ant build and > so there are no SNAPSHOTS. This is a bit of an impediment, but its likely > that the Zookeepr project will cut a release before too long. In the > meantime, to get some soak time in the real world, I've attached a freshly > cut jar from the head today so you can try the component out. It can be > installed using the following command. > mvn install:install-file -DgroupId=org.apache.zookeeper > -DartifactId=zookeeper -Dversion=3.3.0 -Dpackaging=jar > -Dfile=zookeeper-3.3.0.jar > I'm putting together some documentation and will be happy to add it to the > wiki if the component gets picked up. I hope the project can find this useful. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-2472) A Zookeeper Component for Camel
[ https://issues.apache.org/jira/browse/CAMEL-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090666#comment-13090666 ] Hadrian Zbarcea commented on CAMEL-2472: Patch applied in r1161306 with a minor change accounting for cschneider's refactoring and one failing test I am looking into. There are a few other minor issues I will look into related to forkmode=pertest, that shouldn't be necessary, Tread.sleeps etc. I'll get those fixed and close this issue. The documentation is already done. Excellent contribution Stephen, much appreciated. > A Zookeeper Component for Camel > --- > > Key: CAMEL-2472 > URL: https://issues.apache.org/jira/browse/CAMEL-2472 > Project: Camel > Issue Type: New Feature >Reporter: Stephen Gargan >Assignee: Hadrian Zbarcea > Fix For: 2.9.0 > > Attachments: zookeeper-3.3.0.jar, zookeeper.patch, zookeeper.patch > > > I've put together a basic component implementation for interacting with a > Zookeeper Cluster (http://hadoop.apache.org/zookeeper/). Its a reasonably > complete implementation, providing much of the available functionality of the > 3.3.0 api. The main features being the abilities to > - Creation of nodes in any of the ZooKeeper create modes. > - Get and Set the data contents of arbitrary cluster nodes. > - Create and retrieve the list the child nodes attached to a particular node. > - A Distributed RoutePoilcy that leverages a Leader election coordinated by > ZK to determine if exchanges should get processed. > It's build against the Head of Zookeepers current release stream, 3.3.0. > Zookeeper (Like the rest of the Hadoop project) uses a custom ant build and > so there are no SNAPSHOTS. This is a bit of an impediment, but its likely > that the Zookeepr project will cut a release before too long. In the > meantime, to get some soak time in the real world, I've attached a freshly > cut jar from the head today so you can try the component out. It can be > installed using the following command. > mvn install:install-file -DgroupId=org.apache.zookeeper > -DartifactId=zookeeper -Dversion=3.3.0 -Dpackaging=jar > -Dfile=zookeeper-3.3.0.jar > I'm putting together some documentation and will be happy to add it to the > wiki if the component gets picked up. I hope the project can find this useful. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4227) Seda component doesn't block on its blocking queue
[
https://issues.apache.org/jira/browse/CAMEL-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lalonde updated CAMEL-4227:
---
Attachment: seda-blockWhenFull-patch.zip
This archive contains 1 new test & 2 patches:
* seda-blockWhenNotFull-20110824.patch ("svn diff ." in .../camel/seda (main))
* seda-blockWhenFull-test-20110824.patch ("svn diff ." in .../camel/seda (test)
* SedaBlockWhenFullTest.java (to be added to .../camel/seda (test))
Let me know if I need to make further changes. I've added the ASF license to
the new file.
> Seda component doesn't block on its blocking queue
> --
>
> Key: CAMEL-4227
> URL: https://issues.apache.org/jira/browse/CAMEL-4227
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.7.2
>Reporter: Michael Allman
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments: seda-blockWhenFull-patch.zip
>
>
> While one can put an upper bound on the size of the blocking queue that the
> seda component uses to queue messages, the seda component throws an exception
> when it reaches that limit instead of blocking. My understanding of a
> blocking queue is that the upper bound lets you put an upper bound on the
> queue and block when it becomes full. The fact that the seda component throws
> an exception makes the upper bound useless in practice, unless there is
> supposed to be some kind of easy workaround. We have not found one, and it
> looks like we will be rolling our own async component to compensate. :(
> The basic issue is that SedaProducer calls BlockingQueue.add() instead of
> BlockingQueue.put().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Scope of org.apache.camel.spi
Actually I think it would be better to put annotations in their own package: org.apache.camel.annotation org.apache.camel.annotation.management org.apache.camel.annotation.etc... Then it won't feel weird that org.apache.camel.management is not there My $0.02, Hadrian On 08/24/2011 01:55 PM, Christian Schneider wrote: Actually JDk and spring are two very good examples how to not do it :-) I guess in the JDK no one cared as you will always have it. Btw. I guess everyone agrees that the JDK is a mess architecturally. Btw. he JDK extensions ship separate API jars like JAXB api. So they seem to have learned. In spring I suspect it is on purpose. They could provide API jars that make you independent of their implementation. By combining API and impl they force you into having a hard dependency on spring. You had to remove the spring JMX annotations as we did not want to have their impl. If they had cleanly separated their API from the impl we could have kept the one API jar with the annotations and just implemented them ourself when running outside of spring. So having the annotations in the management package is a very bad idea. A subpackage would work on a pure simple package perspective but I think it would be bad to have a top level package with implementations and a subpackage with the API. We can move around the management stuff at the moment as my commit changed it anyway. So before Camel 2.9 comes out we are free to move them. api.management of course only makes sense if we intend to put more stuff there but I think it would be a good idea to do so. Having a top level api package will also make it easier to create a pure API jar for camel 3.0. I think it would be strange if the API jar would contain org.apache.camel org.apache.camel.spi org.apache.camel.management.annotation but not org.apache.camel.management Btw management.annotation is not enough anyway as we have more management interfaces that have to live in the API space. So management.api would be better but I would prefer to have api at the top level so the user can clearly see that everything api.* is part of the API. In any case we need to separate the management API from the management impl classes. If we do not do it then we have no chance to avoid cycles. Besides that how should we make it possible that the components only need to depend on the API if we mix things. For example a component may want to use the management annotations or another management interface but it should not know the impl. Btw. the event classes should also be part of the API as they are necessary to understand management events. As they live in a separate package already the does not depend on the management impl I did not move them but they would be better placed in api.management.events. Christian Am 24.08.2011 19:12, schrieb Claus Ibsen: On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider wrote: Hi Claus, we can do that but then we have to move the impl classes somewhere else. We may not mix impl and api in the same package. This is what leads to cycles. That is actually common. For example look at the JDK Map (API) and HashMap (Impl) are both in java.util package. However these annotations are not regular interfaces, that end users is supposed to implement. Or for example that we in the Apache Camel provides 2+ different implements of those annotations. As an end user I would feel natural these annotations are in the mangement package as they are part of the management (end user) API in Camel. The Spring framework put these annotations at http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html We could also have a annotation subpackage (org.apache.camel.management.annotation) but we usually dont have that, eg there are no annotation package for @Consume, @Produce, @EndpointInject etc. Alternatively we could move them in the root package, but as you said there is already plenty of APIs in that package. Putting them in org.apache.camel.api seems a bit weird, as they would be the only pieces in there. And for Camel 2.x we should keep the API stable and not move around stuff all the time. Christian Am 24.08.2011 17:53, schrieb Claus Ibsen: On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider wrote: So where do you propose to put them? 1. org.apache.camel 2. org.apache.camel.api.management I propose to put them here, where they where already 3. org.apache.camel.management These annotations are part of the management API in Camel and IMHO should be in that package. I propose to go with 2 and create an api package with subpackages so we can structure org.apache.camel better. In the long run I would like to also move the whole camel api into an api package to make it clearer but that will probably create too much incompatibility. Christian Am 24.08.2011 14:13, schrieb Claus Ibsen: On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: I w
[jira] [Created] (CAMEL-4376) Deprecate DefaultEndpoint constructors that create partially constructed endpoints
Deprecate DefaultEndpoint constructors that create partially constructed endpoints --- Key: CAMEL-4376 URL: https://issues.apache.org/jira/browse/CAMEL-4376 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.8.0 Reporter: Hadrian Zbarcea Assignee: Hadrian Zbarcea Fix For: 2.8.1, 2.9.0 There are 2 DefaultEndpoint constructors that are not necessary, are not really used (and as the doc says they should not be used anyway) that I intend to remove. One issue is that during endpoint construction because the component and context are set later services from the context such as type converters are not yet available which may lead to errors (or unnecessarily complicated code). protected DefaultEndpoint(String, CamelContext); protected DefaultEndpoint(String); possibly protected DefaultEndpoint(); There are also a number of components defining constructors that just mimic those that are not necessary and not used either. Those can be removed now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[HEADS-UP] Removing error prone DefaultEndpoint constructors
Hi, There are 2 DefaultEndpoint constructors that are not necessary, are not really used (and as the doc says they should not be used anyway) that I intend to remove. One issue is that during endpoint construction because the component and context are set later services from the context such as type converters are not yet available which may lead to errors (or unnecessarily complicated code). protected DefaultEndpoint(String, CamelContext); protected DefaultEndpoint(String); There are also a number of components defining constructors that just mimic those that are not necessary and not used either. Those can be removed now. Not sure if they should be just deprecated for now and removed probably in 3.0 or just remove them now. I'll create a jira for this. Thoughts? Hadrian
Re: Scope of org.apache.camel.spi
Actually JDk and spring are two very good examples how to not do it :-) I guess in the JDK no one cared as you will always have it. Btw. I guess everyone agrees that the JDK is a mess architecturally. Btw. he JDK extensions ship separate API jars like JAXB api. So they seem to have learned. In spring I suspect it is on purpose. They could provide API jars that make you independent of their implementation. By combining API and impl they force you into having a hard dependency on spring. You had to remove the spring JMX annotations as we did not want to have their impl. If they had cleanly separated their API from the impl we could have kept the one API jar with the annotations and just implemented them ourself when running outside of spring. So having the annotations in the management package is a very bad idea. A subpackage would work on a pure simple package perspective but I think it would be bad to have a top level package with implementations and a subpackage with the API. We can move around the management stuff at the moment as my commit changed it anyway. So before Camel 2.9 comes out we are free to move them. api.management of course only makes sense if we intend to put more stuff there but I think it would be a good idea to do so. Having a top level api package will also make it easier to create a pure API jar for camel 3.0. I think it would be strange if the API jar would contain org.apache.camel org.apache.camel.spi org.apache.camel.management.annotation but not org.apache.camel.management Btw management.annotation is not enough anyway as we have more management interfaces that have to live in the API space. So management.api would be better but I would prefer to have api at the top level so the user can clearly see that everything api.* is part of the API. In any case we need to separate the management API from the management impl classes. If we do not do it then we have no chance to avoid cycles. Besides that how should we make it possible that the components only need to depend on the API if we mix things. For example a component may want to use the management annotations or another management interface but it should not know the impl. Btw. the event classes should also be part of the API as they are necessary to understand management events. As they live in a separate package already the does not depend on the management impl I did not move them but they would be better placed in api.management.events. Christian Am 24.08.2011 19:12, schrieb Claus Ibsen: On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider wrote: Hi Claus, we can do that but then we have to move the impl classes somewhere else. We may not mix impl and api in the same package. This is what leads to cycles. That is actually common. For example look at the JDK Map (API) and HashMap (Impl) are both in java.util package. However these annotations are not regular interfaces, that end users is supposed to implement. Or for example that we in the Apache Camel provides 2+ different implements of those annotations. As an end user I would feel natural these annotations are in the mangement package as they are part of the management (end user) API in Camel. The Spring framework put these annotations at http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html We could also have a annotation subpackage (org.apache.camel.management.annotation) but we usually dont have that, eg there are no annotation package for @Consume, @Produce, @EndpointInject etc. Alternatively we could move them in the root package, but as you said there is already plenty of APIs in that package. Putting them in org.apache.camel.api seems a bit weird, as they would be the only pieces in there. And for Camel 2.x we should keep the API stable and not move around stuff all the time. Christian Am 24.08.2011 17:53, schrieb Claus Ibsen: On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider wrote: So where do you propose to put them? 1. org.apache.camel 2. org.apache.camel.api.management I propose to put them here, where they where already 3. org.apache.camel.management These annotations are part of the management API in Camel and IMHO should be in that package. I propose to go with 2 and create an api package with subpackages so we can structure org.apache.camel better. In the long run I would like to also move the whole camel api into an api package to make it clearer but that will probably create too much incompatibility. Christian Am 24.08.2011 14:13, schrieb Claus Ibsen: On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: I wonder what our scope for the org.apache.camel.spi package is vs the org.apache.camel (API) package. I know two valid definitions for API vs SPI: 1) API interfaces are called by the user to invoke functionality of the framework. So API interfaces are implemented by the framework. S
Re: Scope of org.apache.camel.spi
On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider wrote: > Hi Claus, > > we can do that but then we have to move the impl classes somewhere else. We > may not mix impl and api in the same package. This is what leads to cycles. > That is actually common. For example look at the JDK Map (API) and HashMap (Impl) are both in java.util package. However these annotations are not regular interfaces, that end users is supposed to implement. Or for example that we in the Apache Camel provides 2+ different implements of those annotations. As an end user I would feel natural these annotations are in the mangement package as they are part of the management (end user) API in Camel. The Spring framework put these annotations at http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html We could also have a annotation subpackage (org.apache.camel.management.annotation) but we usually dont have that, eg there are no annotation package for @Consume, @Produce, @EndpointInject etc. Alternatively we could move them in the root package, but as you said there is already plenty of APIs in that package. Putting them in org.apache.camel.api seems a bit weird, as they would be the only pieces in there. And for Camel 2.x we should keep the API stable and not move around stuff all the time. > Christian > > > Am 24.08.2011 17:53, schrieb Claus Ibsen: >> >> On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider >> wrote: >>> >>> So where do you propose to put them? >>> >>> 1. org.apache.camel >>> 2. org.apache.camel.api.management >>> >> I propose to put them here, where they where already >> 3. org.apache.camel.management >> >> These annotations are part of the management API in Camel and IMHO >> should be in that package. >> >> >> >>> I propose to go with 2 and create an api package with subpackages so we >>> can >>> structure org.apache.camel better. In the long run I would like to also >>> move >>> the whole camel api into an api package to make it clearer but that will >>> probably create too much incompatibility. >>> >>> Christian >>> >>> >>> Am 24.08.2011 14:13, schrieb Claus Ibsen: On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: > > I wonder what our scope for the org.apache.camel.spi package is vs the > org.apache.camel (API) package. > > I know two valid definitions for API vs SPI: > > 1) API interfaces are called by the user to invoke functionality of the > framework. So API interfaces are implemented by the framework. SPI > interfaces are implemented by the user to change functionality of the > framework or for callbacks > 2) SPI interfaces are for third party modules while API interfaces are > for > users > > So the current case for me is the new JMX annotations. Are they SPI > interfaces or API interfaces? > They are API interfaces. Just like @Consumer, @Produce and any of the other API Camel annotations we have. Its just that these annotations is for management enabling your business logic / custom components or whatnot. > So what is your opinion about the specific and the general case. > > As a side question: The org.apache.camel package has grown quite large. > I > think we should create specialized packages for it. As we are talking > about > the camel API org.apache.camel.api.* would be a good name in my > opinion. > So > the questions are: Should we create such specialized packages? Should > we > move API parts there? Should we only use the new packages for new > stuff? > > Christian > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > >>> >>> -- >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> Talend Application Integration Division http://www.talend.com >>> >>> >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: Scope of org.apache.camel.spi
Hi Claus, we can do that but then we have to move the impl classes somewhere else. We may not mix impl and api in the same package. This is what leads to cycles. Christian Am 24.08.2011 17:53, schrieb Claus Ibsen: On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider wrote: So where do you propose to put them? 1. org.apache.camel 2. org.apache.camel.api.management I propose to put them here, where they where already 3. org.apache.camel.management These annotations are part of the management API in Camel and IMHO should be in that package. I propose to go with 2 and create an api package with subpackages so we can structure org.apache.camel better. In the long run I would like to also move the whole camel api into an api package to make it clearer but that will probably create too much incompatibility. Christian Am 24.08.2011 14:13, schrieb Claus Ibsen: On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: I wonder what our scope for the org.apache.camel.spi package is vs the org.apache.camel (API) package. I know two valid definitions for API vs SPI: 1) API interfaces are called by the user to invoke functionality of the framework. So API interfaces are implemented by the framework. SPI interfaces are implemented by the user to change functionality of the framework or for callbacks 2) SPI interfaces are for third party modules while API interfaces are for users So the current case for me is the new JMX annotations. Are they SPI interfaces or API interfaces? They are API interfaces. Just like @Consumer, @Produce and any of the other API Camel annotations we have. Its just that these annotations is for management enabling your business logic / custom components or whatnot. So what is your opinion about the specific and the general case. As a side question: The org.apache.camel package has grown quite large. I think we should create specialized packages for it. As we are talking about the camel API org.apache.camel.api.* would be a good name in my opinion. So the questions are: Should we create such specialized packages? Should we move API parts there? Should we only use the new packages for new stuff? Christian -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Scope of org.apache.camel.spi
On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider wrote: > So where do you propose to put them? > > 1. org.apache.camel > 2. org.apache.camel.api.management > I propose to put them here, where they where already 3. org.apache.camel.management These annotations are part of the management API in Camel and IMHO should be in that package. > I propose to go with 2 and create an api package with subpackages so we can > structure org.apache.camel better. In the long run I would like to also move > the whole camel api into an api package to make it clearer but that will > probably create too much incompatibility. > > Christian > > > Am 24.08.2011 14:13, schrieb Claus Ibsen: >> >> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider >> wrote: >>> >>> I wonder what our scope for the org.apache.camel.spi package is vs the >>> org.apache.camel (API) package. >>> >>> I know two valid definitions for API vs SPI: >>> >>> 1) API interfaces are called by the user to invoke functionality of the >>> framework. So API interfaces are implemented by the framework. SPI >>> interfaces are implemented by the user to change functionality of the >>> framework or for callbacks >>> 2) SPI interfaces are for third party modules while API interfaces are >>> for >>> users >>> >>> So the current case for me is the new JMX annotations. Are they SPI >>> interfaces or API interfaces? >>> >> They are API interfaces. Just like @Consumer, @Produce and any of the >> other API Camel annotations we have. >> Its just that these annotations is for management enabling your >> business logic / custom components or whatnot. >> >> >> >>> So what is your opinion about the specific and the general case. >>> >>> As a side question: The org.apache.camel package has grown quite large. I >>> think we should create specialized packages for it. As we are talking >>> about >>> the camel API org.apache.camel.api.* would be a good name in my opinion. >>> So >>> the questions are: Should we create such specialized packages? Should we >>> move API parts there? Should we only use the new packages for new stuff? >>> >>> Christian >>> >>> >>> -- >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> Talend Application Integration Division http://www.talend.com >>> >>> >> >> > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
Re: camel FTP not polling the files
I added the recursive=true option but same thing. Process is not polling the files. -- View this message in context: http://camel.465427.n5.nabble.com/camel-FTP-not-polling-the-files-tp4727841p4730805.html Sent from the Camel Development mailing list archive at Nabble.com.
[jira] [Commented] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090277#comment-13090277 ] Willem Jiang commented on CAMEL-4374: - @Andreas I just ran a test within camel-test in trunk, the test is passed. But there is something wrong with the camel-testng, I will dig it more tomorrow. > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-4374: --- Assignee: Willem Jiang > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4373) Upgrade to xstream 1.4.1
[ https://issues.apache.org/jira/browse/CAMEL-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090248#comment-13090248 ] Jean-Baptiste Onofré commented on CAMEL-4373: - Revision 1161112. I let this Jira open waiting for the ServiceMix bundles release including xstream 1.4.1_1. > Upgrade to xstream 1.4.1 > > > Key: CAMEL-4373 > URL: https://issues.apache.org/jira/browse/CAMEL-4373 > Project: Camel > Issue Type: Task > Components: camel-xstream >Affects Versions: 2.9.0 >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.9.0 > > > XStream 1.4.1 has been released which fixed an dependency issue in 1.4.0. We > should upgrade to it. The old xpp3 is now yet again the default pull parser. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4375) FilterCreateCamelContextPerClassTest is wrong configured
[ https://issues.apache.org/jira/browse/CAMEL-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-4375: --- Assignee: Willem Jiang > FilterCreateCamelContextPerClassTest is wrong configured > > > Key: CAMEL-4375 > URL: https://issues.apache.org/jira/browse/CAMEL-4375 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz >Assignee: Willem Jiang > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4375.patch > > > The FilterCreateCamelContextPerClassTest is wrong configured. The > isCreateCamelContextPerClass() should return true as written in the comment > but currently returns false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Scope of org.apache.camel.spi
So where do you propose to put them? 1. org.apache.camel 2. org.apache.camel.api.management I propose to go with 2 and create an api package with subpackages so we can structure org.apache.camel better. In the long run I would like to also move the whole camel api into an api package to make it clearer but that will probably create too much incompatibility. Christian Am 24.08.2011 14:13, schrieb Claus Ibsen: On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: I wonder what our scope for the org.apache.camel.spi package is vs the org.apache.camel (API) package. I know two valid definitions for API vs SPI: 1) API interfaces are called by the user to invoke functionality of the framework. So API interfaces are implemented by the framework. SPI interfaces are implemented by the user to change functionality of the framework or for callbacks 2) SPI interfaces are for third party modules while API interfaces are for users So the current case for me is the new JMX annotations. Are they SPI interfaces or API interfaces? They are API interfaces. Just like @Consumer, @Produce and any of the other API Camel annotations we have. Its just that these annotations is for management enabling your business logic / custom components or whatnot. So what is your opinion about the specific and the general case. As a side question: The org.apache.camel package has grown quite large. I think we should create specialized packages for it. As we are talking about the camel API org.apache.camel.api.* would be a good name in my opinion. So the questions are: Should we create such specialized packages? Should we move API parts there? Should we only use the new packages for new stuff? Christian -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
[jira] [Commented] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090171#comment-13090171 ] Andreas Kuhtz commented on CAMEL-4374: -- @Willem You're right, but currently it doesn't support even a single camel context in the XML file and the patch shows at least this problem. I'm not sure if the problem could be solved if the debugger could be configured in the camel context via Spring XML ... > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090160#comment-13090160 ] Willem Jiang commented on CAMEL-4374: - @Andreas If there are more than one camel context in the spring application context, your patch can not work for this case. As the CamelSpringTestSupport it only try to start the first camel context, we need find other way to resolve this kind of issue. > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Scope of org.apache.camel.spi
On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider wrote: > I wonder what our scope for the org.apache.camel.spi package is vs the > org.apache.camel (API) package. > > I know two valid definitions for API vs SPI: > > 1) API interfaces are called by the user to invoke functionality of the > framework. So API interfaces are implemented by the framework. SPI > interfaces are implemented by the user to change functionality of the > framework or for callbacks > 2) SPI interfaces are for third party modules while API interfaces are for > users > > So the current case for me is the new JMX annotations. Are they SPI > interfaces or API interfaces? > They are API interfaces. Just like @Consumer, @Produce and any of the other API Camel annotations we have. Its just that these annotations is for management enabling your business logic / custom components or whatnot. > So what is your opinion about the specific and the general case. > > As a side question: The org.apache.camel package has grown quite large. I > think we should create specialized packages for it. As we are talking about > the camel API org.apache.camel.api.* would be a good name in my opinion. So > the questions are: Should we create such specialized packages? Should we > move API parts there? Should we only use the new packages for new stuff? > > Christian > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
[jira] [Created] (CAMEL-4375) FilterCreateCamelContextPerClassTest is wrong configured
FilterCreateCamelContextPerClassTest is wrong configured Key: CAMEL-4375 URL: https://issues.apache.org/jira/browse/CAMEL-4375 Project: Camel Issue Type: Bug Components: camel-test Affects Versions: 2.8.0 Reporter: Andreas Kuhtz Fix For: 2.8.1, 2.9.0 Attachments: camel-4375.patch The FilterCreateCamelContextPerClassTest is wrong configured. The isCreateCamelContextPerClass() should return true as written in the comment but currently returns false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4375) FilterCreateCamelContextPerClassTest is wrong configured
[ https://issues.apache.org/jira/browse/CAMEL-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuhtz updated CAMEL-4375: - Attachment: camel-4375.patch > FilterCreateCamelContextPerClassTest is wrong configured > > > Key: CAMEL-4375 > URL: https://issues.apache.org/jira/browse/CAMEL-4375 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4375.patch > > > The FilterCreateCamelContextPerClassTest is wrong configured. The > isCreateCamelContextPerClass() should return true as written in the comment > but currently returns false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuhtz updated CAMEL-4374: - Attachment: camel-4374.patch > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution. > However I think this could be improved by moving the > SpringCamelContext.setNoStart(true); to CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
The debugger doesn't work in the CamelSpringTestSupport with route defined in XML - Key: CAMEL-4374 URL: https://issues.apache.org/jira/browse/CAMEL-4374 Project: Camel Issue Type: Improvement Components: camel-test Affects Versions: 2.8.0 Reporter: Andreas Kuhtz Fix For: 2.8.1, 2.9.0 Attachments: camel-4374.patch The debugger doesn't work in the CamelSpringTestSupport with route defined in XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). I've created a patch with 2 new tests that show the problem and a solution. However I think this could be improved by moving the SpringCamelContext.setNoStart(true); to CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4374) The debugger doesn't work in the CamelSpringTestSupport with route defined in XML
[ https://issues.apache.org/jira/browse/CAMEL-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuhtz updated CAMEL-4374: - Description: The debugger doesn't work in the CamelSpringTestSupport with route defined in XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). I've created a patch with 2 new tests that show the problem and a solution (check the doSetup() method in the tests). However I think this could be improved by moving the SpringCamelContext.setNoStart(true); to CamelSpringTestSupport). was: The debugger doesn't work in the CamelSpringTestSupport with route defined in XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). I've created a patch with 2 new tests that show the problem and a solution. However I think this could be improved by moving the SpringCamelContext.setNoStart(true); to CamelSpringTestSupport). > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML > - > > Key: CAMEL-4374 > URL: https://issues.apache.org/jira/browse/CAMEL-4374 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.8.0 >Reporter: Andreas Kuhtz > Fix For: 2.8.1, 2.9.0 > > Attachments: camel-4374.patch > > > The debugger doesn't work in the CamelSpringTestSupport with route defined in > XML. This issue is related to CAMEL-4368 (closed and I cannot re-open). > I've created a patch with 2 new tests that show the problem and a solution > (check the doSetup() method in the tests). However I think this could be > improved by moving the SpringCamelContext.setNoStart(true); to > CamelSpringTestSupport). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4372) Add FiltersRef option for the Jetty component
[ https://issues.apache.org/jira/browse/CAMEL-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4372. - Resolution: Fixed Applied patch into the trunk. > Add FiltersRef option for the Jetty component > - > > Key: CAMEL-4372 > URL: https://issues.apache.org/jira/browse/CAMEL-4372 > Project: Camel > Issue Type: New Feature > Components: camel-jetty >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.9.0 > > > As there are lots of handy filter could be used in Jetty, it could be useful > if we can set the filter list for camel-jetty component. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4355) CxfRsProducer - Should use LRUSoftCache and start/stop the cache according to the producers lifecycle
[ https://issues.apache.org/jira/browse/CAMEL-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4355. - Resolution: Fixed Applied patch into trunk > CxfRsProducer - Should use LRUSoftCache and start/stop the cache according to > the producers lifecycle > - > > Key: CAMEL-4355 > URL: https://issues.apache.org/jira/browse/CAMEL-4355 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Affects Versions: 2.8.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.0 > > > The CxfRsProducer uses an internal LRUCache. Now we have a LRUSoftCache that > uses soft reference, so we can switch to use that directly. > Also the cache should be started/stopped in the doStart/doStop methods of the > CxfRsProducer itself, to ensure proper house cleaning. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4368) The debug doesn't work in the CamelSpringTestSupport
[ https://issues.apache.org/jira/browse/CAMEL-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4368. - Resolution: Fixed Applied patch into trunk and camel-2.8.x branch. > The debug doesn't work in the CamelSpringTestSupport > > > Key: CAMEL-4368 > URL: https://issues.apache.org/jira/browse/CAMEL-4368 > Project: Camel > Issue Type: Improvement > Components: camel-test >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.8.1, 2.9.0 > > > Here is the mail thread about this issue. > http://camel.465427.n5.nabble.com/camel-testng-Start-debugger-with-CamelSpringTestSupport-tp4716094p4716094.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4370) It's hardly possible to use all expression of the Simple language to create file names in the file component
[
https://issues.apache.org/jira/browse/CAMEL-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4370.
Resolution: Fixed
Fix Version/s: 2.9.0
2.8.1
Thanks for reporting.
> It's hardly possible to use all expression of the Simple language to create
> file names in the file component
>
>
> Key: CAMEL-4370
> URL: https://issues.apache.org/jira/browse/CAMEL-4370
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.7.1
>Reporter: Sergey Zhemzhitsky
>Assignee: Claus Ibsen
> Labels: camel-file
> Fix For: 2.8.1, 2.9.0
>
>
> Sometimes it can be necessary to use custom headers to create a file name.
> For example, I declare my file endpoint in the following manner:
> {code}
>
> uri="file://rootFolder?move=.backup&moveFailed=.error/${header.CustomHeader}"
> />
>
>
> {code}
> The header "CustomHeader" cannot be read because of the following snippets of
> code in the org.apache.camel.component.file.GenericFile
> {code}
> /**
> * Bind this GenericFile to an Exchange
> */
> public void bindToExchange(Exchange exchange) {
> exchange.setProperty(FileComponent.FILE_EXCHANGE_FILE, this);
> GenericFileMessage in = new GenericFileMessage(this);
> exchange.setIn(in);
> populateHeaders(in);
> }
> /**
> * Populates the {@link GenericFileMessage} relevant headers
> *
> * @param message the message to populate with headers
> */
> public void populateHeaders(GenericFileMessage message) {
> if (message != null) {
> message.setHeader(Exchange.FILE_NAME_ONLY, getFileNameOnly());
> message.setHeader(Exchange.FILE_NAME, getFileName());
> message.setHeader("CamelFileAbsolute", isAbsolute());
> message.setHeader("CamelFileAbsolutePath", getAbsoluteFilePath());
> if (isAbsolute()) {
> message.setHeader(Exchange.FILE_PATH, getAbsoluteFilePath());
> } else {
> // we must normalize path according to protocol if we build our
> own paths
> String path = normalizePathToProtocol(getEndpointPath() +
> File.separator + getRelativeFilePath());
> message.setHeader(Exchange.FILE_PATH, path);
> }
> message.setHeader("CamelFileRelativePath", getRelativeFilePath());
> message.setHeader(Exchange.FILE_PARENT, getParent());
> if (getFileLength() >= 0) {
> message.setHeader("CamelFileLength", getFileLength());
> }
> if (getLastModified() > 0) {
> message.setHeader(Exchange.FILE_LAST_MODIFIED, new
> Date(getLastModified()));
> }
> }
> }
> {code}
> As you can see a new "in" message is created and not all the headers from the
> original message are copied to it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4373) Upgrade to xstream 1.4.1
[ https://issues.apache.org/jira/browse/CAMEL-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned CAMEL-4373: --- Assignee: Jean-Baptiste Onofré > Upgrade to xstream 1.4.1 > > > Key: CAMEL-4373 > URL: https://issues.apache.org/jira/browse/CAMEL-4373 > Project: Camel > Issue Type: Task > Components: camel-xstream >Affects Versions: 2.9.0 >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.9.0 > > > XStream 1.4.1 has been released which fixed an dependency issue in 1.4.0. We > should upgrade to it. The old xpp3 is now yet again the default pull parser. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4373) Upgrade to xstream 1.4.1
Upgrade to xstream 1.4.1 Key: CAMEL-4373 URL: https://issues.apache.org/jira/browse/CAMEL-4373 Project: Camel Issue Type: Task Components: camel-xstream Affects Versions: 2.9.0 Reporter: Claus Ibsen Priority: Minor Fix For: 2.9.0 XStream 1.4.1 has been released which fixed an dependency issue in 1.4.0. We should upgrade to it. The old xpp3 is now yet again the default pull parser. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4372) Add FiltersRef option for the Jetty component
Add FiltersRef option for the Jetty component - Key: CAMEL-4372 URL: https://issues.apache.org/jira/browse/CAMEL-4372 Project: Camel Issue Type: New Feature Components: camel-jetty Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.9.0 As there are lots of handy filter could be used in Jetty, it could be useful if we can set the filter list for camel-jetty component. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4370) It's hardly possible to use all expression of the Simple language to create file names in the file component
[
https://issues.apache.org/jira/browse/CAMEL-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-4370:
--
Assignee: Claus Ibsen
> It's hardly possible to use all expression of the Simple language to create
> file names in the file component
>
>
> Key: CAMEL-4370
> URL: https://issues.apache.org/jira/browse/CAMEL-4370
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.7.1
>Reporter: Sergey Zhemzhitsky
>Assignee: Claus Ibsen
> Labels: camel-file
>
> Sometimes it can be necessary to use custom headers to create a file name.
> For example, I declare my file endpoint in the following manner:
> {code}
>
> uri="file://rootFolder?move=.backup&moveFailed=.error/${header.CustomHeader}"
> />
>
>
> {code}
> The header "CustomHeader" cannot be read because of the following snippets of
> code in the org.apache.camel.component.file.GenericFile
> {code}
> /**
> * Bind this GenericFile to an Exchange
> */
> public void bindToExchange(Exchange exchange) {
> exchange.setProperty(FileComponent.FILE_EXCHANGE_FILE, this);
> GenericFileMessage in = new GenericFileMessage(this);
> exchange.setIn(in);
> populateHeaders(in);
> }
> /**
> * Populates the {@link GenericFileMessage} relevant headers
> *
> * @param message the message to populate with headers
> */
> public void populateHeaders(GenericFileMessage message) {
> if (message != null) {
> message.setHeader(Exchange.FILE_NAME_ONLY, getFileNameOnly());
> message.setHeader(Exchange.FILE_NAME, getFileName());
> message.setHeader("CamelFileAbsolute", isAbsolute());
> message.setHeader("CamelFileAbsolutePath", getAbsoluteFilePath());
> if (isAbsolute()) {
> message.setHeader(Exchange.FILE_PATH, getAbsoluteFilePath());
> } else {
> // we must normalize path according to protocol if we build our
> own paths
> String path = normalizePathToProtocol(getEndpointPath() +
> File.separator + getRelativeFilePath());
> message.setHeader(Exchange.FILE_PATH, path);
> }
> message.setHeader("CamelFileRelativePath", getRelativeFilePath());
> message.setHeader(Exchange.FILE_PARENT, getParent());
> if (getFileLength() >= 0) {
> message.setHeader("CamelFileLength", getFileLength());
> }
> if (getLastModified() > 0) {
> message.setHeader(Exchange.FILE_LAST_MODIFIED, new
> Date(getLastModified()));
> }
> }
> }
> {code}
> As you can see a new "in" message is created and not all the headers from the
> original message are copied to it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
