[IMPORTANT] - Changing API - Must document changes in release notes
Hi The API in camel-core have changed on trunk recently by the works of Christian S. I just to remind that its important to notice all the API breaking changes in the API section in the release notes. I have noticed that the release notes hasn't been updated accordingly to changes. I suggest to update the release notes at the time when you commit changes, as then you wont forget. What we need to put in there, is for example when a class has been *moved* to a new package, which mean there is not even an old @deprecated class. We ought also to mention important classe which may have been @deprecated in favor of some other class etc. Our user base should have this information up-front so they can take that into account, in their migration plans. -- 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] [Resolved] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-4351.
-
Resolution: Fixed
Fix Version/s: 2.9.0
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Fix For: 2.9.0
>
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3521) OsgiLifecycleStrategy - To register and unregister camel services in OSGi service registry on-the-fly
[ https://issues.apache.org/jira/browse/CAMEL-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-3521: --- Assignee: Willem Jiang (was: Gert Vanthienen) > OsgiLifecycleStrategy - To register and unregister camel services in OSGi > service registry on-the-fly > - > > Key: CAMEL-3521 > URL: https://issues.apache.org/jira/browse/CAMEL-3521 > Project: Camel > Issue Type: New Feature > Components: osgi >Affects Versions: 2.5.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang > Fix For: 2.9.0, Future > > > In camel-core-osgi we got the osgi integration with Camel. > Currently we got OsgiCamelContextPublisher which can register/unregister > CamelContext in OSGi service registry. > Its based on Camel's EventNotifier. > Instead we should use org.apache.camel.spi.LifecycleStrategy instead. It has > more fine grained events. > That allows us to register much more > - CamelContext > - Component > - Endpoint > - Route > - Service > - ThreadPool > - ErrorHandler -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4350) Camel-jdbc with List has arbitrary column order
[ https://issues.apache.org/jira/browse/CAMEL-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094331#comment-13094331 ] Claus Ibsen commented on CAMEL-4350: Yeah fell free to provide a unit test for camel-sql as well. > Camel-jdbc with List has arbitrary column order > > > Key: CAMEL-4350 > URL: https://issues.apache.org/jira/browse/CAMEL-4350 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc, camel-sql >Affects Versions: 2.7.1 > Environment: java 1.6 >Reporter: Julian Cable >Assignee: Mathieu Lalonde >Priority: Minor > Fix For: 2.9.0 > > Attachments: camel-jdbc_keyOrdering.tar > > > The following route works but the order of the columns is dependent on the > natural ordering of the hashmap. Target systems will have an expectation of > the order of the data. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id, value1, value2 FROM mytable > > > > > > > Either there needs to be a property for csv that allows hash key ordering to > be specified, or an option to sort the keys, e.g. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id as col1, value1 as col2, value2 as col3 FROM > mytable > > > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Camel - Build # 1316 - Fixed
The Apache Jenkins build system has built Camel (build #1316) Status: Fixed Check console output at https://builds.apache.org/job/Camel/1316/ to view the results.
[jira] [Updated] (CAMEL-4397) add route support for Hazelcast distributed locking/unlocking
[
https://issues.apache.org/jira/browse/CAMEL-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-4397:
-
Description:
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from("direct:processLocked")
.doTry()
.toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
simple("${header.id}"))
.bean(MyProcess.class)
.doFinally()
.toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
simple("${header.id}"));
{code}
was:
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from("direct:processLocked")
.doTry()
.toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
simple("${header.id}"))
.bean(MyProcess.class);
.doFinally()
.toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
simple("${header.id}"));
{code}
> add route support for Hazelcast distributed locking/unlocking
> -
>
> Key: CAMEL-4397
> URL: https://issues.apache.org/jira/browse/CAMEL-4397
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.9.0
>
>
> add support for Hazelcast distributed locking/unlocking APIs in a route...see
> http://www.hazelcast.com/documentation.jsp#Lock
> something like this...
> {code}
> from("direct:processLocked")
> .doTry()
> .toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
> simple("${header.id}"))
> .bean(MyProcess.class)
> .doFinally()
> .toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
> simple("${header.id}"));
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4397) add route support for Hazelcast distributed locking/unlocking
[
https://issues.apache.org/jira/browse/CAMEL-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-4397:
-
Description:
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from("direct:processLocked")
.doTry()
.toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
simple("${header.id}"))
.bean(MyProcess.class);
.doFinally()
.toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
simple("${header.id}"));
{code}
was:
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
from("direct:processLocked")
.doTry()
.toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
simple("${header.id}"))
.bean(MyProcess.class);
.doFinally()
.toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
simple("${header.id}"))
.to("hazelcast:unlock");
> add route support for Hazelcast distributed locking/unlocking
> -
>
> Key: CAMEL-4397
> URL: https://issues.apache.org/jira/browse/CAMEL-4397
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.9.0
>
>
> add support for Hazelcast distributed locking/unlocking APIs in a route...see
> http://www.hazelcast.com/documentation.jsp#Lock
> something like this...
> {code}
> from("direct:processLocked")
> .doTry()
> .toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
> simple("${header.id}"))
> .bean(MyProcess.class);
> .doFinally()
> .toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
> simple("${header.id}"));
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4397) add route support for Hazelcast distributed locking/unlocking
add route support for Hazelcast distributed locking/unlocking
-
Key: CAMEL-4397
URL: https://issues.apache.org/jira/browse/CAMEL-4397
Project: Camel
Issue Type: Improvement
Components: camel-hazelcast
Reporter: Ben O'Day
Assignee: Ben O'Day
Priority: Minor
Fix For: 2.9.0
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
from("direct:processLocked")
.doTry()
.toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
simple("${header.id}"))
.bean(MyProcess.class);
.doFinally()
.toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
simple("${header.id}"))
.to("hazelcast:unlock");
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-4034) Create Camel component for Jclouds
[ https://issues.apache.org/jira/browse/CAMEL-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-4034 started by Hadrian Zbarcea. > Create Camel component for Jclouds > -- > > Key: CAMEL-4034 > URL: https://issues.apache.org/jira/browse/CAMEL-4034 > Project: Camel > Issue Type: New Feature >Reporter: Ioannis Canellos >Assignee: Hadrian Zbarcea > Fix For: Future > > Attachments: CAMEL-4034-patch.txt, CAMEL-4034-updated-patch.txt, > blobstore-test.xml > > > JClouds is a library that provides abstractions for cloud providers. > Currently it provides abstractions for: > i) BlobStores > ii) Queues > iii) Compute > It would be cool to have a camel component that would leverage the power of > jclouds in order to use any cloud provider. > JClouds is Apache Licensed & OSGi ready (1.0-beta-10 will be and will provide > Karaf integration). > I have put together a component that for jclouds blobstore (I intend to add > queue support in the future). > The component is available on github: > g...@github.com:iocanel/camel-jclouds.git -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4034) Create Camel component for Jclouds
[ https://issues.apache.org/jira/browse/CAMEL-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094197#comment-13094197 ] Hadrian Zbarcea commented on CAMEL-4034: @Ioannis, no need for a full patch. I'll assign this to myself, starts some tests and let you know how it works or if it needs any changes. Thanks for the contribution and we'd like to see more from you. > Create Camel component for Jclouds > -- > > Key: CAMEL-4034 > URL: https://issues.apache.org/jira/browse/CAMEL-4034 > Project: Camel > Issue Type: New Feature >Reporter: Ioannis Canellos >Assignee: Ioannis Canellos > Fix For: Future > > Attachments: CAMEL-4034-patch.txt, CAMEL-4034-updated-patch.txt, > blobstore-test.xml > > > JClouds is a library that provides abstractions for cloud providers. > Currently it provides abstractions for: > i) BlobStores > ii) Queues > iii) Compute > It would be cool to have a camel component that would leverage the power of > jclouds in order to use any cloud provider. > JClouds is Apache Licensed & OSGi ready (1.0-beta-10 will be and will provide > Karaf integration). > I have put together a component that for jclouds blobstore (I intend to add > queue support in the future). > The component is available on github: > g...@github.com:iocanel/camel-jclouds.git -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4034) Create Camel component for Jclouds
[ https://issues.apache.org/jira/browse/CAMEL-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea reassigned CAMEL-4034: -- Assignee: Hadrian Zbarcea (was: Ioannis Canellos) > Create Camel component for Jclouds > -- > > Key: CAMEL-4034 > URL: https://issues.apache.org/jira/browse/CAMEL-4034 > Project: Camel > Issue Type: New Feature >Reporter: Ioannis Canellos >Assignee: Hadrian Zbarcea > Fix For: Future > > Attachments: CAMEL-4034-patch.txt, CAMEL-4034-updated-patch.txt, > blobstore-test.xml > > > JClouds is a library that provides abstractions for cloud providers. > Currently it provides abstractions for: > i) BlobStores > ii) Queues > iii) Compute > It would be cool to have a camel component that would leverage the power of > jclouds in order to use any cloud provider. > JClouds is Apache Licensed & OSGi ready (1.0-beta-10 will be and will provide > Karaf integration). > I have put together a component that for jclouds blobstore (I intend to add > queue support in the future). > The component is available on github: > g...@github.com:iocanel/camel-jclouds.git -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4350) Camel-jdbc with List has arbitrary column order
[ https://issues.apache.org/jira/browse/CAMEL-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094175#comment-13094175 ] Mathieu Lalonde commented on CAMEL-4350: Based on the SqlProducer code & the javadoc for Spring's ColumnMapRowMapper, the keys should already be in a deterministic order. I can add a unit test in case we change the implementation down the road. > Camel-jdbc with List has arbitrary column order > > > Key: CAMEL-4350 > URL: https://issues.apache.org/jira/browse/CAMEL-4350 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc, camel-sql >Affects Versions: 2.7.1 > Environment: java 1.6 >Reporter: Julian Cable >Assignee: Mathieu Lalonde >Priority: Minor > Fix For: 2.9.0 > > Attachments: camel-jdbc_keyOrdering.tar > > > The following route works but the order of the columns is dependent on the > natural ordering of the hashmap. Target systems will have an expectation of > the order of the data. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id, value1, value2 FROM mytable > > > > > > > Either there needs to be a property for csv that allows hash key ordering to > be specified, or an option to sort the keys, e.g. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id as col1, value1 as col2, value2 as col3 FROM > mytable > > > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-4350) Camel-jdbc with List has arbitrary column order
[ https://issues.apache.org/jira/browse/CAMEL-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lalonde reopened CAMEL-4350: I was going to submit a patch for the camel-sql component as well. I should have it done in the next few days. > Camel-jdbc with List has arbitrary column order > > > Key: CAMEL-4350 > URL: https://issues.apache.org/jira/browse/CAMEL-4350 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc, camel-sql >Affects Versions: 2.7.1 > Environment: java 1.6 >Reporter: Julian Cable >Assignee: Mathieu Lalonde >Priority: Minor > Fix For: 2.9.0 > > Attachments: camel-jdbc_keyOrdering.tar > > > The following route works but the order of the columns is dependent on the > natural ordering of the hashmap. Target systems will have an expectation of > the order of the data. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id, value1, value2 FROM mytable > > > > > > > Either there needs to be a property for csv that allows hash key ordering to > be specified, or an option to sort the keys, e.g. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id as col1, value1 as col2, value2 as col3 FROM > mytable > > > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4332) camel-nagios - Use Camel type converter to convert message body to String before sending to Nagios
[ https://issues.apache.org/jira/browse/CAMEL-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094166#comment-13094166 ] Mathieu Lalonde commented on CAMEL-4332: Thanks for the feedback. I will also take into account your comment from CAMEL-4393, including it in the code & re-factoring a little to remove some duplication. > camel-nagios - Use Camel type converter to convert message body to String > before sending to Nagios > -- > > Key: CAMEL-4332 > URL: https://issues.apache.org/jira/browse/CAMEL-4332 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: Claus Ibsen >Assignee: Mathieu Lalonde >Priority: Trivial > Fix For: 2.9.0 > > Attachments: camel-nagios_test-contribution.tar, > camel-nagios_test-patch.tar > > > See nabble > http://camel.465427.n5.nabble.com/Sending-Nagios-Passive-Checks-from-Spring-HowTo-tp4694564p4694564.html > If people route a payload which is not already a String, we should convert > that to a String beforehand sending to Nagios. > In the nabble link the user routes from file -> nagios. And thus the payload > is a java.io.File instead. > All needed is to use the Camel type converter to convert to String first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4393) Camel :: Nagios unit test will break if exception is thrown during set up
[ https://issues.apache.org/jira/browse/CAMEL-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lalonde resolved CAMEL-4393. Resolution: Won't Fix > Camel :: Nagios unit test will break if exception is thrown during set up > - > > Key: CAMEL-4393 > URL: https://issues.apache.org/jira/browse/CAMEL-4393 > Project: Camel > Issue Type: Task >Reporter: Mathieu Lalonde >Assignee: Mathieu Lalonde >Priority: Minor > Original Estimate: 2h > Remaining Estimate: 2h > > The test classes swallow any exceptions thrown during setUp, log a warning > and set flag indicating they can't run. > Test methods return successfully if the flag is set! If an error is > introduced during the setUp() phase, all tests will pass and we will be down > to developer eye balls to spot the warning! > The simplest solution is to let the exception escape from setUp() which will > count as a test error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4393) Camel :: Nagios unit test will break if exception is thrown during set up
[ https://issues.apache.org/jira/browse/CAMEL-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lalonde updated CAMEL-4393: --- Fix Version/s: (was: Future) I guess I jumped to conclusion too soon. I'll make sure to take this into account for CAMEL-4332. > Camel :: Nagios unit test will break if exception is thrown during set up > - > > Key: CAMEL-4393 > URL: https://issues.apache.org/jira/browse/CAMEL-4393 > Project: Camel > Issue Type: Task >Reporter: Mathieu Lalonde >Assignee: Mathieu Lalonde >Priority: Minor > Original Estimate: 2h > Remaining Estimate: 2h > > The test classes swallow any exceptions thrown during setUp, log a warning > and set flag indicating they can't run. > Test methods return successfully if the flag is set! If an error is > introduced during the setUp() phase, all tests will pass and we will be down > to developer eye balls to spot the warning! > The simplest solution is to let the exception escape from setUp() which will > count as a test error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4392) LRUCache should not be a service
[ https://issues.apache.org/jira/browse/CAMEL-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved CAMEL-4392. Resolution: Fixed Fix Version/s: 2.9.0 > LRUCache should not be a service > > > Key: CAMEL-4392 > URL: https://issues.apache.org/jira/browse/CAMEL-4392 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.9.0 >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.9.0 > > > Properly implemented clear() would do. It also forces other classes using it > (such as PropertyEditorTypeConverter) to be a Service, quite unnecessarily. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4396) XML validation errors should be not logged on System.err
[ https://issues.apache.org/jira/browse/CAMEL-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller resolved CAMEL-4396. - Resolution: Fixed Fix Version/s: 2.9.0 Committed r1163420 Thanks for the patch. > XML validation errors should be not logged on System.err > > > Key: CAMEL-4396 > URL: https://issues.apache.org/jira/browse/CAMEL-4396 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.6.0 >Reporter: metatech >Assignee: Christian Müller > Fix For: 2.9.0 > > Attachments: camel_xml_exceptions1.patch, camel_xml_exceptions2.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > When a XSLT has validation errors, these errors do not appear in the log4j > logs but instead are printed as "System.err". > A simple change to the XmlConverter class of camel-core and a custom > XmlErrorListener fixes that (see attachment). > Please consider the patch for inclusion. > Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4396) XML validation errors should be not logged on System.err
[ https://issues.apache.org/jira/browse/CAMEL-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller reassigned CAMEL-4396: --- Assignee: Christian Müller > XML validation errors should be not logged on System.err > > > Key: CAMEL-4396 > URL: https://issues.apache.org/jira/browse/CAMEL-4396 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.6.0 >Reporter: metatech >Assignee: Christian Müller > Attachments: camel_xml_exceptions1.patch, camel_xml_exceptions2.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > When a XSLT has validation errors, these errors do not appear in the log4j > logs but instead are printed as "System.err". > A simple change to the XmlConverter class of camel-core and a custom > XmlErrorListener fixes that (see attachment). > Please consider the patch for inclusion. > Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-4396) XML validation errors should be not logged on System.err
[ https://issues.apache.org/jira/browse/CAMEL-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-4396 started by Christian Müller. > XML validation errors should be not logged on System.err > > > Key: CAMEL-4396 > URL: https://issues.apache.org/jira/browse/CAMEL-4396 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.6.0 >Reporter: metatech >Assignee: Christian Müller > Attachments: camel_xml_exceptions1.patch, camel_xml_exceptions2.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > When a XSLT has validation errors, these errors do not appear in the log4j > logs but instead are printed as "System.err". > A simple change to the XmlConverter class of camel-core and a custom > XmlErrorListener fixes that (see attachment). > Please consider the patch for inclusion. > Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4394) MyAsyncComponent uses invalid URIs
[
https://issues.apache.org/jira/browse/CAMEL-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated CAMEL-4394:
---
Affects Version/s: 2.8.0
> MyAsyncComponent uses invalid URIs
> --
>
> Key: CAMEL-4394
> URL: https://issues.apache.org/jira/browse/CAMEL-4394
> Project: Camel
> Issue Type: Test
> Components: camel-core
>Affects Versions: 2.8.0
>Reporter: Hadrian Zbarcea
>Assignee: Hadrian Zbarcea
>Priority: Minor
> Fix For: 2.9.0
>
>
> MyAsyncComponent URIs contain spaces and test depend on invalid URIs like
> to("async:Bye Camel"). A simple fix is to make a convention to use URNs like:
> "async:bye:camel" and internally convert ':' to ' ' and capitalize words to
> not change the tests too much.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Supporting our users to be more involved with our project
Christian Mueller wrote: > > The "easy to resolve" issues have the Novices annotation. > Dan created and shared the new JIRA view which is called "Camel-Novice" > [1]. > I have linked this page from our contribution page [2]. > > I hope our users/contributors will like it and are more easily involved. > > [1] > https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12316782 > [2] http://camel.apache.org/contributing.html > > Best, > Christian > Nice! I will drill down them as soon as I find time from my "paid" work ;) Thanks a lot! -- View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Supporting-our-users-to-be-more-involved-with-our-project-tp4660329p4751573.html Sent from the Camel Development mailing list archive at Nabble.com.
[jira] [Commented] (CAMEL-3476) Contribute camel-sns component to the new camel-aws component.
[ https://issues.apache.org/jira/browse/CAMEL-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094087#comment-13094087 ] Christian Müller commented on CAMEL-3476: - Kai, I looking forward for the community feedback you are asking for. In the meantime, you have to configure the subscription once via the AWS web console. Than you can use a Camel consumer (SQS, Mail, HTTP or HTTP4) to consume the messages. And as you probably know, we love contributions... :-) Best, Christian > Contribute camel-sns component to the new camel-aws component. > -- > > Key: CAMEL-3476 > URL: https://issues.apache.org/jira/browse/CAMEL-3476 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.6.0 >Reporter: Mark Ford >Assignee: Tracy Snell >Priority: Minor > Fix For: 2.8.0 > > Attachments: camel-aws-3476.txt, patchfile.txt, patchfile.txt > > > CAMEL-3468 contributes a new component for interacting with the Amazon SQS > service. The camel-sns component allows users to publish/subscribe to topics > on Amazon's Simple Notification Service. > This code is currently hosted as a google code project here: > http://code.google.com/p/camel-sns/ > I'll coordinate with Tracy (developer of camel-aws) in the creation of the > patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3476) Contribute camel-sns component to the new camel-aws component.
[ https://issues.apache.org/jira/browse/CAMEL-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094080#comment-13094080 ] Christian Müller commented on CAMEL-3476: - Kai, I added a link from our [Artices site|https://cwiki.apache.org/confluence/display/CAMEL/Articles] to your blog. > Contribute camel-sns component to the new camel-aws component. > -- > > Key: CAMEL-3476 > URL: https://issues.apache.org/jira/browse/CAMEL-3476 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.6.0 >Reporter: Mark Ford >Assignee: Tracy Snell >Priority: Minor > Fix For: 2.8.0 > > Attachments: camel-aws-3476.txt, patchfile.txt, patchfile.txt > > > CAMEL-3468 contributes a new component for interacting with the Amazon SQS > service. The camel-sns component allows users to publish/subscribe to topics > on Amazon's Simple Notification Service. > This code is currently hosted as a google code project here: > http://code.google.com/p/camel-sns/ > I'll coordinate with Tracy (developer of camel-aws) in the creation of the > patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4396) XML validation errors should be not logged on System.err
[ https://issues.apache.org/jira/browse/CAMEL-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] metatech updated CAMEL-4396: Attachment: camel_xml_exceptions2.patch camel_xml_exceptions1.patch > XML validation errors should be not logged on System.err > > > Key: CAMEL-4396 > URL: https://issues.apache.org/jira/browse/CAMEL-4396 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.6.0 >Reporter: metatech > Attachments: camel_xml_exceptions1.patch, camel_xml_exceptions2.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > When a XSLT has validation errors, these errors do not appear in the log4j > logs but instead are printed as "System.err". > A simple change to the XmlConverter class of camel-core and a custom > XmlErrorListener fixes that (see attachment). > Please consider the patch for inclusion. > Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4396) XML validation errors should be not logged on System.err
XML validation errors should be not logged on System.err Key: CAMEL-4396 URL: https://issues.apache.org/jira/browse/CAMEL-4396 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.6.0 Reporter: metatech When a XSLT has validation errors, these errors do not appear in the log4j logs but instead are printed as "System.err". A simple change to the XmlConverter class of camel-core and a custom XmlErrorListener fixes that (see attachment). Please consider the patch for inclusion. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093809#comment-13093809
]
Sergey Zhemzhitsky commented on CAMEL-4351:
---
Hi Willem,
I've just tried the latest version from the trunk.
Now everything works like a charm.
Thank you very much for such a great help.
Regards,
Sergey
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-4395) MockEndpoint should save copies of received exchanges.
[
https://issues.apache.org/jira/browse/CAMEL-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Zhemzhitsky closed CAMEL-4395.
-
Resolution: Won't Fix
Closing this issue because it has already been fixed on trunk
> MockEndpoint should save copies of received exchanges.
> --
>
> Key: CAMEL-4395
> URL: https://issues.apache.org/jira/browse/CAMEL-4395
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.8.0
>Reporter: Sergey Zhemzhitsky
>
> MockEndpoint should save copies of received exchanges, because it's hardly
> possible to attach a custom processor that modifies the exchange and perform
> assertions by means of expectedMessagesMatches.
> It happens because at the time of evaluation of assertions the original
> exchange has already been modified and it is not equal to the received
> exchange.
> {code}
> mockEndpoint.whenExchangeReceived(1, new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception {
> Message out = exchange.getPattern().isOutCapable() ?
> exchange.getOut() : exchange.getIn();
> Object newBody = getNewBodySomeHow();
> out.setBody(newBody);
> }
> });
> {code}
> {code}
> mockEndpoint.expectedMessagesMatches(
> new Predicate() {
> @Override
> public boolean matches(Exchange exchange) {
> Object actualBody = exchange.getIn().getBody(); // this body is
> equal to newBody that was set by processor in the whenExchangeReceived method
> Object expectedBody = getExpectedBodySomeHow();
> return compareExpectedBodyAndActualBody(expectedBody, actualBody);
> }
> }
> );
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093779#comment-13093779
]
Willem Jiang commented on CAMEL-4351:
-
Hi Sergey,
I just committed a quick fix for the issue that you met.
Do you mind try it again ?
Thanks,
Willem
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4395) MockEndpoint should save copies of received exchanges.
MockEndpoint should save copies of received exchanges.
--
Key: CAMEL-4395
URL: https://issues.apache.org/jira/browse/CAMEL-4395
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.0
Reporter: Sergey Zhemzhitsky
MockEndpoint should save copies of received exchanges, because it's hardly
possible to attach a custom processor that modifies the exchange and perform
assertions by means of expectedMessagesMatches.
It happens because at the time of evaluation of assertions the original
exchange has already been modified and it is not equal to the received exchange.
{code}
mockEndpoint.whenExchangeReceived(1, new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
Message out = exchange.getPattern().isOutCapable() ? exchange.getOut()
: exchange.getIn();
Object newBody = getNewBodySomeHow();
out.setBody(newBody);
}
});
{code}
{code}
mockEndpoint.expectedMessagesMatches(
new Predicate() {
@Override
public boolean matches(Exchange exchange) {
Object actualBody = exchange.getIn().getBody(); // this body is
equal to newBody that was set by processor in the whenExchangeReceived method
Object expectedBody = getExpectedBodySomeHow();
return compareExpectedBodyAndActualBody(expectedBody, actualBody);
}
}
);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093736#comment-13093736
]
Willem Jiang commented on CAMEL-4351:
-
Hi Sergey，
I can reproduce the error, will look into it later.
Thanks for pointing that out.
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] - Apache Camel 2.8.1 release
I will and get ready for the 2.8.1 release. Hadrian On 08/30/2011 05:44 AM, Claus Ibsen wrote: Anyone got cycles to take a look at the bug fixes in Camel 2.9, which may not have been backported. And then merge any bug fixes which seems reasonable to be backported? I guess this is the current bug fixed on 2.9 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC There is 37 bugs fixed, and there may be some fixes which havent been backported.
Re: camel 2.9 release plan
Definitely not. Christian was probably referring to 2.8.1. Camel 2.8.0 was just released, and the earliest you could expect camel 2.9 would probably be October, but there is no clear plan yet. We also got into the habit of issuing patch releases every 6-8 weeks so users could get fixes more often. Cheers, Hadrian On 08/30/2011 05:53 AM, Christian Schneider wrote: I guess it will be in the next two to three weeks. Any other suggestions? Christian Am 30.08.2011 11:11, schrieb Marco Crivellaro: Hi all, is there any plan regarding releasing Camel 2.9? -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-9-release-plan-tp4749402p4749402.html Sent from the Camel Development mailing list archive at Nabble.com.
[jira] [Issue Comment Edited] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093648#comment-13093648
]
Sergey Zhemzhitsky edited comment on CAMEL-4351 at 8/30/11 10:56 AM:
-
Hi Willem,
I've just tested the new functionality and the attached patch for the
CxfEndpointBeans.xml makes the test failed.
Here is the stacktrace
{code}
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myEndpoint': Error setting property
values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'endpointNameString' of bean class
[org.apache.cxf.jaxws.JaxWsProxyFactoryBean]: Bean property
'endpointNameString' is not writable or has an invalid setter method. Does
the parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBean
Factory.java:1361)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory
.java:1086)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.configureBean(AbstractAutowireCapableBeanFactor
y.java:314)
at
org.springframework.beans.factory.wiring.BeanConfigurerSupport.configureBean(BeanConfigurerSupport.java:146)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:151)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:115)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.configure(CxfSpringEndpoint.java:225)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.createClient(CxfSpringEndpoint.java:117)
at
org.apache.camel.component.cxf.CxfProducer.(CxfProducer.java:71)
at
org.apache.camel.component.cxf.CxfEndpoint.createProducer(CxfEndpoint.java:153)
at
org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:377)
... 86 more
Caused by: org.springframework.beans.NotWritablePropertyException: Invalid
property 'endpointNameString' of bean class [org.apache.cxf.
jaxws.JaxWsProxyFactoryBean]: Bean property 'endpointNameString' is not
writable or has an invalid setter method. Does the parameter ty
pe of the setter match the return type of the getter?
at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1024)
at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:903)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:58)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBean
Factory.java:1358)
... 96 more
{code}
Properties endpointNameString, serviceNameString seem to be applied to
ClientProxyFactoryBean, ClientFactoryBean, ServerFactoryBean,
JaxWsServerFactoryBean, and these classes don't have such properties.
was (Author: szhemzhitsky):
Hi Willem,
I've just tested the new functionality and the attached patch for the
CxfEndpointBeans.xml that makes the test failed.
Here is the stacktrace
{code}
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myEndpoint': Error setting property
values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'endpointNameString' of bean class
[org.apache.cxf.jaxws.JaxWsProxyFactoryBean]: Bean property
'endpointNameString' is not writable or has an invalid setter method. Does
the parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBean
Factory.java:1361)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory
.java:1086)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.configureBean(AbstractAutowireCapableBeanFactor
y.java:314)
at
org.springframework.beans.factory.wiring.BeanConfigurerSupport.configureBean(BeanConfigurerSupport.java:146)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:151)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:115)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.configure(CxfSpringEndpoint.java:225)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.createClient(CxfSpringEn
[jira] [Commented] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093648#comment-13093648
]
Sergey Zhemzhitsky commented on CAMEL-4351:
---
Hi Willem,
I've just tested the new functionality and the attached patch for the
CxfEndpointBeans.xml that makes the test failed.
Here is the stacktrace
{code}
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myEndpoint': Error setting property
values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'endpointNameString' of bean class
[org.apache.cxf.jaxws.JaxWsProxyFactoryBean]: Bean property
'endpointNameString' is not writable or has an invalid setter method. Does
the parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBean
Factory.java:1361)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory
.java:1086)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.configureBean(AbstractAutowireCapableBeanFactor
y.java:314)
at
org.springframework.beans.factory.wiring.BeanConfigurerSupport.configureBean(BeanConfigurerSupport.java:146)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:151)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:115)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.configure(CxfSpringEndpoint.java:225)
at
org.apache.camel.component.cxf.CxfSpringEndpoint.createClient(CxfSpringEndpoint.java:117)
at
org.apache.camel.component.cxf.CxfProducer.(CxfProducer.java:71)
at
org.apache.camel.component.cxf.CxfEndpoint.createProducer(CxfEndpoint.java:153)
at
org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:377)
... 86 more
Caused by: org.springframework.beans.NotWritablePropertyException: Invalid
property 'endpointNameString' of bean class [org.apache.cxf.
jaxws.JaxWsProxyFactoryBean]: Bean property 'endpointNameString' is not
writable or has an invalid setter method. Does the parameter ty
pe of the setter match the return type of the getter?
at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1024)
at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:903)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:58)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBean
Factory.java:1358)
... 96 more
{code}
Properties endpointNameString, serviceNameString seem to be applied to
ClientProxyFactoryBean, ClientFactoryBean, ServerFactoryBean,
JaxWsServerFactoryBean, and these classes don't have such properties.
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jenkins dependency in camel-core pom.xml for SNAPSHOTs
Maybe we need to add this profile in camel-core http://maven.apache.org/general.html#tools-jar-dependency Also discussed here http://jenkins.361315.n4.nabble.com/com-sun-tools-jar-1-5-is-missing-td390964.html On Tue, Aug 30, 2011 at 11:49 AM, Claus Ibsen wrote: > Hi > > Take a look at the pom.xml for camel-core that the CI server at Apache > produces > https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.9-SNAPSHOT/camel-core-2.9-SNAPSHOT.pom > > If you notice then it adds a dependency to jenkins > > com.sun > tools > 1.5.0 > system > > /home/jenkins/tools/java/jdk1.6.0_20-32/jre/../lib/tools.jar > > > > > I have not been able to figure out why it does that, and where you can > disable it from doing this. > > Anyone seen this before? And know a reason for doing this. > > > > -- > 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/ > -- 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 2.9 release plan
I guess it will be in the next two to three weeks. Any other suggestions? Christian Am 30.08.2011 11:11, schrieb Marco Crivellaro: Hi all, is there any plan regarding releasing Camel 2.9? -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-9-release-plan-tp4749402p4749402.html Sent from the Camel Development mailing list archive at Nabble.com. -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
camel 2.9 release plan
Hi all, is there any plan regarding releasing Camel 2.9? -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-9-release-plan-tp4749402p4749402.html Sent from the Camel Development mailing list archive at Nabble.com.
Jenkins dependency in camel-core pom.xml for SNAPSHOTs
Hi Take a look at the pom.xml for camel-core that the CI server at Apache produces https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.9-SNAPSHOT/camel-core-2.9-SNAPSHOT.pom If you notice then it adds a dependency to jenkins com.sun tools 1.5.0 system /home/jenkins/tools/java/jdk1.6.0_20-32/jre/../lib/tools.jar I have not been able to figure out why it does that, and where you can disable it from doing this. Anyone seen this before? And know a reason for doing this. -- 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: [DISCUSS] - Apache Camel 2.8.1 release
Anyone got cycles to take a look at the bug fixes in Camel 2.9, which may not have been backported. And then merge any bug fixes which seems reasonable to be backported? I guess this is the current bug fixed on 2.9 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC There is 37 bugs fixed, and there may be some fixes which havent been backported. -- 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] [Updated] (CAMEL-4351) Impossible to use placeholders in endpointName and serviceName attributes of cxf:cxfEndpoint
[
https://issues.apache.org/jira/browse/CAMEL-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Zhemzhitsky updated CAMEL-4351:
--
Attachment: CxfEndpointBeans.xml.patch
> Impossible to use placeholders in endpointName and serviceName attributes of
> cxf:cxfEndpoint
>
>
> Key: CAMEL-4351
> URL: https://issues.apache.org/jira/browse/CAMEL-4351
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.7.3
>Reporter: Sergey Zhemzhitsky
>Assignee: Willem Jiang
> Attachments: CxfEndpointBeans.xml.patch
>
>
> Here is how endpointName and serviceName are declared in XSD.
> {code}
>
>
> {code}
> So the xml parser fails to parse the following element
> {code}
> wsdlURL="${http.service.wsdl.path}"
> serviceName="${http.service.serviceName}"
> endpointName="${http.service.portName}">
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1163153 - in /camel/trunk/components/camel-cxf/src: main/java/org/apache/camel/component/cxf/ main/java/org/apache/camel/component/cxf/spring/ test/java/org/apache/camel/component/cxf
The CamelContext API have that method
String resolvePropertyPlaceholders(String text) throws Exception;
So you do *not* need to depend on DefaultCamelContext, but just
CamelContext interface.
On Tue, Aug 30, 2011 at 11:19 AM, wrote:
> Author: ningjiang
> Date: Tue Aug 30 09:19:11 2011
> New Revision: 1163153
>
> URL: http://svn.apache.org/viewvc?rev=1163153&view=rev
> Log:
> CAMEL-3510 cxf namespace supports Camel properties placeholder out of the box
>
> Added:
>
> camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/spring/testEndpoint.properties
> (with props)
> Modified:
>
> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
>
> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/spring/CxfEndpointBeanDefinitionParser.java
>
> camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/spring/CxfEndpointBeansRouterTest.java
>
> camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/spring/CxfEndpointBeansRouter.xml
>
> Modified:
> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
> URL:
> http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java?rev=1163153&r1=1163152&r2=1163153&view=diff
> ==
> ---
> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
> (original)
> +++
> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
> Tue Aug 30 09:19:11 2011
> @@ -27,14 +27,10 @@ import javax.xml.namespace.QName;
> import javax.xml.ws.WebServiceProvider;
> import javax.xml.ws.handler.Handler;
>
> +import org.apache.camel.*;
> +import org.apache.camel.impl.DefaultCamelContext;
> import org.w3c.dom.Element;
>
> -import org.apache.camel.CamelContext;
> -import org.apache.camel.CamelException;
> -import org.apache.camel.Consumer;
> -import org.apache.camel.Processor;
> -import org.apache.camel.Producer;
> -import org.apache.camel.Service;
> import org.apache.camel.component.cxf.common.header.CxfHeaderFilterStrategy;
> import org.apache.camel.component.cxf.common.message.CxfConstants;
> import org.apache.camel.component.cxf.feature.MessageDataFormatFeature;
> @@ -90,6 +86,8 @@ public class CxfEndpoint extends Default
> private Class serviceClass;
> private QName portName;
> private QName serviceName;
> + private String portNameString;
> + private String serviceNameString;
> private String defaultOperationName;
> private String defaultOperationNamespace;
> // This is for invoking the CXFClient with wrapped parameters of
> unwrapped parameters
> @@ -189,11 +187,11 @@ public class CxfEndpoint extends Default
> if (sfb instanceof JaxWsServerFactoryBean && handlers != null) {
> ((JaxWsServerFactoryBean)sfb).setHandlers(handlers);
> }
> - if (transportId != null) {
> - sfb.setTransportId(transportId);
> + if (getTransportId() != null) {
> + sfb.setTransportId(getTransportId());
> }
> - if (bindingId != null) {
> - sfb.setBindingId(bindingId);
> + if (getBindingId() != null) {
> + sfb.setBindingId(getBindingId());
> }
>
> // wsdl url
> @@ -319,11 +317,11 @@ public class CxfEndpoint extends Default
> if (factoryBean instanceof JaxWsProxyFactoryBean && handlers != null)
> {
> ((JaxWsProxyFactoryBean)factoryBean).setHandlers(handlers);
> }
> - if (transportId != null) {
> - factoryBean.setTransportId(transportId);
> + if (getTransportId() != null) {
> + factoryBean.setTransportId(getTransportId());
> }
> - if (bindingId != null) {
> - factoryBean.setBindingId(bindingId);
> + if (getBindingId() != null) {
> + factoryBean.setBindingId(getBindingId());
> }
>
> // address
> @@ -502,6 +500,18 @@ public class CxfEndpoint extends Default
> return answer;
> }
>
> + protected String resolvePropertyPlaceholders(String str) {
> + try {
> + if (getCamelContext() != null) {
> + return
> ((DefaultCamelContext)getCamelContext()).resolvePropertyPlaceholders(str);
> + } else {
> + return str;
> + }
> + } catch (Exception ex) {
> + throw new RuntimeCamelException(ex);
> + }
> + }
> +
> // Properties
> //
> -
>
> @@ -514,7 +524,7 @@ public class CxfEndpoint extends Default
> }
>
> public String getPublishedEndpointUrl() {
> - return publishedEndpointUrl;
> + return resolvePropertyPlaceholders(publishe
[jira] [Commented] (CAMEL-4332) camel-nagios - Use Camel type converter to convert message body to String before sending to Nagios
[ https://issues.apache.org/jira/browse/CAMEL-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093572#comment-13093572 ] Claus Ibsen commented on CAMEL-4332: Please use "target" for tmp dir. That is what we usually do. And there is a deleteDirectory in the camel test kit, so we usually delete the target/foo directory in the setup. > camel-nagios - Use Camel type converter to convert message body to String > before sending to Nagios > -- > > Key: CAMEL-4332 > URL: https://issues.apache.org/jira/browse/CAMEL-4332 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: Claus Ibsen >Assignee: Mathieu Lalonde >Priority: Trivial > Fix For: 2.9.0 > > Attachments: camel-nagios_test-contribution.tar, > camel-nagios_test-patch.tar > > > See nabble > http://camel.465427.n5.nabble.com/Sending-Nagios-Passive-Checks-from-Spring-HowTo-tp4694564p4694564.html > If people route a payload which is not already a String, we should convert > that to a String beforehand sending to Nagios. > In the nabble link the user routes from file -> nagios. And thus the payload > is a java.io.File instead. > All needed is to use the Camel type converter to convert to String first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4350) Camel-jdbc with List has arbitrary column order
[ https://issues.apache.org/jira/browse/CAMEL-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-4350. Resolution: Fixed Thanks for the patch. > Camel-jdbc with List has arbitrary column order > > > Key: CAMEL-4350 > URL: https://issues.apache.org/jira/browse/CAMEL-4350 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc, camel-sql >Affects Versions: 2.7.1 > Environment: java 1.6 >Reporter: Julian Cable >Assignee: Mathieu Lalonde >Priority: Minor > Fix For: 2.9.0 > > Attachments: camel-jdbc_keyOrdering.tar > > > The following route works but the order of the columns is dependent on the > natural ordering of the hashmap. Target systems will have an expectation of > the order of the data. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id, value1, value2 FROM mytable > > > > > > > Either there needs to be a property for csv that allows hash key ordering to > be specified, or an option to sort the keys, e.g. > > http://0.0.0.0:16081/css/mes"/> > > SELECT id as col1, value1 as col2, value2 as col3 FROM > mytable > > > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4381) Simplify ServiceSupport and introduce ServiceWithStatus interface to remove tangle between util and support
[ https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093550#comment-13093550 ] Christian Schneider commented on CAMEL-4381: Honestly I think we have to many states. For example I do not get what the difference between stopped and suspended should be. I have never really seen that many states. But of course there is the real issue with existing code that might easily break. So I will suggest having a status variable in camel 3.0 but for now it is better to leave it alone. > Simplify ServiceSupport and introduce ServiceWithStatus interface to remove > tangle between util and support > --- > > Key: CAMEL-4381 > URL: https://issues.apache.org/jira/browse/CAMEL-4381 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.9.0 > > > Currently ServiceSupport and ServiceHelper form a dependency cycle. > ServiceSupport calls ServiceHelper to start and stop services and > ServiceSupport operate on ServiceSupport classes. > To solve that I introduce an Interface ServiceWithSupport (open for a better > naming). This interface extends Service and has all relevant methods from > ServiceSupport. So ServiceHelper can operate on ServiceWithStatus and the > tangle goes away. > Addtionally I split up ServiceSupport into ServiceSupport which has no > children and ChildServiceSupport which has. This is because we seem to have > only two classes that actually use the children functionality. The rest of > the classes that extend ServiceSupport have no children. So having them all > extend the old ServiceSupport introduces a lot of unneeded complexity. > The change should be fairly compatible. The only possible problem are third > party components that use children. As we only had two such components in > camel the chance that something breaks is fairly low. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: BytesSource and StringSource
Hi Claus, I think you are right. These classes can be put into util. As they are only two classes I suggest to directly put them in util. Originally I put them ino the API package as they are needed in camel-jms and so are needed in at least some components. We now agreed that support may access util so util is part of the "extended" API of API+SPI+support+util. I am still not sure if we should have data classes in util but I also have no better suggestion so util is ok for me. Christian Am 30.08.2011 08:50, schrieb Claus Ibsen: Hi Its a pita that these classes is moved to the root package of Camel. The root package is an API having only interfaces, exceptions, enums, annotations etc. Then we got those two "stranded whales" here which seems misplaced. The JDK have its xxxSource implementations in sub packages: javax.xml.transform.stream.StreamSource So why can't we in Camel? It seems too dramatic as a solution to move stuff into the root package. Also these classes do *not* implement any Camel interface, but they are JDK xxxSource specific helpers in Camel. Instead I suggest they are placed in the org.apache.camel.util.stream package -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
[jira] [Commented] (CAMEL-4381) Simplify ServiceSupport and introduce ServiceWithStatus interface to remove tangle between util and support
[ https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093547#comment-13093547 ] Claus Ibsen commented on CAMEL-4381: Yes have respect for the existing code. The state can be stopped + shutdown etc. When a service is shutdown its also stopped. > Simplify ServiceSupport and introduce ServiceWithStatus interface to remove > tangle between util and support > --- > > Key: CAMEL-4381 > URL: https://issues.apache.org/jira/browse/CAMEL-4381 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.9.0 > > > Currently ServiceSupport and ServiceHelper form a dependency cycle. > ServiceSupport calls ServiceHelper to start and stop services and > ServiceSupport operate on ServiceSupport classes. > To solve that I introduce an Interface ServiceWithSupport (open for a better > naming). This interface extends Service and has all relevant methods from > ServiceSupport. So ServiceHelper can operate on ServiceWithStatus and the > tangle goes away. > Addtionally I split up ServiceSupport into ServiceSupport which has no > children and ChildServiceSupport which has. This is because we seem to have > only two classes that actually use the children functionality. The rest of > the classes that extend ServiceSupport have no children. So having them all > extend the old ServiceSupport introduces a lot of unneeded complexity. > The change should be fairly compatible. The only possible problem are third > party components that use children. As we only had two such components in > camel the chance that something breaks is fairly low. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3476) Contribute camel-sns component to the new camel-aws component.
[ https://issues.apache.org/jira/browse/CAMEL-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093546#comment-13093546 ] Kai Wähner commented on CAMEL-3476: --- Hey guys, one great thing about Camel is to do very easy integrations within routes. You can (but you do not have to) specify almost all configurations in the endpoints. This is awesome if you need to change an endpoint to another technology - also for playing around, evaluating and testing technologies. I have played around with the camel-aws component this week. In my opinion, there should be a consumer which is able to subscribe to topics, otherwise Camel is missing a key part of the AWS SNS service! I have written a blog about the camel-aws component and mentioned this discussion (http://www.kai-waehner.de/blog/2011/08/30/cloud-integration-with-apache-camel-and-amazon-web-services-aws-s3-sqs-and-sns). Maybe more people will contribute their opinion. Best regards, Kai > Contribute camel-sns component to the new camel-aws component. > -- > > Key: CAMEL-3476 > URL: https://issues.apache.org/jira/browse/CAMEL-3476 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.6.0 >Reporter: Mark Ford >Assignee: Tracy Snell >Priority: Minor > Fix For: 2.8.0 > > Attachments: camel-aws-3476.txt, patchfile.txt, patchfile.txt > > > CAMEL-3468 contributes a new component for interacting with the Amazon SQS > service. The camel-sns component allows users to publish/subscribe to topics > on Amazon's Simple Notification Service. > This code is currently hosted as a google code project here: > http://code.google.com/p/camel-sns/ > I'll coordinate with Tracy (developer of camel-aws) in the creation of the > patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4381) Simplify ServiceSupport and introduce ServiceWithStatus interface to remove tangle between util and support
[ https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093540#comment-13093540 ] Christian Schneider commented on CAMEL-4381: Btw. Do we really need these AtomicBooleans? The state of the service can only be one of those at a time. So I think an integer or a status enum would be better. So I would like to change that into a ServiceStatus status. The only question is how to make it thread safe but I guess this should work with synchronized. > Simplify ServiceSupport and introduce ServiceWithStatus interface to remove > tangle between util and support > --- > > Key: CAMEL-4381 > URL: https://issues.apache.org/jira/browse/CAMEL-4381 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.9.0 > > > Currently ServiceSupport and ServiceHelper form a dependency cycle. > ServiceSupport calls ServiceHelper to start and stop services and > ServiceSupport operate on ServiceSupport classes. > To solve that I introduce an Interface ServiceWithSupport (open for a better > naming). This interface extends Service and has all relevant methods from > ServiceSupport. So ServiceHelper can operate on ServiceWithStatus and the > tangle goes away. > Addtionally I split up ServiceSupport into ServiceSupport which has no > children and ChildServiceSupport which has. This is because we seem to have > only two classes that actually use the children functionality. The rest of > the classes that extend ServiceSupport have no children. So having them all > extend the old ServiceSupport introduces a lot of unneeded complexity. > The change should be fairly compatible. The only possible problem are third > party components that use children. As we only had two such components in > camel the chance that something breaks is fairly low. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: WrappedFile
Hi Claus,
technically you are correct. WrappedFile is rather a WrappedObject. But
this is not the intent.
The intent is to have an interface for the minimum part of GenericFile
that is needed outside of the file component. This is necessary to avoid
having other parts of camel know about the inner details of the file
component.
My solution is not ideal but it works for the moment. In the future I
would like to change the file component to not use generics and a
special message at all. I think the best way to send files is to create
a DefaultMessage and add the File as body. For all other details needed
I would use headers. I would like to do this for camel 3.0.
Christian
Am 30.08.2011 08:46, schrieb Claus Ibsen:
Hi
The WrappedFile seems like when people create a facade for another facade.
public interface WrappedFile {
T getFile();
}
That WrappedFile is not specific for a File, it could in fact be anything.
So I suggest to come up with a more generic name and API. I bet it
could come handy in another place in the jigsaw.
Could be
public interface WrappedObject {
T getObject();
}
Or
public interface WrappedEntity {
T getEntity();
}
Or
public interface Facade {
T getTarget();
}
Or something else.
Also any API in the root package should have javadoc, stating its
purpose and what it does.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
[jira] [Commented] (CAMEL-4381) Simplify ServiceSupport and introduce ServiceWithStatus interface to remove tangle between util and support
[ https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093531#comment-13093531 ] Christian Schneider commented on CAMEL-4381: Hi Claus, the logic for not starting a service twice is still there. I just moved it to ServiceSupport. I was not aware of the logic that resets the state when an exception is thrown. I will add this and also add a test for it. > Simplify ServiceSupport and introduce ServiceWithStatus interface to remove > tangle between util and support > --- > > Key: CAMEL-4381 > URL: https://issues.apache.org/jira/browse/CAMEL-4381 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.9.0 > > > Currently ServiceSupport and ServiceHelper form a dependency cycle. > ServiceSupport calls ServiceHelper to start and stop services and > ServiceSupport operate on ServiceSupport classes. > To solve that I introduce an Interface ServiceWithSupport (open for a better > naming). This interface extends Service and has all relevant methods from > ServiceSupport. So ServiceHelper can operate on ServiceWithStatus and the > tangle goes away. > Addtionally I split up ServiceSupport into ServiceSupport which has no > children and ChildServiceSupport which has. This is because we seem to have > only two classes that actually use the children functionality. The rest of > the classes that extend ServiceSupport have no children. So having them all > extend the old ServiceSupport introduces a lot of unneeded complexity. > The change should be fairly compatible. The only possible problem are third > party components that use children. As we only had two such components in > camel the chance that something breaks is fairly low. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4213) camel-jpa can't find entities when using blueprint in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093519#comment-13093519
]
Claus Ibsen commented on CAMEL-4213:
A patch is of course welcome, but an osgi blueprint unit tests in
camel-itest-osgi would be great.
> camel-jpa can't find entities when using blueprint in OSGi
> --
>
> Key: CAMEL-4213
> URL: https://issues.apache.org/jira/browse/CAMEL-4213
> Project: Camel
> Issue Type: Bug
> Components: camel-jpa, osgi
>Affects Versions: 2.7.2
> Environment: Apache Karaf 2.2.2
>Reporter: Jonas Bengtsson
> Fix For: 2.9.0
>
>
> When using the following simple route, the entity classes can't be found:
> {code}
> public void configure() throws Exception {
> from("direct:test-in").to("jpa:mypackage.MyEntity1");
> from("jpa:mypackage.MyEntity2").to("log:test-out");
> }
> {code}
> The error message is:
> 09:43:55,417 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity1
> 09:43:55,467 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity2
> followed by many warnings about that the entityType is not known for the
> consumer.
> The errors only occur when using blueprint to bootstrap the route. When using
> spring-dm everything works fine. The entity classes are located in the same
> bundle as the route. My guess is that it uses the wrong classloader.
> JPA works fine otherwise. It is only the camel-jpa component I have problems
> with. camel-jpa is a very spring-centric module, using a spring
> TransactionManager and all, so I hope that my use case makes sense.
> For completeness here is my blueprint-file:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
> default-activation="eager"
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0";>
> http://camel.apache.org/schema/blueprint";>
> mypackage
>
>
>ref="entityManagerFactory" />
>
>
>class="org.springframework.orm.jpa.JpaTransactionManager">
>ref="entityManagerFactory" />
>
>interface="javax.persistence.EntityManagerFactory"
> filter="(osgi.unit.name=myunit)" />
>
> {code}
> The EntityManagerFactory is created by Aries Jpa, but it shouldn't be
> relevant for the question.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4213) camel-jpa can't find entities when using blueprint in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093518#comment-13093518
]
Claus Ibsen commented on CAMEL-4213:
I think Gert fixed camel-blueprint to set the TCCL as well.
> camel-jpa can't find entities when using blueprint in OSGi
> --
>
> Key: CAMEL-4213
> URL: https://issues.apache.org/jira/browse/CAMEL-4213
> Project: Camel
> Issue Type: Bug
> Components: camel-jpa, osgi
>Affects Versions: 2.7.2
> Environment: Apache Karaf 2.2.2
>Reporter: Jonas Bengtsson
> Fix For: 2.9.0
>
>
> When using the following simple route, the entity classes can't be found:
> {code}
> public void configure() throws Exception {
> from("direct:test-in").to("jpa:mypackage.MyEntity1");
> from("jpa:mypackage.MyEntity2").to("log:test-out");
> }
> {code}
> The error message is:
> 09:43:55,417 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity1
> 09:43:55,467 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity2
> followed by many warnings about that the entityType is not known for the
> consumer.
> The errors only occur when using blueprint to bootstrap the route. When using
> spring-dm everything works fine. The entity classes are located in the same
> bundle as the route. My guess is that it uses the wrong classloader.
> JPA works fine otherwise. It is only the camel-jpa component I have problems
> with. camel-jpa is a very spring-centric module, using a spring
> TransactionManager and all, so I hope that my use case makes sense.
> For completeness here is my blueprint-file:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
> default-activation="eager"
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0";>
> http://camel.apache.org/schema/blueprint";>
> mypackage
>
>
>ref="entityManagerFactory" />
>
>
>class="org.springframework.orm.jpa.JpaTransactionManager">
>ref="entityManagerFactory" />
>
>interface="javax.persistence.EntityManagerFactory"
> filter="(osgi.unit.name=myunit)" />
>
> {code}
> The EntityManagerFactory is created by Aries Jpa, but it shouldn't be
> relevant for the question.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4381) Simplify ServiceSupport and introduce ServiceWithStatus interface to remove tangle between util and support
[
https://issues.apache.org/jira/browse/CAMEL-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093492#comment-13093492
]
Claus Ibsen commented on CAMEL-4381:
Spotted another issue, in the ServiceSupport. The start/stop methods etc. when
an exception is thrown from doStart,doStop, then the state of the service
should be "changed back" etc. So if a service is attempted to be started and it
fails, then the old logic ensured the state would be as stopped. Now the logic
doesnt do that.
For example the "starting" state would be keept.
now
{code}
public void start() throws Exception {
if (isStarting() || isStarted()) {
// only start service if not already started
LOG.trace("Service already started");
return;
}
if (starting.compareAndSet(false, true)) {
LOG.trace("Starting service");
doStart();
started.set(true);
starting.set(false);
stopping.set(false);
stopped.set(false);
suspending.set(false);
suspended.set(false);
shutdown.set(false);
shuttingdown.set(false);
}
}
{code}
before:
{code}
public void start(boolean startChildren) throws Exception {
if (!started.get()) {
if (starting.compareAndSet(false, true)) {
boolean childrenStarted = false;
Exception ex = null;
try {
if (childServices != null && startChildren) {
ServiceHelper.startServices(childServices);
}
childrenStarted = true;
doStart();
} catch (Exception e) {
ex = e;
} finally {
if (ex != null) {
try {
stop(childrenStarted);
} catch (Exception e) {
// Ignore exceptions as we want to show the
original exception
}
throw ex;
} else {
started.set(true);
starting.set(false);
stopping.set(false);
stopped.set(false);
suspending.set(false);
suspended.set(false);
shutdown.set(false);
shuttingdown.set(false);
}
}
}
}
{code}
> Simplify ServiceSupport and introduce ServiceWithStatus interface to remove
> tangle between util and support
> ---
>
> Key: CAMEL-4381
> URL: https://issues.apache.org/jira/browse/CAMEL-4381
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.8.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 2.9.0
>
>
> Currently ServiceSupport and ServiceHelper form a dependency cycle.
> ServiceSupport calls ServiceHelper to start and stop services and
> ServiceSupport operate on ServiceSupport classes.
> To solve that I introduce an Interface ServiceWithSupport (open for a better
> naming). This interface extends Service and has all relevant methods from
> ServiceSupport. So ServiceHelper can operate on ServiceWithStatus and the
> tangle goes away.
> Addtionally I split up ServiceSupport into ServiceSupport which has no
> children and ChildServiceSupport which has. This is because we seem to have
> only two classes that actually use the children functionality. The rest of
> the classes that extend ServiceSupport have no children. So having them all
> extend the old ServiceSupport introduces a lot of unneeded complexity.
> The change should be fairly compatible. The only possible problem are third
> party components that use children. As we only had two such components in
> camel the chance that something breaks is fairly low.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4213) camel-jpa can't find entities when using blueprint in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093486#comment-13093486
]
Ioannis Canellos commented on CAMEL-4213:
-
ObjectHelper is using the Thread Context Class loader in order to resolve the
class. Spring DM sets the Thread Context Class Loader to the class loader of
the bundle that created the context, while blueprint does not.
I think that the problem could be solved if the OsgiClassResolver would use the
bundle class loader in order to resolve classes.
I could work on a patch, if you like.
> camel-jpa can't find entities when using blueprint in OSGi
> --
>
> Key: CAMEL-4213
> URL: https://issues.apache.org/jira/browse/CAMEL-4213
> Project: Camel
> Issue Type: Bug
> Components: camel-jpa, osgi
>Affects Versions: 2.7.2
> Environment: Apache Karaf 2.2.2
>Reporter: Jonas Bengtsson
> Fix For: 2.9.0
>
>
> When using the following simple route, the entity classes can't be found:
> {code}
> public void configure() throws Exception {
> from("direct:test-in").to("jpa:mypackage.MyEntity1");
> from("jpa:mypackage.MyEntity2").to("log:test-out");
> }
> {code}
> The error message is:
> 09:43:55,417 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity1
> 09:43:55,467 | WARN | rint Extender: 3 | ObjectHelper |
> g.apache.camel.util.ObjectHelper 698 | 78 - org.apache.camel.camel-core -
> 2.7.2 | Cannot find class: mypackage.MyEntity2
> followed by many warnings about that the entityType is not known for the
> consumer.
> The errors only occur when using blueprint to bootstrap the route. When using
> spring-dm everything works fine. The entity classes are located in the same
> bundle as the route. My guess is that it uses the wrong classloader.
> JPA works fine otherwise. It is only the camel-jpa component I have problems
> with. camel-jpa is a very spring-centric module, using a spring
> TransactionManager and all, so I hope that my use case makes sense.
> For completeness here is my blueprint-file:
> {code}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
> default-activation="eager"
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0";>
> http://camel.apache.org/schema/blueprint";>
> mypackage
>
>
>ref="entityManagerFactory" />
>
>
>class="org.springframework.orm.jpa.JpaTransactionManager">
>ref="entityManagerFactory" />
>
>interface="javax.persistence.EntityManagerFactory"
> filter="(osgi.unit.name=myunit)" />
>
> {code}
> The EntityManagerFactory is created by Aries Jpa, but it shouldn't be
> relevant for the question.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
