Camel netty encode bug
we tried to set up a custom encoder with netty tcp.
Here was our encoder class, for testing:
@Component(EndOfLineEncoder)
public class EndOfLineEncoder extends OneToOneEncoder{
@Override
protected Object encode(ChannelHandlerContext channelHandlerContext,
Channel channel, Object msg) throws Exception {
return msg;
}
}
Here was our routing:
from(stream:in)
.to(log:response)
.to(netty:tcp://localhost:10121?sync=trueencoder=#EndOfLineEncoder)
.to(log:response);
We tried to debug this problem for yours. We finally found out, that it
works, if we change encoder to encoders:
.to(netty:tcp://localhost:10121?sync=trueencoders=#EndOfLineEncoder)
So i guess it may be a bug - it is a single encoder, but it doesnt work if
we use encoder command.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-netty-encode-bug-tp4825369p4825369.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Camel netty encode bug
Hi
Its best to use the @user mailing list.
Anyway what version of Camel are you using?
On Wed, Sep 21, 2011 at 9:01 AM, stenver stenver1...@gmail.com wrote:
we tried to set up a custom encoder with netty tcp.
Here was our encoder class, for testing:
@Component(EndOfLineEncoder)
public class EndOfLineEncoder extends OneToOneEncoder{
@Override
protected Object encode(ChannelHandlerContext channelHandlerContext,
Channel channel, Object msg) throws Exception {
return msg;
}
}
Here was our routing:
from(stream:in)
.to(log:response)
.to(netty:tcp://localhost:10121?sync=trueencoder=#EndOfLineEncoder)
.to(log:response);
We tried to debug this problem for yours. We finally found out, that it
works, if we change encoder to encoders:
.to(netty:tcp://localhost:10121?sync=trueencoders=#EndOfLineEncoder)
So i guess it may be a bug - it is a single encoder, but it doesnt work if
we use encoder command.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-netty-encode-bug-tp4825369p4825369.html
Sent from the Camel Development mailing list archive at Nabble.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/
Mediatray for prinitercomponent
Hi, I have an question about the printercomponent. This component does currently not support things like MediaTray, are there any plans to add support for this printer attribute? Best regards, Evert
[jira] [Created] (CAMEL-4472) HazelcastComponentHelper. copyHeaders() creates an Out message
HazelcastComponentHelper. copyHeaders() creates an Out message
--
Key: CAMEL-4472
URL: https://issues.apache.org/jira/browse/CAMEL-4472
Project: Camel
Issue Type: Bug
Components: camel-hazelcast
Reporter: Tomislav Mrkus
Due to lazy creation of Out message in DefaultExchange.getOut() implementation,
HazelcastComponentHelper.copyHeaders() method inadvertently creates an Out
message if one has not been set yet, which then creates problems in
CamelInvocationHandler.getBody() which then returns null as a result.
There should be a check in copyHeaders() to see if Out exists, e.g.:
{code}
// set out headers
if (ex.hasOut()) {
ex.getOut().setHeaders(headers);
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4472) HazelcastComponentHelper. copyHeaders() creates an Out message
[
https://issues.apache.org/jira/browse/CAMEL-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomislav Mrkus updated CAMEL-4472:
--
Attachment: CAMEL-4472.patch
HazelcastComponentHelper. copyHeaders() creates an Out message
--
Key: CAMEL-4472
URL: https://issues.apache.org/jira/browse/CAMEL-4472
Project: Camel
Issue Type: Bug
Components: camel-hazelcast
Reporter: Tomislav Mrkus
Attachments: CAMEL-4472.patch
Due to lazy creation of Out message in DefaultExchange.getOut()
implementation, HazelcastComponentHelper.copyHeaders() method inadvertently
creates an Out message if one has not been set yet, which then creates
problems in CamelInvocationHandler.getBody() which then returns null as a
result.
There should be a check in copyHeaders() to see if Out exists, e.g.:
{code}
// set out headers
if (ex.hasOut()) {
ex.getOut().setHeaders(headers);
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
[ https://issues.apache.org/jira/browse/CAMEL-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Zhemzhitsky updated CAMEL-4473: -- Attachment: camel-cxf-binding-failure-test.zip Unit test has been attached Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Attachments: camel-cxf-binding-failure-test.zip Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4474) file: consumer does not create directory
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreate trueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13109460#comment-13109460
]
Sergey Zhemzhitsky commented on CAMEL-4397:
---
Hi guys,
What do you think about org.apache.camel.spi.RoutePolicy implementation that
uses hazelcast to support distributed locking/unloking?
Such a route policy will force the route to run only on a single node in the
cluster.
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
Attachments: CAMEL-4397.patch
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (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:comment-tabpanelfocusedCommentId=13109460#comment-13109460
]
Sergey Zhemzhitsky edited comment on CAMEL-4397 at 9/21/11 1:29 PM:
Hi guys,
What do you think about org.apache.camel.spi.RoutePolicy implementation that
uses hazelcast to support distributed locking/unloking?
Such a route policy will force the route to run only on a single node in the
cluster. Moreover there can be two route policies:
# the first one will create a distributed lock on every incoming exchange and
will release the lock when exchange processing completes. This policy will
allow to process exchange only on a single node of the cluster at a given time.
When exchange processing completes the second node in the cluster will be able
to obtain a lock.
# the second route policy will create a distributed lock on route startup, and
will release the lock on route shutdown, so the route will run only on a single
node in the cluster all the time.
was (Author: szhemzhitsky):
Hi guys,
What do you think about org.apache.camel.spi.RoutePolicy implementation that
uses hazelcast to support distributed locking/unloking?
Such a route policy will force the route to run only on a single node in the
cluster.
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
Attachments: CAMEL-4397.patch
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Camel 2.8.2 - Reason for the many backports?
This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's about average at this point. On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsenclaus.ib...@gmail.com wrote: Hi Dan what is the reason why you backport so many commits to 2.8.2 from 2.9? The problem is that its a lot of new features, non trivial bug fixes and whatnot. People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2 because of the big difference. People is more prepared for a little trouble when doing 2.8.0 to 2.9.0 upgrade. But not for an upgrade in 2.8.x branch. Also for new features and whatnot we update the documentation to indicate eg *Camel 2.9* that this is a new feature in that version. These documentation changes is not part of the SVN and thus you lose this, and cannot keep the documentation- source code in sync. Yea. Docs are definitely an issue. I'll admit that. They don't really end up wrong, but not 100% correct either. :-) If you consider a feature not complete until documented, and it's not documented until 2.9, then the docs are correct if they say 2.9.Yea, kind of a silly answer. Fixing the docs should definitely be done as well. I'll try and look a little at that in the next couple days. (and thanks Jon for the help!) In anycase, I'm trying to provide a usable solution for our users. This processed has worked extremely well based on past experience. If there is a particular commit that I merged back that you are particularly concerned about, feel free to bring it up. We can work on finding a solution that would solve the problem in a way with less impact on the users. Dan -- 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/ -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Camel 2.8.2 - Reason for the many backports?
For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's about average at this point. On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsenclaus.ib...@gmail.com wrote: Hi Dan what is the reason why you backport so many commits to 2.8.2 from 2.9? The problem is that its a lot of new features, non trivial bug fixes and whatnot. People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2 because of the big difference. People is more prepared for a little trouble when doing 2.8.0 to 2.9.0 upgrade. But not for an upgrade in 2.8.x branch. Also for new features and whatnot we update the documentation to indicate eg *Camel 2.9* that this is a new feature in that version. These documentation changes is not part of the SVN and thus you lose this, and cannot keep the documentation- source code in sync. Yea. Docs are definitely an issue. I'll admit that. They don't really end up wrong, but not 100% correct either. :-) If you consider a feature not complete until documented, and it's not documented until 2.9, then the docs are correct if they say 2.9.Yea, kind of a silly answer. Fixing the docs should definitely be done as well. I'll try and look a little at that in the next couple days. (and thanks Jon for the help!) In anycase, I'm trying to provide a usable solution for our users. This processed has worked extremely well based on past experience. If there is a particular commit that I merged back that you are particularly concerned about, feel free to bring it up. We can work on finding a solution that would solve the problem in a way with less impact on the users. Dan -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/
[jira] [Assigned] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
[ https://issues.apache.org/jira/browse/CAMEL-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-4473: --- Assignee: Willem Jiang Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Assignee: Willem Jiang Attachments: camel-cxf-binding-failure-test.zip Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Camel 2.8.2 - Reason for the many backports?
On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list.:-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF.Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's about average at this point. On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsenclaus.ib...@gmail.com wrote: Hi Dan what is the reason why you backport so many commits to 2.8.2 from 2.9? The problem is that its a lot of new features, non trivial bug fixes and whatnot. People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2 because of the big difference. People is more prepared for a little trouble when doing 2.8.0 to 2.9.0 upgrade. But not for an upgrade in 2.8.x branch. Also for new features and whatnot we update the documentation to indicate eg *Camel 2.9* that this is a new feature in that version. These documentation changes is not part of the SVN and thus you lose this, and cannot keep the
[jira] [Commented] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109534#comment-13109534
]
Taariq Levack commented on CAMEL-4474:
--
David can you please post a test for this?
There are tests[1] for this code so maybe you missed something with permissions
etc.
[1]
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/FileConsumerAutoCreateDirectoryTest.java
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109534#comment-13109534
]
Taariq Levack edited comment on CAMEL-4474 at 9/21/11 2:40 PM:
---
David can you please post a test for this?
There are tests[1] for this code so maybe you missed something with permissions
etc, or of course maybe these tests miss something.
[1]
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/FileConsumerAutoCreateDirectoryTest.java
was (Author: taariql):
David can you please post a test for this?
There are tests[1] for this code so maybe you missed something with permissions
etc.
[1]
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/component/file/FileConsumerAutoCreateDirectoryTest.java
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4366) Expose Exchange Load statistics in Route and Context MBeans
[ https://issues.apache.org/jira/browse/CAMEL-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-4366. Resolution: Fixed Expose Exchange Load statistics in Route and Context MBeans --- Key: CAMEL-4366 URL: https://issues.apache.org/jira/browse/CAMEL-4366 Project: Camel Issue Type: New Feature Components: camel-core, jmx Reporter: christian ohr Assignee: Claus Ibsen Priority: Minor Fix For: 2.9.0 Attachments: Load.png, load-patch-1 Add load statistics exposing a exponentially moving weighted average for the number of inflight exchanges in routes and the whole CamelContext. Initially the window is fixed to 1m, 5m and 15m, just like Linux load figures. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4472) HazelcastComponentHelper. copyHeaders() creates an Out message
[
https://issues.apache.org/jira/browse/CAMEL-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109590#comment-13109590
]
Claus Ibsen commented on CAMEL-4472:
The copyHeaders is only used by the producers as a mean to preserve headers
after sending a message to hazelcast. So we should be okay with this patch.
HazelcastComponentHelper. copyHeaders() creates an Out message
--
Key: CAMEL-4472
URL: https://issues.apache.org/jira/browse/CAMEL-4472
Project: Camel
Issue Type: Bug
Components: camel-hazelcast
Reporter: Tomislav Mrkus
Attachments: CAMEL-4472.patch
Due to lazy creation of Out message in DefaultExchange.getOut()
implementation, HazelcastComponentHelper.copyHeaders() method inadvertently
creates an Out message if one has not been set yet, which then creates
problems in CamelInvocationHandler.getBody() which then returns null as a
result.
There should be a check in copyHeaders() to see if Out exists, e.g.:
{code}
// set out headers
if (ex.hasOut()) {
ex.getOut().setHeaders(headers);
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4472) HazelcastComponentHelper. copyHeaders() creates an Out message
[
https://issues.apache.org/jira/browse/CAMEL-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4472.
Resolution: Fixed
Fix Version/s: 2.9.0
2.8.2
Assignee: Claus Ibsen
HazelcastComponentHelper. copyHeaders() creates an Out message
--
Key: CAMEL-4472
URL: https://issues.apache.org/jira/browse/CAMEL-4472
Project: Camel
Issue Type: Bug
Components: camel-hazelcast
Reporter: Tomislav Mrkus
Assignee: Claus Ibsen
Fix For: 2.8.2, 2.9.0
Attachments: CAMEL-4472.patch
Due to lazy creation of Out message in DefaultExchange.getOut()
implementation, HazelcastComponentHelper.copyHeaders() method inadvertently
creates an Out message if one has not been set yet, which then creates
problems in CamelInvocationHandler.getBody() which then returns null as a
result.
There should be a check in copyHeaders() to see if Out exists, e.g.:
{code}
// set out headers
if (ex.hasOut()) {
ex.getOut().setHeaders(headers);
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13109597#comment-13109597
]
Claus Ibsen commented on CAMEL-4397:
Sergey sounds good. And possible make it possible for end users to provide a
3rd option, some may want to look at load on servers, and allow the server with
the lowest load to favor the lock. And whatnot. But that is just a wish. Having
1 and 2 is good.
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
Attachments: CAMEL-4397.patch
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109600#comment-13109600
]
Taariq Levack commented on CAMEL-4474:
--
You're using a dot in the directory name which is not allowed, is this the
error you're getting?
IllegalArgumentException(Only directory is supported. Endpoint must be
configured with a valid starting directory: + file);
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
Attachments: Camel4474.java, app-config-context.xml,
app-config.properties, test-context.xml
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109617#comment-13109617
]
David J. M. Karlsen commented on CAMEL-4474:
I will have to test tomorrow at work. But I do not see this requirement
documented an place: http://camel.apache.org/file2.html .
It's also not a problem as long as the directory in fact exists - so I doubt
that is the case - but I'll double check tomorrow.
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
Attachments: Camel4474.java, app-config-context.xml,
app-config.properties, test-context.xml
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13109638#comment-13109638
]
Ben O'Day commented on CAMEL-4397:
--
hey Sergey, what you described is CAMEL-4454...using a RoutePolicy/Hazelcast
seems to make the most sense there.
My use case is slightly different. We have data (Orders, etc) that is modified
in multiple routes and also by POJOs in other apps. I was hoping to leverage
Hazelcast to manage the distributed Lock on this data (to prevent stale
read/writes, etc) regardless of where the Lock was created. So, my approach
was to create the Lock on specific Exchange data (OrderID) based on an
Expression. Also, I don't want to stop the route consumer altogether, but only
block the threads processing specific data (based on OrderID) to allow the
route to continue processing other data (other Orders) to preserve processing
throughput.
That being said, perhaps this should be done with a RoutePolicy (or is
overambitious altogether). I was just trying to leverage the existing
camel-hazelcast component since it seemed to fit there...I'll give it some more
thought.
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
Attachments: CAMEL-4397.patch
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{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(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{code}
see this
discussion...http://camel.465427.n5.nabble.com/discuss-implementing-Locks-in-Camel-td4775904.html
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(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{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
Attachments: CAMEL-4397.patch
add support for Hazelcast distributed locking/unlocking APIs in a route...see
http://www.hazelcast.com/documentation.jsp#Lock
something like this...
{code}
from(seda:lockTest)
.doTry()
.setHeader(HazelcastConstants.LOCK_OBJECT, simple(ID-${header.id}))
.to(hazelcast:lock)
.setBody(simple(processed[${body}]))
.to(mock:mock)
.doFinally()
.to(hazelcast:unlock);
{code}
see this
discussion...http://camel.465427.n5.nabble.com/discuss-implementing-Locks-in-Camel-td4775904.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
[ https://issues.apache.org/jira/browse/CAMEL-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109670#comment-13109670 ] Sergey Zhemzhitsky commented on CAMEL-4473: --- Hi, please change the extension of the attachment to 7z. Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Assignee: Willem Jiang Attachments: camel-cxf-binding-failure-test.zip Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Camel 2.8.2 - Reason for the many backports?
Awesome! - thanks Dan On 21 Sep 2011, at 15:23, Daniel Kulp wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list.:-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF.Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's about average at this point. On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsenclaus.ib...@gmail.com wrote: Hi Dan what is the reason why you backport so many commits to 2.8.2 from 2.9? The problem is that its a lot of new features, non trivial bug fixes and whatnot. People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2 because of the big difference. People is more prepared for a little trouble when doing 2.8.0 to 2.9.0 upgrade. But not for an upgrade in 2.8.x branch. Also for new features and whatnot we update the documentation to indicate eg *Camel 2.9* that this is a new feature in that version. These documentation changes is not part of the SVN and thus you lose this, and cannot keep the
[jira] [Resolved] (CAMEL-4431) Zookeeper tests do not work on windows
[ https://issues.apache.org/jira/browse/CAMEL-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CAMEL-4431. Resolution: Fixed Zookeeper tests do not work on windows -- Key: CAMEL-4431 URL: https://issues.apache.org/jira/browse/CAMEL-4431 Project: Camel Issue Type: Test Components: camel-zookeeper Affects Versions: 2.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.9.0 All zookeeper tests after the first class fail with the following exception: java.lang.Exception: Could not delete Test Zookeeper Server working dir ./target/zookeeper This happens because the log file is still in use and so windows refuses to delete the directory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-4431) Zookeeper tests do not work on windows
[ https://issues.apache.org/jira/browse/CAMEL-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider closed CAMEL-4431. -- Zookeeper tests do not work on windows -- Key: CAMEL-4431 URL: https://issues.apache.org/jira/browse/CAMEL-4431 Project: Camel Issue Type: Test Components: camel-zookeeper Affects Versions: 2.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.9.0 All zookeeper tests after the first class fail with the following exception: java.lang.Exception: Could not delete Test Zookeeper Server working dir ./target/zookeeper This happens because the log file is still in use and so windows refuses to delete the directory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
[ https://issues.apache.org/jira/browse/CAMEL-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Zhemzhitsky updated CAMEL-4473: -- Attachment: (was: camel-cxf-binding-failure-test.zip) Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Assignee: Willem Jiang Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4473) Unable to use cxf:binding configuration for the endpoint
[ https://issues.apache.org/jira/browse/CAMEL-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Zhemzhitsky updated CAMEL-4473: -- Attachment: camel-cxf-binding-failure-test.zip Valid camel-cxf-binding-failure-test.zip zip archive with unit test has been attached. The old one has been deleted. Unable to use cxf:binding configuration for the endpoint Key: CAMEL-4473 URL: https://issues.apache.org/jira/browse/CAMEL-4473 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.1 Reporter: Sergey Zhemzhitsky Assignee: Willem Jiang Attachments: camel-cxf-binding-failure-test.zip Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'service': Error setting property val ues; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.ap ache.camel.component.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the pa rameter 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.doCreateBean(AbstractAutowireCapableBeanFactory .java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.j ava:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.jav a:580) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.ja va:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84) at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1) at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280) at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304) ... 30 more Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'bindingConfig' of bean class [org.apache.camel.com ponent.cxf.CxfSpringEndpoint]: Bean property 'bindingConfig' is not writable or has an invalid setter method. Does the parameter type o f 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:900) 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) ... 44 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4475) Make API self contained
Make API self contained --- Key: CAMEL-4475 URL: https://issues.apache.org/jira/browse/CAMEL-4475 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.9.0 The API, SPI packages of camel are already quite independent after the previous refactorings. There are three classes in model that are still needed at the moment. ProcessorDefinition, RouteDefinition and FromDefiniton I propose to add the necessary methods to NamedNode to be able to reference most of the functionality of the classes. For RouteDefinition I propose a special interface that adds the ErrorHandler. For the rare cases where more functionality is needed a instanceof and a cast can be used. I will attach a patch shortly that solves the issue and would be glad about some reviews. The patch can not be fully compatible but the changes are mostly in spi interfaces that are probably rather rarely used. I will also add screenshots from structure 101 that show how much the architecture improves after this patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4475) Make API self contained
[ https://issues.apache.org/jira/browse/CAMEL-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated CAMEL-4475: --- Attachment: camel-4475-after.png camel-4475-before.png Make API self contained --- Key: CAMEL-4475 URL: https://issues.apache.org/jira/browse/CAMEL-4475 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.9.0 Attachments: camel-4475-after.png, camel-4475-before.png The API, SPI packages of camel are already quite independent after the previous refactorings. There are three classes in model that are still needed at the moment. ProcessorDefinition, RouteDefinition and FromDefiniton I propose to add the necessary methods to NamedNode to be able to reference most of the functionality of the classes. For RouteDefinition I propose a special interface that adds the ErrorHandler. For the rare cases where more functionality is needed a instanceof and a cast can be used. I will attach a patch shortly that solves the issue and would be glad about some reviews. The patch can not be fully compatible but the changes are mostly in spi interfaces that are probably rather rarely used. I will also add screenshots from structure 101 that show how much the architecture improves after this patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4475) Make API self contained
[ https://issues.apache.org/jira/browse/CAMEL-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated CAMEL-4475: --- Attachment: camel-4475-1.patch Make API self contained --- Key: CAMEL-4475 URL: https://issues.apache.org/jira/browse/CAMEL-4475 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.9.0 Attachments: camel-4475-1.patch, camel-4475-after.png, camel-4475-before.png The API, SPI packages of camel are already quite independent after the previous refactorings. There are three classes in model that are still needed at the moment. ProcessorDefinition, RouteDefinition and FromDefiniton I propose to add the necessary methods to NamedNode to be able to reference most of the functionality of the classes. For RouteDefinition I propose a special interface that adds the ErrorHandler. For the rare cases where more functionality is needed a instanceof and a cast can be used. I will attach a patch shortly that solves the issue and would be glad about some reviews. The patch can not be fully compatible but the changes are mostly in spi interfaces that are probably rather rarely used. I will also add screenshots from structure 101 that show how much the architecture improves after this patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109759#comment-13109759
]
David J. M. Karlsen commented on CAMEL-4474:
Hah! You are dead-right - but why??
{noformat}
Caused by: org.apache.camel.RuntimeCamelException:
java.lang.IllegalArgumentException: Only directory is supported. Endpoint must
be configured with a valid starting directory: target/incoming.dir
at
org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1145)
at
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:108)
at
org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:240)
at
{noformat}
Changing it to one w/o dot fixed it - and the error message Only directory is
supported. is misleading.
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
Attachments: Camel4474.java, app-config-context.xml,
app-config.properties, test-context.xml
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Camel netty encode bug
okei, i think i am subscribed now. Our maven is using this version: version.camel2.7.1/version.camel We do not need a bug fix, as we found out that we need multiple codec. We are just reporting a bug. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-netty-encode-bug-tp4825369p4827395.html Sent from the Camel Development mailing list archive at Nabble.com.
[jira] [Resolved] (CAMEL-4097) Add option on aggregation to flush on shutdown
[ https://issues.apache.org/jira/browse/CAMEL-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-4097. -- Resolution: Fixed change committed and docs updated (Aggregator2, 2.9 Release Notes)... Add option on aggregation to flush on shutdown -- Key: CAMEL-4097 URL: https://issues.apache.org/jira/browse/CAMEL-4097 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Claus Ibsen Assignee: Ben O'Day Priority: Minor Fix For: 2.9.0 Attachments: CAMEL-4097.patch We may want to add options to stateful EIPs such as aggregator/resequencer that they should flush on shutdown. People who dont use a persistent store would loose the in-memory partly aggregated exchanges. See nabble http://camel.465427.n5.nabble.com/Aggregator-completeOnShutdown-tp4423774p4423774.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4476) Camel splitter/aggregator 2x slower in 2.8.1 vs 2.7.3
Camel splitter/aggregator 2x slower in 2.8.1 vs 2.7.3 - Key: CAMEL-4476 URL: https://issues.apache.org/jira/browse/CAMEL-4476 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.8.1 Environment: Oracle JDK 1.6.0_26 64-bit, CentOS 6 64-bit Reporter: Bryan Keller I noticed a sharp decline in the performance of my application when I upgraded from Camel 2.7.3 to 2.8.1. I discovered that the splitter/aggregator had become the bottleneck in my app. I have created a sample app that demonstrates the issue. The aggregator uses a lock, and I suspect lock contention may be at the root of this, but didn't notice any changes around that in the code diff between the versions. I uploaded the sample app to http://www.vancameron.net/CamelPerf.zip. It uses gradle. Unzip to a directory then run gradle from the command line. To change the version from 2.8.1 to 2.7.3, edit the build.gradle file and run again. The app loads 10 files with 100k lines each. It prints the current time in msec per batch. -- 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-tabpanelfocusedCommentId=13112283#comment-13112283 ] Hadrian Zbarcea commented on CAMEL-4034: @Ioannis, committed patch and minor fixes, but still have another change to commit tomorrow. Thanks for the contribution! 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
Re: Camel 2.8.2 - Reason for the many backports?
May I miss something, but at the moment it's not really clear for me WHAT should be backported. Do we backport EVERYTHING which doesn't break existing code (not only bugs)? Also new features and enhancements with the risk of introducing new bugs? Only to make it clear for me and may others... And by Awesome! - thanks Dan On 21 Sep 2011, at 15:23, Daniel Kulp wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list. :-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's about average at this point. On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsenclaus.ib...@gmail.com wrote: Hi Dan what is the reason why you backport so many commits to 2.8.2 from 2.9? The problem is that its a lot of new features, non trivial bug fixes and whatnot. People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2 because of the big difference. People is more prepared for a little trouble when doing 2.8.0 to 2.9.0 upgrade. But not for an upgrade in 2.8.x branch.
Re: Camel 2.8.2 - Reason for the many backports?
I'll step in here… Much of what Dan has done is in the corporate world very very much wanted. Dan offered his time to keep on back porting fixing and non api breaking features. That means we'll see (and we can debate that) done in 2.9, available in 2.8.5) I think Dan already said he should have said more of a hey, debating if we need this is going to go in the insane bin, most customers I work with complain about the lack of a stable train that provides fixes with no upgrades…. /je On Sep 21, 2011, at 8:08 PM, Christian Müller wrote: May I miss something, but at the moment it's not really clear for me WHAT should be backported. Do we backport EVERYTHING which doesn't break existing code (not only bugs)? Also new features and enhancements with the risk of introducing new bugs? Only to make it clear for me and may others... And by Awesome! - thanks Dan On 21 Sep 2011, at 15:23, Daniel Kulp wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list. :-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to
[jira] [Commented] (CAMEL-4474) file: consumer does not create directory
[
https://issues.apache.org/jira/browse/CAMEL-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13112328#comment-13112328
]
Taariq Levack commented on CAMEL-4474:
--
Great.
The reason is stated in the comments in FileEndpoint;
// we assume its a file if the name has a dot in it (eg foo.txt)
Since a directory can have a dot, like .m2, .camel etc, we should perhaps
always assume it's a directory, but that doesn't sound right either.
Feel free to submit a patch to improve the code or even documentation to make
it clearer.
file: consumer does not create directory
Key: CAMEL-4474
URL: https://issues.apache.org/jira/browse/CAMEL-4474
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.8.1
Environment: java 1.6
Reporter: David J. M. Karlsen
Labels: component, consumer, file
Attachments: Camel4474.java, app-config-context.xml,
app-config.properties, test-context.xml
According to http://camel.apache.org/file2.html autoCreate is true by default
and should for a consumer create the directory.
{noformat}
autoCreatetrueAutomatically create missing directories in the file's
pathname. For the file consumer, that means creating the starting directory.
For the file producer, it means the directory the files should be written to.
{noformat}
This does not happen and thus a route startup would fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Camel 2.8.2 - Reason for the many backports?
On Thu, Sep 22, 2011 at 4:08 AM, Christian Müller christian.muel...@gmail.com wrote: May I miss something, but at the moment it's not really clear for me WHAT should be backported. Me too. Do we backport EVERYTHING which doesn't break existing code (not only bugs)? Also new features and enhancements with the risk of introducing new bugs? Only to make it clear for me and may others... I would not favor that as new code may introduce new bugs and other side effects. I would rather allow people to have a stable branch where bug fixes is the primary reason for backporting. There may be good reasons to backport a non-bug ticket, but then we ought to be more careful when doing this. For example I think the Karaf team discuss this on @dev which tickets to backport. And by Awesome! - thanks Dan On 21 Sep 2011, at 15:23, Daniel Kulp wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list. :-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have no impact on existing users, but makes it possible to use Camel by a wider audience. So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable. Compared to any CXF patch release, it's
Re: Camel 2.8.2 - Reason for the many backports?
On Thu, Sep 22, 2011 at 4:17 AM, Johan Edstrom seij...@gmail.com wrote: I'll step in here… Much of what Dan has done is in the corporate world very very much wanted. Dan offered his time to keep on back porting fixing and non api breaking features. Dan is not the only person doing this. We are already backporting to the 2.8 branch. Also after the 2.8.1 release. Well there were some API breakings in there, however on the small side as they face internally, but still. Some commits wasn't necessary to backport as they cases these minor/micro API changes. That means we'll see (and we can debate that) done in 2.9, available in 2.8.5) I think Dan already said he should have said more of a hey, debating if we need this is going to go in the insane bin, most customers I work with complain about the lack of a stable train that provides fixes with no upgrades…. The 2.8.2 would have become more stable if there was not backported soo many changes. /je On Sep 21, 2011, at 8:08 PM, Christian Müller wrote: May I miss something, but at the moment it's not really clear for me WHAT should be backported. Do we backport EVERYTHING which doesn't break existing code (not only bugs)? Also new features and enhancements with the risk of introducing new bugs? Only to make it clear for me and may others... And by Awesome! - thanks Dan On 21 Sep 2011, at 15:23, Daniel Kulp wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list. :-( Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just
Re: Camel 2.8.2 - Reason for the many backports?
On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp dk...@apache.org wrote: On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote: For my part it is the principle - at some point this will go wrong - doing what Chistian suggested makes a lot of sense. And, users in production want stability, fixes are good, new features leads naturally to concern about stability. It should be good practice to give a heads up at least, before backporting new features. I agree that I should have given a better hey, ton of stuff going to happen heads up Monday morning (or Friday). Thanks. We are not accustomed to see 70-100 backports on the 2.x branch overnight. So we were wonder what happened. If some auto tool have been enabled or whatnot? That said, I had complete intention after 2.8.0 was released to try and port things back more on a weekly basis or so. That makes things a LOT easier to do. Reviewing 380+ commits in one day is really not fun. :-) I've just been quite a bit busy on other things that the Camel porting kept falling off the bottom of my weekly todo list. :-( I think its better to have the person who worked on the ticket backport the ticket. For example as myself, Willem and some others already do. After the changes is committed to trunk, we take time to backport it as well. The reason is that we know best if that ticket would be good to packport or not. Going forward, it may be a good idea to put a note in the JIRA ticket if the ticket is not ideal to backport. Going forward, I'm hoping to keep being able to port fixes and such back on a semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously, any help from anyone else would be greatly appreciated. In CXF, over time, I've gotten more help from Sergey and Willem and Freeman and others and I greatly appreciate their efforts. I've seen Claus and Jon and others pulling things back here as well which is definitely appreciated. Good idea, but see above. We should do both. Have the habit of backport the change at the same time you commit to trunk. Then its fresh in memory and we get it done at the best time. Having a semi-weekly basis as well, helps make sure we catch tickets which for some reason wasn't, or there has come up good cause to backport some tickets etc. Dan On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote: This is an emotional non-discussion. The question in the title is what is the reason for the *many* backports. An explanation was also given: if they are *many* bugs (or improvements), they should be fixed, and in dkulp's opinion not only on the trunk but also on the maintained branches. There is also an expectation for the fixes to be backwards compatible, which is absolutely normal. From what I see the expectation was fulfilled. Rob seems to imply that he trusts Dan to do the right thing, but he's concerned about the precedent he sets for the less talented rest of us who might go wild and break things. Did I get it right? Is there a particular commit that triggered this question, or is more the principle? Hadrian On 09/21/2011 01:36 AM, Rob Davies wrote: Dan it admirable what you want to do but it would be better to encourage collective best practice - so we do not break backward compatibility on a released branch. That's why discussing adding new features, or changes to dependencies on the DEV list first is a good idea. it will set the pattern that others will follow. Its not that we expect that you will break anything, but others might do by accident. On 21 Sep 2011, at 04:08, Daniel Kulp wrote: On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote: Hi Dan Do you care to discuss this? You keep on backporting non bug fixes, new features and whatnot. People who run Camel in production and they may want to upgrade to 2.8.2 due to a bug. They frankly do not like a lot of changes. As any change in a production system is not desireable. And there are even more people that are trying to move their applications from development into testing or production and cannot because they are hitting specific bugs or require some trivial features or issues to be resolved. If a user reports a bug (and even better, provides a patch), we definitely owe it to them to get that fix pulled back relatively quickly. Camel has historically done a VERY poor job of doing that. I keep talking to people that have either had to fork Camel internally to get patches applied or go to a third party to demand various things ported back. In both cases, I just cringe as that shows that we, as a community, have failed our users. Likewise, if a user needs a trivial change in order to get Camel into production, we should try and get that change to them WITHOUT a huge upgrade hassle. Things like new methods, new config options (as long as the defaults remain as before), etc... that would have
