[jira] Commented: (CAMEL-316) Merge Fault and Exception semantics
[ https://issues.apache.org/activemq/browse/CAMEL-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50984#action_50984 ] Claus Ibsen commented on CAMEL-316: --- Hadrian, I think its very late, and unless the change have minimal impact on eg SMX then its possible otherwise I would like to leave as is. If we remove fault all together there is quite some code that depends on it, and how does SMX handle this? We are pushing the last must have for Camel 2.0 to get it done in due time, eg hopefully in 2-3 weeks. > Merge Fault and Exception semantics > --- > > Key: CAMEL-316 > URL: https://issues.apache.org/activemq/browse/CAMEL-316 > Project: Apache Camel > Issue Type: Improvement >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.0.0 > > > The fact that there are output/fault/exception could be confusing and clutter > the dsl, especially for components where there is no distinction between > fault and exception. We should merge the two and simplify the model. > See nabble thread: > http://www.nabble.com/in-out-fault-messages-discussion-to14170013s22882.html#a14170013 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50983#action_50983 ] Claus Ibsen commented on CAMEL-1507: Ryan/William We also need to update the mail wiki page with this feature. At least document its possible and give some hints how to do it. And it would be great with a sample how to do it, and you can use the SNIPPETS in the unit test to put it on the wiki pages. > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Fix For: 2.0.0 > > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50982#action_50982 ] Claus Ibsen commented on CAMEL-1507: I renamed the constant so its according to the Camel 2.0 syntax: rev 761182 on trunk > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Fix For: 2.0.0 > > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move the Camel features into Camel
Just a quick question about it. Since camel components have lots of third party dependencies, if we move the Camel features from SMX to Camel, do we need to provide the third party bundles in Camel or just use the bundles in Servicemix's repository? +1 for moving the Camel features into Camel. Willem. Hadrian Zbarcea wrote: > +1 > > On Apr 1, 2009, at 1:50 PM, Gert Vanthienen wrote: > >> L.S., >> >> Currently, a features descriptor for Camel is being generated in the >> ServiceMix 4 features projects. This descriptor basically is an XML >> file that allows you to install any Camel component on ServiceMix >> Kernel in a single command. The information in the descriptor will be >> used to determine which others OSGi bundles are required. >> >> We now released ServiceMix 4.0.0 with a features descriptor for Camel >> 1.6.0, but on the Camel project itself we're now working on >> 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move >> the generation process of the features descriptor into the Camel >> project itself, so every release of Camel can come with its own >> features descriptor. It will also make it easier for people to test a >> SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up >> their own descriptor first. >> >> If we look at the codebase, it will basically mean that we would have >> to move the pom.xml and properties file that's currently at >> https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ >> >> to e.g. a /platform/servicemix-kernel directory in the Camel project. >> >> Any thoughs? >> >> Gert Vanthienen >> >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ > >
[jira] Commented: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50981#action_50981 ] Willem Jiang commented on CAMEL-1507: - @Rayan, Don't worry about the MailConstants issue, I already did a quick fix for that. > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Fix For: 2.0.0 > > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-316) Merge Fault and Exception semantics
[ https://issues.apache.org/activemq/browse/CAMEL-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50980#action_50980 ] Hadrian Zbarcea commented on CAMEL-316: --- I think we should tackle this in 2.0. I will look at it again this weekend. > Merge Fault and Exception semantics > --- > > Key: CAMEL-316 > URL: https://issues.apache.org/activemq/browse/CAMEL-316 > Project: Apache Camel > Issue Type: Improvement >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.0.0 > > > The fact that there are output/fault/exception could be confusing and clutter > the dsl, especially for components where there is no distinction between > fault and exception. We should merge the two and simplify the model. > See nabble thread: > http://www.nabble.com/in-out-fault-messages-discussion-to14170013s22882.html#a14170013 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Apachem Camel with Oracle AQ
Hi,
i'm using Oracle AQ with apache camel. I have a very simple code like this:
---
package pl.sbsd.apachecamel.oracleaq;
import javax.jms.ConnectionFactory;
import oracle.jdbc.pool.OracleDataSource;
import oracle.jms.AQjmsFactory;
import org.apache.camel.CamelContext;
import org.apache.camel.Consumer;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.component.jms.JmsComponent;
import org.apache.camel.impl.DefaultCamelContext;
public class OracleAQApp {
private String uri;
private String login;
private String password;
private final String jdbcUrl = "jdbc:oracle:thin:@xxx:1521:xxx";
private CamelContext camel;
private ConnectionFactory connectionFactory;
private ProducerTemplate producerTemplate;
public OracleAQApp(String uri, String login, String password)
throws Exception {
this.uri = uri;
this.login = login;
this.password = password;
OracleDataSource dataSource = new OracleDataSource();
dataSource.setURL(jdbcUrl);
dataSource.setUser(login);
dataSource.setPassword(password);
connectionFactory =
AQjmsFactory.getQueueConnectionFactory(dataSource);
camel = new DefaultCamelContext();
JmsComponent jmsComponent = new JmsComponent(camel);
jmsComponent.setConnectionFactory(connectionFactory);
camel.addComponent("jms", jmsComponent);
producerTemplate = camel.createProducerTemplate();
Consumer consumer = camel.getEndpoint(uri).createConsumer(
new Processor() {
public void process(Exchange exchange)
throws Exception {
System.out.println("New
message!");
System.out.println(exchange.getIn().getBody());
}
});
consumer.start();
camel.start();
}
public void send(String message) throws InterruptedException {
producerTemplate.sendBody(uri, message);
Thread.sleep(50);
}
}
---
I'm sending some message to the queue and the consumer will consume it. That
works with my local installation of oracle database. When i'm using remote
database which is in the LAN then the messages are writting into the queue
but consumer can't dequeue them. In the eclipse console i get this message:
---
Exception in thread "DefaultMessageListenerContainer-1"
java.lang.NullPointerException
at java.lang.String.indexOf(String.java:1564)
at java.lang.String.indexOf(String.java:1546)
at
org.springframework.jms.support.JmsUtils.buildExceptionMessage(JmsUtils.java:255)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.handleListenerSetupFailure(DefaultMessageListenerContainer.java:745)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:897)
at java.lang.Thread.run(Thread.java:595)
---
I have debugged the DefaultMessageListenerContainer and there is a exception
with information: "JMS-120: Dequeue failed.". I dont now what can it be.
Everythink works when i'm using local database. I've tested many jdbc
drivers "ojdbc*.jar" and oracle aq apis "aqapi*.jar" but nothing. I've
privileges to dequeue the messages.
Kind regards
Sebastian
--
View this message in context:
http://www.nabble.com/Apachem-Camel-with-Oracle-AQ-tp22841667p22841667.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Move the Camel features into Camel
+1 On Apr 1, 2009, at 1:50 PM, Gert Vanthienen wrote: L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[jira] Commented: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50978#action_50978 ] Ryan Gardner commented on CAMEL-1507: - Do you want me to tweak the patch to rename the alternate body header tag andif move it to the MailConstants? If you have any other things you don't like about it, let me know and I can work on it tomorrow. > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Fix For: 2.0.0 > > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
CAMEL 2.0 - The remaining work
Hi We are in the final phase of Camel 2.0 and need to get the last features and fixes done. I have been looking at the JIRA tickets and moved stuff for 2.1. There are 2 issues we must address: === 1) Change default error handler strategy (CAMEL-714) to no error handling at all I am currently working on this one. 2) StreamCache to work out of the box with all the error handler strategies (I does not work with TX for instance) and seamless with SMX We need to work together with Gert on this one. Could be that streamCache should be enabled by default. And these issue would be great to have: == 3) Support onException for the transaction and default error handler, allowing you to trap exceptions and avoid rolling back. Kinda like the tryBlock() .. handle() 4) Consider renaming the handle() name to catchBlock() so its consistent with the tryBlock() name (CAMEL-1447) As this is an API change I would like to get it in 2.0. And finally we should have time to fix the community reports bugs and minor new features to add that we usually do on a daily basis. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
[jira] Resolved: (CAMEL-961) Reporting exceptions back to the jms requester in in-out exchange style
[ https://issues.apache.org/activemq/browse/CAMEL-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-961. --- Resolution: Fixed Fix Version/s: 2.0.0 In Camel 2.0 you can enable transferring exceptions over JMS with the *transferException* option. > Reporting exceptions back to the jms requester in in-out exchange style > --- > > Key: CAMEL-961 > URL: https://issues.apache.org/activemq/browse/CAMEL-961 > Project: Apache Camel > Issue Type: Improvement > Components: camel-jms >Affects Versions: 1.4.0 >Reporter: Markus Wolf >Assignee: Hadrian Zbarcea > Fix For: 2.0.0 > > Attachments: camel-test.tar.gz > > > We tried to setup a route where some exceptions where caught by the dead > letter queue for retry and some exceptions where reported back to the jms > message requester in an in-out exchange style request. > There are two problems with this. > First: The dead letter queue is an all or nothing handler. There is currently > no way to give some excludes to the handled exceptions. > Second: Exceptions are not serialized and returned by the jms listener on > reponse, but instead a camel runtime exception is logged and the jms request > thread gets a timeout. > In the attached example the IOException should be returned to the > jms:someQueue endpoint as answer to the request. All other exceptions should > be handled by the dead letter queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1046) Camel DSL
[ https://issues.apache.org/activemq/browse/CAMEL-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1046. Resolution: Won't Fix > Camel DSL > - > > Key: CAMEL-1046 > URL: https://issues.apache.org/activemq/browse/CAMEL-1046 > Project: Apache Camel > Issue Type: New Feature >Affects Versions: Future >Reporter: Vadim Chekan >Priority: Minor > Attachments: camel-dsl.patch, test.txt > > > Attached Camel native DSL. > The work in progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1507: --- Fix Version/s: 2.0.0 > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Fix For: 2.0.0 > > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1496) Using request parameters in the feed url will result in ResolveEndpointFailedException for Unknown parameters
[ https://issues.apache.org/activemq/browse/CAMEL-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1496: --- Fix Version/s: 2.0.0 > Using request parameters in the feed url will result in > ResolveEndpointFailedException for Unknown parameters > - > > Key: CAMEL-1496 > URL: https://issues.apache.org/activemq/browse/CAMEL-1496 > Project: Apache Camel > Issue Type: Bug > Components: camel-atom, camel-rss >Affects Versions: 2.0-M1 >Reporter: Jeroen Reijn > Fix For: 2.0.0 > > Attachments: CAMEL-1496.patch.txt > > > While configuring a route like: > > http://somehost/?feed=1234567"/> > > > camel throws an exception with: > Failed to resolve endpoint due to: > org.apache.camel.ResolveEndpointFailedException: There are 1 parameters that > couldn't be set on the endpoint -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1506) Recursively scan multipart nodes of an email for attachments - not just top level nodes
[ https://issues.apache.org/activemq/browse/CAMEL-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1506: --- Fix Version/s: 2.0.0 > Recursively scan multipart nodes of an email for attachments - not just top > level nodes > --- > > Key: CAMEL-1506 > URL: https://issues.apache.org/activemq/browse/CAMEL-1506 > Project: Apache Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.0.0 >Reporter: Ryan Gardner >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.0.0 > > Attachments: MailContentAttachmentScanning.patch > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The current code will only scan the top level of a multipart message. This > misses any attachments that are under another node. > All unit tests still run for me after applying this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1504) HTTP_URI and HTTP_PATH message headers not concatenated when sending messages to http endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1504: --- Priority: Minor (was: Major) Fix Version/s: 2.0.0 > HTTP_URI and HTTP_PATH message headers not concatenated when sending messages > to http endpoint > -- > > Key: CAMEL-1504 > URL: https://issues.apache.org/activemq/browse/CAMEL-1504 > Project: Apache Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 2.0-M1 >Reporter: Mathis Schwuchow >Priority: Minor > Fix For: 2.0.0 > > Attachments: Patch_Issue_CAMEL-1504_V01.patch, > Patch_Issue_CAMEL-1504_V02.patch > > > When a message is sent to an http endpoint, the path specified in the > HTTP_PATH header is ignored. > In the HttpProducer.createMethod() of the camel-http component, the URI is > taken from the HTTP_URI header or the endpoint, but the HTTP_PATH header is > not concatenated. > See also the discussion on the mailing list: > http://www.nabble.com/Setting-a-path-in-message-header-with-Camel-http-2.0M1-td22781504.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1059) StreamMessage not supported in camel-jms
[ https://issues.apache.org/activemq/browse/CAMEL-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1059: --- Priority: Minor (was: Major) Fix Version/s: (was: 2.0.0) 2.1.0 Summary: StreamMessage not supported in camel-jms (was: StreamMessage not porperly supported in camel-jms ) > StreamMessage not supported in camel-jms > - > > Key: CAMEL-1059 > URL: https://issues.apache.org/activemq/browse/CAMEL-1059 > Project: Apache Camel > Issue Type: Improvement > Components: camel-jms >Affects Versions: 1.5.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.1.0 > > > When Camel is mapping to/from javax.jmx.XXX to the Camel message body it does > not properly support the javax.jms.StreamMessage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1511) TransactionErrorHandler and DefaultErrorHandler - support onException
TransactionErrorHandler and DefaultErrorHandler - support onException - Key: CAMEL-1511 URL: https://issues.apache.org/activemq/browse/CAMEL-1511 Project: Apache Camel Issue Type: New Feature Components: camel-core, camel-spring Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0.0 The *onException* is a great feature and we should try to see if we can get it supported in the TransactionErrorHandler and DefaultErrorHandler as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1175) Scripting Language - Add support for context initializer can end users to easily add customize the context before evaluation
[ https://issues.apache.org/activemq/browse/CAMEL-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1175: --- Fix Version/s: (was: 2.0.0) 2.1.0 > Scripting Language - Add support for context initializer can end users to > easily add customize the context before evaluation > > > Key: CAMEL-1175 > URL: https://issues.apache.org/activemq/browse/CAMEL-1175 > Project: Apache Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.1.0 > > > See nabble: > http://www.nabble.com/Expression-Language-td20916213s22882.html > End users needing to doe custom code such as adding their own bindings to the > context. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-714) Change default DeadLetterChannel strategy in Camel
[ https://issues.apache.org/activemq/browse/CAMEL-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-714 started by Claus Ibsen. > Change default DeadLetterChannel strategy in Camel > -- > > Key: CAMEL-714 > URL: https://issues.apache.org/activemq/browse/CAMEL-714 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 1.3.0, 1.4.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0.0 > > > The current DLC strategy in Camel is to retry 6 times with 1 sec delay. If > still failed it will be moved to a log WARN. > This default behavior is not feasible for most end-users, in fact none. We > should have a better default strategy in Camel. > Also we should force end-users to setup a strategy from the start. > And we should improve this in the documentation so end-users is aware of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1242) Prevent camel-cometd component from consuming messages when no client has subscribed to channel
[ https://issues.apache.org/activemq/browse/CAMEL-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1242: --- Fix Version/s: (was: 2.0.0) 2.1.0 > Prevent camel-cometd component from consuming messages when no client has > subscribed to channel > --- > > Key: CAMEL-1242 > URL: https://issues.apache.org/activemq/browse/CAMEL-1242 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 2.0.0 > Environment: All >Reporter: Stephen Joyner >Priority: Minor > Fix For: 2.1.0 > > > The camel-cometd component will consume all messages sent to it whether it > has a client subscribed to its enpoint channel or not. It would be preferable > for the component not to consume messages until it has a subscribed client to > receive the messages. > As it is currently written, the component "eats" messages, and this doesn't > seem to be a desirable function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1005) should we have an annotation - maybe @Handler or something which can mark a method as being the default method invoked by the Bean Binding if no other Camel annotations ar
[
https://issues.apache.org/activemq/browse/CAMEL-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-1005:
---
Fix Version/s: (was: 2.0.0)
2.1.0
> should we have an annotation - maybe @Handler or something which can mark a
> method as being the default method invoked by the Bean Binding if no other
> Camel annotations are used to bind parameters
>
>
> Key: CAMEL-1005
> URL: https://issues.apache.org/activemq/browse/CAMEL-1005
> Project: Apache Camel
> Issue Type: Improvement
>Reporter: James Strachan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.1.0
>
>
> e.g.
> {code}
> public class Cheese {
> public void foo(String bar) {...}
> @Handler
> public void bar(String cheese) {...}
> {code}
> Then if we did
> {code}
> from("seda:foo").bean(Cheese.class);
> {code}
> it'd be obvious.
> I guess its pretty low priority as follks could always do
> {code}
> public class Cheese {
> public void foo(String bar) {...}
> public void bar(@Body String cheese) {...}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1311) when dependencies are missing, can we report to the user exactly what kinds of jars are typically required?
[ https://issues.apache.org/activemq/browse/CAMEL-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1311: --- Fix Version/s: (was: 2.0.0) 2.1.0 > when dependencies are missing, can we report to the user exactly what kinds > of jars are typically required? > --- > > Key: CAMEL-1311 > URL: https://issues.apache.org/activemq/browse/CAMEL-1311 > Project: Apache Camel > Issue Type: Improvement >Reporter: James Strachan >Assignee: Willem Jiang > Fix For: 2.1.0 > > > See this tweet ... > http://twitter.com/casron/statuses/1172707316 > not exactly sure how we can do it though :) I wonder if when we know there is > a class missing, we can deduce some groupId + artifact Id that is typically > missing, then we can report on the jars (and the dependencies) missing for > that group ID and artifact ID? e.g. if we know that (say) XStream jar is > missing, can we report the camel-xstream dependencies that are missing? > This typically occurs when we use the apache-camel uber-jar and then the > converters can't be registered due to the dependencies not being there. So > how about adding (say) camel-xstream knows that jars it requires and has some > kinda way (through Maven / OSGi tooling) to auto-generate a list of missing > jars? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1168) any missing EIP patterns?
[ https://issues.apache.org/activemq/browse/CAMEL-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1168: --- Fix Version/s: (was: 2.0.0) 2.1.0 > any missing EIP patterns? > - > > Key: CAMEL-1168 > URL: https://issues.apache.org/activemq/browse/CAMEL-1168 > Project: Apache Camel > Issue Type: Improvement >Reporter: James Strachan > Fix For: 2.1.0 > > > we could do with a review of the patterns in the index to see if we've missed > any... > comparing > http://cwiki.apache.org/CAMEL/enterprise-integration-patterns.html > to > http://www.enterpriseintegrationpatterns.com/toc.html > as I'm sure we could document some more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1222) DeadLetterChannel - Snapshots for processor and (bean invocations) when doing redelivery
[ https://issues.apache.org/activemq/browse/CAMEL-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1222. Resolution: Won't Fix > DeadLetterChannel - Snapshots for processor and (bean invocations) when doing > redelivery > > > Key: CAMEL-1222 > URL: https://issues.apache.org/activemq/browse/CAMEL-1222 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen > Fix For: 2.0.0 > > > This ticket is created to not forget about this and get a discussion going. > When Camel handles redeliver using DLC for processors > (org.apache.camel.Processor) and bean invocations (only in the special case > where it operates directly on the Exchange = Exchange as parameter), then any > changes that was done before is also present at the next redelivery attempt. > So for instance changing the body value, or adding a header etc. will cause > these changes on the Exchange. > We should document this - especially for org.apache.camel.Processor. bean > component end users is encouraged to use bean binding, that hasn't this issue > (except for Headers, Properties). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-825) async endpoints like SEDA and VM do not work with InOut and Spring Remoting - as the caller does not wait for the exchange to be completed
[ https://issues.apache.org/activemq/browse/CAMEL-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-825: -- Fix Version/s: (was: 2.0.0) 2.1.0 > async endpoints like SEDA and VM do not work with InOut and Spring Remoting - > as the caller does not wait for the exchange to be completed > -- > > Key: CAMEL-825 > URL: https://issues.apache.org/activemq/browse/CAMEL-825 > Project: Apache Camel > Issue Type: Bug >Reporter: James Strachan > Fix For: 2.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1382) should we zap the Route class?
[ https://issues.apache.org/activemq/browse/CAMEL-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1382. Resolution: Won't Fix > should we zap the Route class? > --- > > Key: CAMEL-1382 > URL: https://issues.apache.org/activemq/browse/CAMEL-1382 > Project: Apache Camel > Issue Type: Improvement >Reporter: James Strachan > Fix For: 2.0.0 > > > it seems kinda confusing and am not sure if its got real value? > I'm just about to add a class I'm calling RouteService which is-a Service > representing a runtime image of a RouteType which can be started/stopped. Am > wondering if we zap Route - or if we just make Route be the RouteService? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-974) DataSetSedaTest intermittent test failure
[
https://issues.apache.org/activemq/browse/CAMEL-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-974:
--
Priority: Minor (was: Major)
Fix Version/s: (was: 2.0.0)
Future
> DataSetSedaTest intermittent test failure
> -
>
> Key: CAMEL-974
> URL: https://issues.apache.org/activemq/browse/CAMEL-974
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.4.0
>Reporter: Hadrian Zbarcea
>Priority: Minor
> Fix For: Future
>
>
> I get this kind of failures in the DataSetSedaTest now and then:
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.731 sec <<<
> FAILURE!
> test(org.apache.camel.component.dataset.DataSetSedaTest) Time elapsed: 4.49
> sec <<< ERROR!
> java.lang.AssertionError: dataset:foo Failed due to caught exception:
> java.lang.AssertionError: Header: camelDataSetIndex does not match. Expected:
> 33 but was: 32 on Exchange[Message: world!] with headers:
> {camelDataSetIndex=32}
> at
> org.apache.camel.component.mock.MockEndpoint.fail(MockEndpoint.java:712)
> at
> org.apache.camel.component.mock.MockEndpoint.assertIsSatisfied(MockEndpoint.java:255)
> at
> org.apache.camel.component.mock.MockEndpoint.assertIsSatisfied(MockEndpoint.java:214)
> at
> org.apache.camel.component.mock.MockEndpoint.assertIsSatisfied(MockEndpoint.java:141)
> at
> org.apache.camel.ContextTestSupport.assertMockEndpointsSatisfied(ContextTestSupport.java:283)
> at
> org.apache.camel.component.dataset.DataSetSedaTest.test(DataSetSedaTest.java:35)
> I am not sure yet if it's just a test issue (quite probable) or there's a
> more serious underlying issue. If anybody else experienced this please add a
> comment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1383) provide a text search - or a way to search by some expression for messages on an endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1383: --- Fix Version/s: (was: 2.0.0) 2.1.0 > provide a text search - or a way to search by some expression for messages on > an endpoint > - > > Key: CAMEL-1383 > URL: https://issues.apache.org/activemq/browse/CAMEL-1383 > Project: Apache Camel > Issue Type: Sub-task > Components: camel-web >Reporter: James Strachan > Fix For: 2.1.0 > > > using a text search to find a message (using headers/body) or using xpath/EL > or whatever -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-316) Merge Fault and Exception semantics
[ https://issues.apache.org/activemq/browse/CAMEL-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-316. --- Resolution: Won't Fix We never got this addressed in Camel 2.0 timeframe. If really needed we can address or look at it again in Camel 3.0 or later. > Merge Fault and Exception semantics > --- > > Key: CAMEL-316 > URL: https://issues.apache.org/activemq/browse/CAMEL-316 > Project: Apache Camel > Issue Type: Improvement >Reporter: Hadrian Zbarcea >Assignee: Hadrian Zbarcea > Fix For: 2.0.0 > > > The fact that there are output/fault/exception could be confusing and clutter > the dsl, especially for components where there is no distinction between > fault and exception. We should merge the two and simplify the model. > See nabble thread: > http://www.nabble.com/in-out-fault-messages-discussion-to14170013s22882.html#a14170013 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1268) use the ExpressionClause on the MockEndpoint to enhance the DSL for creating expression based expectations
[
https://issues.apache.org/activemq/browse/CAMEL-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-1268:
---
Fix Version/s: (was: 2.0.0)
Future
Assignee: (was: James Strachan)
> use the ExpressionClause on the MockEndpoint to enhance the DSL for
> creating expression based expectations
> -
>
> Key: CAMEL-1268
> URL: https://issues.apache.org/activemq/browse/CAMEL-1268
> Project: Apache Camel
> Issue Type: Improvement
>Reporter: James Strachan
> Fix For: Future
>
>
> e.g.
> {code}
> mockEndpoint.expectsAscending().header("foo");
> mockEndpoint.expectsUnique().xpath("/foo/bar");
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-603) Embedded ServiceMix for JBI integration example
[ https://issues.apache.org/activemq/browse/CAMEL-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-603. --- Resolution: Won't Fix > Embedded ServiceMix for JBI integration example > --- > > Key: CAMEL-603 > URL: https://issues.apache.org/activemq/browse/CAMEL-603 > Project: Apache Camel > Issue Type: New Feature > Components: camel-jbi >Reporter: Claus Ibsen > Fix For: 2.0.0 > > > We should be able to run smx as a war in 'embedded mode' with whatever camel > routes we need > We should create a little example of how to mix and match servicemix, jbi > components and camel in a war -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50974#action_50974
]
Marat Bedretdinov commented on CAMEL-1509:
--
The logic in the ServiceSupport is somewhat interesting.
The state goes from
Thread1 -> ServiceSuppoet.start() -> starting = false and stared = false ->
starting = true and started = true -> starting = false and started = true
Now why is started = true is set before starting = true? started is in pass
tense, so to me this is clearly that started = true should have been set
*after* starting went from true to false
Moreover there is also a race.
Look at the ServiceSupport.stop() method its state goes like this:
Thread 1-> ServiceSupport.stop() -> started = true and stopping = false ->
stopping = true -> stopped = true and started = false and stopping = false
Now lets look at this scenario, 2 threads invoking onto the same CamelContext
Thread1 ->ServiceSupport.start() -> starting = false and stared = false ->
starting = true and started = true -> @
Thread2-> ServiceSupport.stop() -> started = true and stopping = false ->
stopping = true -> @
@ is the point in time when we will have a concurrent start and stop logic
executed on the same context and I'd imagine this can't be good ;)
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50973#action_50973
]
Alexander Kleymenov commented on CAMEL-1509:
{quote}
if the camel context finishe the start process,
the staring flag wil be set to false again.
So , if the camel context's start method doesn't be called ,
isStarting != ! isStarted.
{quote}
:) of course, I mean the timeline between ctx.start() and ctx.stop() (outside
of which both methods should return false).
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50972#action_50972
]
Alexander Kleymenov commented on CAMEL-1509:
BTW,
Timer thread introduced in https://issues.apache.org/activemq/browse/CAMEL-1129
prevents the program from being finished.
That's because timer is being created as not a daemon. I tried
DeadLetterChannel.java with line 52 fixed as this:
{code}
private static Timer timer = new Timer(true); // create timer with
associated thread running as daemon
{code}
and it works fine.
Should it be a separate issue, or this info is enough for issue to be fixed?
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move the Camel features into Camel
+1 On Thu, Apr 2, 2009 at 2:05 AM, Freeman Fang wrote: > +1 > Freeman > Gert Vanthienen wrote: >> >> L.S., >> >> Currently, a features descriptor for Camel is being generated in the >> ServiceMix 4 features projects. This descriptor basically is an XML >> file that allows you to install any Camel component on ServiceMix >> Kernel in a single command. The information in the descriptor will be >> used to determine which others OSGi bundles are required. >> >> We now released ServiceMix 4.0.0 with a features descriptor for Camel >> 1.6.0, but on the Camel project itself we're now working on >> 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move >> the generation process of the features descriptor into the Camel >> project itself, so every release of Camel can come with its own >> features descriptor. It will also make it easier for people to test a >> SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up >> their own descriptor first. >> >> If we look at the codebase, it will basically mean that we would have >> to move the pom.xml and properties file that's currently at >> >> https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ >> to e.g. a /platform/servicemix-kernel directory in the Camel project. >> >> Any thoughs? >> >> Gert Vanthienen >> >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50971#action_50971
]
Willem Jiang commented on CAMEL-1509:
-
Here your are the starting codes
{code}
public void start() throws Exception {
if (started.compareAndSet(false, true)) {
starting.set(true);
try {
if (childServices != null) {
ServiceHelper.startServices(childServices);
}
doStart();
} finally {
notStarting();
}
}
}
{code}
started and starting flag are false by default.
if the camel context finishe the start process,
the staring flag wil be set to false again.
So , if the camel context's start method doesn't be called ,
isStarting != ! isStarted.
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50970#action_50970
]
Alexander Kleymenov commented on CAMEL-1509:
Willem, thank you for taking this!
Should not this implication be always true:
{code}
isStarting => !isStarted
{code}
?
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50969#action_50969
]
Willem Jiang commented on CAMEL-1509:
-
Hi
Can you add a check for the camelCtx.isStarted() for waiting for camelCtx
starting?
{code}
camelCtx = new DefaultCamelContext()
route = new MyRoute()
camelCtx.addRoutes(route);
Thread.start {
camelCtx.start();
}
while (!camelCtx.isStarted() || camelCtx.isStarting()) {
Thread.sleep(1000)
}
{code}
I just checked the code. If the camelCtx.start() code is running later than the
camelCtx.isStarting() check,
the test will failed since the route rule is not started yet.
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-1509:
---
Assignee: Willem Jiang
> DefaultCamelContext.isStarting returns incorrect status
> ---
>
> Key: CAMEL-1509
> URL: https://issues.apache.org/activemq/browse/CAMEL-1509
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Alexander Kleymenov
>Assignee: Willem Jiang
>
> DefaultCamelContext.isStarting returns true while it actually not started.
> So the following groovy test case fails:
> {code:title=test.groovy}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.language.groovy.GroovyRouteBuilder;
> class Foo {
> def name
> def data
> void run(data) {
> println "[${name}] got ${data}"
> this.data = data
> }
> }
> public class MyRoute extends GroovyRouteBuilder {
> def bean = new Foo(name: "bean")
> protected void configure() {
> from("direct:start").bean(bean, "run")
> }
> }
> camelCtx = new DefaultCamelContext()
> route = new MyRoute()
> camelCtx.addRoutes(route);
> Thread.start {
> camelCtx.start();
> }
> while (camelCtx.isStarting()) {
> Thread.sleep(1000)
> }
> camelCtx.createProducerTemplate().sendBody("direct:start", "data")
> if (!route.bean.data) {
> println "FAILED: no data has been received!"
> } else {
> println "PASSED"
> }
> camelCtx.stop();
> {code}
> Note, after moving of
> {code}
> camelCtx.addRoutes(route)
> {code}
> after
> {code}
> Thread.start {
> camelCtx.start();
> }
> {code}
> the test passes.
> Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects
[
https://issues.apache.org/activemq/browse/CAMEL-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50968#action_50968
]
Christopher Hunt commented on CAMEL-1510:
-
Just wondering... the batch processor's collection should always be a
thread-safe type of collection. Is this the case in practice? If the collection
is not thread safe then the batch sender run method will contend with the
processor's isOutBatchCompleted(), doStop() and getCollection() methods.
> BatchProcessor interrupt has side effects
> -
>
> Key: CAMEL-1510
> URL: https://issues.apache.org/activemq/browse/CAMEL-1510
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0
> Environment: Mac OS X
>Reporter: Christopher Hunt
>Priority: Critical
>
> I have noticed that the BatchProcessor class uses the Thread class interrupt
> method to wake the run loop from sleeping within the enqueueExchange method.
> The unfortunate side effect of this is that if the run loop is in the middle
> of processing exchanges, and the processing involves something slow like
> establishing a JMS connection over SSL or queuing to an asynchronous
> processor, then the processing can become interrupted. The consequence of
> this side effect is that the batch sender thread rarely gets the opportunity
> to complete properly and exceptions regarding the interrupt are thrown.
> This all became apparent during some performance testing that resulted in
> continuously adding exchanges to the aggregator, the threshold becoming
> reached, and then trying to enqueue the aggregated result to a JMS queue.
> If my analysis of the BatchProcessor is correct then I would recommend finer
> grained concurrency controls being used instead of relying upon interrupting
> a thread. Perhaps something like the following (untested) re-write of the
> sender:
> {code}
> private class BatchSender extends Thread {
> private Queue queue;
> private boolean exchangeQueued = false;
> private Lock queueMutex = new ReentrantLock();
> private Condition queueCondition = queueMutex.newCondition();
> public BatchSender() {
> super("Batch Sender");
> this.queue = new LinkedList();
> }
> public void cancel() {
> interrupt();
> }
> private void drainQueueTo(Collection collection, int
> batchSize) {
> for (int i = 0; i < batchSize; ++i) {
> Exchange e = queue.poll();
> if (e != null) {
> collection.add(e);
> } else {
> break;
> }
> }
> }
> public void enqueueExchange(Exchange exchange) {
> queueMutex.lock();
> try {
> queue.add(exchange);
> exchangeQueued = true;
> } finally {
> queueMutex.unlock();
> }
> }
> @Override
> public void run() {
> queueMutex.lock();
> try {
> do {
> try {
> if (!exchangeQueued) {
> queueCondition.await(batchTimeout,
> TimeUnit.MILLISECONDS);
> if (!exchangeQueued) {
> drainQueueTo(collection, batchSize);
> }
> }
> if (exchangeQueued) {
> exchangeQueued = false;
> queueMutex.unlock();
> try {
> while (isInBatchCompleted(queue.size())) {
> queueMutex.lock();
> try {
> drainQueueTo(collection, batchSize);
> } finally {
> queueMutex.unlock();
> }
> }
> if (!isOutBatchCompleted()) {
> continue;
> }
> } finally {
> queueMutex.lock();
> }
> }
> queueMutex.unlock();
> try {
> try {
> sendExchanges();
> } catch (Exception e) {
> getExceptionHandler().handleException(e);
> }
> }
[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects
[
https://issues.apache.org/activemq/browse/CAMEL-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt updated CAMEL-1510:
Description:
I have noticed that the BatchProcessor class uses the Thread class interrupt
method to wake the run loop from sleeping within the enqueueExchange method.
The unfortunate side effect of this is that if the run loop is in the middle of
processing exchanges, and the processing involves something slow like
establishing a JMS connection over SSL or queuing to an asynchronous processor,
then the processing can become interrupted. The consequence of this side effect
is that the batch sender thread rarely gets the opportunity to complete
properly and exceptions regarding the interrupt are thrown.
This all became apparent during some performance testing that resulted in
continuously adding exchanges to the aggregator, the threshold becoming
reached, and then trying to enqueue the aggregated result to a JMS queue.
If my analysis of the BatchProcessor is correct then I would recommend finer
grained concurrency controls being used instead of relying upon interrupting a
thread. Perhaps something like the following (untested) re-write of the sender:
{code}
private class BatchSender extends Thread {
private Queue queue;
private boolean exchangeQueued = false;
private Lock queueMutex = new ReentrantLock();
private Condition queueCondition = queueMutex.newCondition();
public BatchSender() {
super("Batch Sender");
this.queue = new LinkedList();
}
public void cancel() {
interrupt();
}
private void drainQueueTo(Collection collection, int
batchSize) {
for (int i = 0; i < batchSize; ++i) {
Exchange e = queue.poll();
if (e != null) {
collection.add(e);
} else {
break;
}
}
}
public void enqueueExchange(Exchange exchange) {
queueMutex.lock();
try {
queue.add(exchange);
exchangeQueued = true;
} finally {
queueMutex.unlock();
}
}
@Override
public void run() {
queueMutex.lock();
try {
do {
try {
if (!exchangeQueued) {
queueCondition.await(batchTimeout,
TimeUnit.MILLISECONDS);
if (!exchangeQueued) {
drainQueueTo(collection, batchSize);
}
}
if (exchangeQueued) {
exchangeQueued = false;
queueMutex.unlock();
try {
while (isInBatchCompleted(queue.size())) {
queueMutex.lock();
try {
drainQueueTo(collection, batchSize);
} finally {
queueMutex.unlock();
}
}
if (!isOutBatchCompleted()) {
continue;
}
} finally {
queueMutex.lock();
}
}
queueMutex.unlock();
try {
try {
sendExchanges();
} catch (Exception e) {
getExceptionHandler().handleException(e);
}
} finally {
queueMutex.lock();
}
} catch (InterruptedException e) {
break;
}
} while (true);
} finally {
queueMutex.unlock();
}
}
private void sendExchanges() throws Exception {
Iterator iter = collection.iterator();
while (iter.hasNext()) {
Exchange exchange = iter.next();
iter.remove();
processExchange(exchange);
}
}
}
{code}
I have replaced the concurrent queue with a regular linked list and mutexed its
access. In addition any queuing of exchanges is noted. This should result in
less locking.
The main change though is that queuing an exchange does not interrupt the batch
sender's current activity.
I hope that this sample is usefu
Re: BatchProcessor interrupt side effects
Now raised as: https://issues.apache.org/activemq/browse/CAMEL-1510 -- View this message in context: http://www.nabble.com/BatchProcessor-interrupt-side-effects-tp22819960p22836192.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com.
[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects
[
https://issues.apache.org/activemq/browse/CAMEL-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt updated CAMEL-1510:
Description:
I have noticed that the BatchProcessor class uses the Thread class interrupt
method to wake the run loop from sleeping within the enqueueExchange method.
The unfortunate side effect of this is that if the run loop is in the middle of
processing exchanges, and the processing involves something slow like
establishing a JMS connection over SSL or queuing to an asynchronous processor,
then the processing can become interrupted. The consequence of this side effect
is that the batch sender thread rarely gets the opportunity to complete
properly and exceptions regarding the interrupt are thrown.
This all became apparent during some performance testing that resulted in
continuously adding exchanges to the aggregator, the threshold becoming
reached, and then trying to enqueue the aggregated result to a JMS queue.
If my analysis of the BatchProcessor is correct then I would recommend finer
grained concurrency controls being used instead of relying upon interrupting a
thread. Perhaps something like the following (untested) re-write of the sender:
{code}
private class BatchSender extends Thread {
private Queue queue;
private boolean exchangeQueued = false;
private Lock queueMutex = new ReentrantLock();
private Condition queueCondition = queueMutex.newCondition();
public BatchSender() {
super("Batch Sender");
this.queue = new LinkedList();
}
public void cancel() {
interrupt();
}
private void drainQueueTo(Collection collection, int
batchSize) {
collection.clear();
for (int i = 0; i < batchSize; ++i) {
Exchange e = queue.poll();
if (e != null) {
collection.add(e);
} else {
break;
}
}
}
public void enqueueExchange(Exchange exchange) {
queueMutex.lock();
try {
queue.add(exchange);
exchangeQueued = true;
} finally {
queueMutex.unlock();
}
}
@Override
public void run() {
queueMutex.lock();
try {
do {
try {
if (!exchangeQueued) {
queueCondition.await(batchTimeout,
TimeUnit.MILLISECONDS);
if (!exchangeQueued) {
drainQueueTo(collection, batchSize);
}
}
if (exchangeQueued) {
exchangeQueued = false;
queueMutex.unlock();
try {
while (isInBatchCompleted(queue.size())) {
queueMutex.lock();
try {
drainQueueTo(collection, batchSize);
} finally {
queueMutex.unlock();
}
}
if (!isOutBatchCompleted()) {
continue;
}
} finally {
queueMutex.lock();
}
}
queueMutex.unlock();
try {
try {
sendExchanges();
} catch (Exception e) {
getExceptionHandler().handleException(e);
}
} finally {
queueMutex.lock();
}
} catch (InterruptedException e) {
break;
}
} while (true);
} finally {
queueMutex.unlock();
}
}
private void sendExchanges() throws Exception {
Iterator iter = collection.iterator();
while (iter.hasNext()) {
Exchange exchange = iter.next();
iter.remove();
processExchange(exchange);
}
}
}
{code}
I have replaced the concurrent queue with a regular linked list and mutexed its
access. In addition any queuing of exchanges is noted. This should result in
less locking.
The main change though is that queuing an exchange does not interrupt the batch
sender's current activity.
[jira] Created: (CAMEL-1510) BatchProcessor interrupt has side effects
BatchProcessor interrupt has side effects
-
Key: CAMEL-1510
URL: https://issues.apache.org/activemq/browse/CAMEL-1510
Project: Apache Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 1.6.0
Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical
I have noticed that the BatchProcessor class uses the Thread class interrupt
method to wake the run loop from sleeping within the enqueueExchange method.
The unfortunate side effect of this is that if the run loop is in the middle of
processing exchanges, and the processing involves something slow like
establishing a JMS connection over SSL or queuing to an asynchronous processor,
then the processing can become interrupted. The consequence of this side effect
is that the batch sender thread rarely gets the opportunity to complete
properly and exceptions regarding the interrupt are thrown.
This all became apparent during some performance testing that resulted in
continuously adding exchanges to the aggregator, the threshold becoming
reached, and then trying to enqueue the aggregated result to a JMS queue.
If my analysis of the BatchProcessor is correct then I would recommend finer
grained concurrency controls being used instead of relying upon interrupting a
thread. Perhaps something like the following (untested) re-write of the sender:
{code}
private class BatchSender extends Thread {
private Queue queue;
private boolean exchangeQueued = false;
private Lock queueMutex = new ReentrantLock();
private Condition queueCondition = queueMutex.newCondition();
public BatchSender() {
super("Batch Sender");
this.queue = new LinkedList();
}
public void cancel() {
interrupt();
}
private void drainQueueTo(Collection collection, int
batchSize) {
collection.clear();
for (int i = 0; i < batchSize; ++i) {
Exchange e = queue.poll();
if (e != null) {
collection.add(e);
} else {
break;
}
}
}
public void enqueueExchange(Exchange exchange) {
queueMutex.lock();
try {
queue.add(exchange);
exchangeQueued = true;
} finally {
queueMutex.unlock();
}
}
@Override
public void run() {
queueMutex.lock();
try {
do {
try {
if (!exchangeQueued) {
queueCondition.await(batchTimeout,
TimeUnit.MILLISECONDS);
if (!exchangeQueued) {
drainQueueTo(collection, batchSize);
}
}
if (exchangeQueued) {
exchangeQueued = false;
queueMutex.unlock();
try {
while
(isInBatchCompleted(queue.size())) {
queueMutex.lock();
try {
drainQueueTo(collection, batchSize);
}
finally {
queueMutex.unlock();
}
}
if
(!isOutBatchCompleted()) {
continue;
}
Re: [DISCUSS] Move the Camel features into Camel
+1 Freeman Gert Vanthienen wrote: L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: BatchProcessor interrupt side effects
Hi Gert, Thanks for your email. Given your acknowledgement of the issue I shall raise a JIRA and provide a suggested patch. I'll look at the latch idea too. Kind regards, Christopher -- View this message in context: http://www.nabble.com/BatchProcessor-interrupt-side-effects-tp22819960p22834774.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com.
Re: [DISCUSS] Move the Camel features into Camel
+1 This is a great idea. -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Wed, Apr 1, 2009 at 11:50 AM, Gert Vanthienen wrote: > L.S., > > Currently, a features descriptor for Camel is being generated in the > ServiceMix 4 features projects. This descriptor basically is an XML > file that allows you to install any Camel component on ServiceMix > Kernel in a single command. The information in the descriptor will be > used to determine which others OSGi bundles are required. > > We now released ServiceMix 4.0.0 with a features descriptor for Camel > 1.6.0, but on the Camel project itself we're now working on > 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move > the generation process of the features descriptor into the Camel > project itself, so every release of Camel can come with its own > features descriptor. It will also make it easier for people to test a > SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up > their own descriptor first. > > If we look at the codebase, it will basically mean that we would have > to move the pom.xml and properties file that's currently at > > https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ > to e.g. a /platform/servicemix-kernel directory in the Camel project. > > Any thoughs? > > Gert Vanthienen > > Open Source SOA: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ >
Re: [DISCUSS] Move the Camel features into Camel
+1 (forgot to reply all :) 2009/4/1 Gert Vanthienen : > L.S., > > Currently, a features descriptor for Camel is being generated in the > ServiceMix 4 features projects. This descriptor basically is an XML > file that allows you to install any Camel component on ServiceMix > Kernel in a single command. The information in the descriptor will be > used to determine which others OSGi bundles are required. > > We now released ServiceMix 4.0.0 with a features descriptor for Camel > 1.6.0, but on the Camel project itself we're now working on > 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move > the generation process of the features descriptor into the Camel > project itself, so every release of Camel can come with its own > features descriptor. It will also make it easier for people to test a > SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up > their own descriptor first. > > If we look at the codebase, it will basically mean that we would have > to move the pom.xml and properties file that's currently at > https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ > to e.g. a /platform/servicemix-kernel directory in the Camel project. > > Any thoughs? > > Gert Vanthienen > > Open Source SOA: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
[jira] Commented: (CAMEL-1450) Add custom endpoints to camel jmx mbean server
[ https://issues.apache.org/activemq/browse/CAMEL-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50963#action_50963 ] Stephen Mullins commented on CAMEL-1450: W00t, thank you! Let me know if there's anything else I can help with :) > Add custom endpoints to camel jmx mbean server > -- > > Key: CAMEL-1450 > URL: https://issues.apache.org/activemq/browse/CAMEL-1450 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 1.6.0 >Reporter: Stephen Mullins >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.0.0 > > Attachments: CAMEL-1450.patch, CAMEL-1450.v2.patch > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, when adding endpoints to the mbean server, all endpoints are > wrapped with ManagedEndpoint. This does not allow for custom attributes or > operations to be exposed on the custom endpoints. I would like the > InstrumentationLifecycleStrategy.onEndpointAdd() method to first check if the > endpoint is annotated with ManagedResource, if it is then register that > endpoint; if the endpoint is not annotated with ManagedResource then wrap it > with ManagedEndpoint and register. This way all endpoints still get > registered but any custom attributes or operations will be exposed through > jmx. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Move the Camel features into Camel
L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[jira] Created: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
DefaultCamelContext.isStarting returns incorrect status
---
Key: CAMEL-1509
URL: https://issues.apache.org/activemq/browse/CAMEL-1509
Project: Apache Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.0-M1, 1.6.0
Reporter: Alexander Kleymenov
DefaultCamelContext.isStarting returns true while it actually not started.
So the following groovy test case fails:
{code:title=test.groovy}
import org.apache.camel.impl.DefaultCamelContext;
import org.apache.camel.language.groovy.GroovyRouteBuilder;
class Foo {
def name
def data
void run(data) {
println "[${name}] got ${data}"
this.data = data
}
}
public class MyRoute extends GroovyRouteBuilder {
def bean = new Foo(name: "bean")
protected void configure() {
from("direct:start").bean(bean, "run")
}
}
camelCtx = new DefaultCamelContext()
route = new MyRoute()
camelCtx.addRoutes(route);
Thread.start {
camelCtx.start();
}
while (camelCtx.isStarting()) {
Thread.sleep(1000)
}
camelCtx.createProducerTemplate().sendBody("direct:start", "data")
if (!route.bean.data) {
println "FAILED: no data has been received!"
} else {
println "PASSED"
}
camelCtx.stop();
{code}
Note, after moving of
{code}
camelCtx.addRoutes(route)
{code}
after
{code}
Thread.start {
camelCtx.start();
}
{code}
the test passes.
Also the program does not finish after camelCtx.stop();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1450) Add custom endpoints to camel jmx mbean server
[ https://issues.apache.org/activemq/browse/CAMEL-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1450. Resolution: Fixed Thanks Stephen. I have committed the patch trunk: 760956. > Add custom endpoints to camel jmx mbean server > -- > > Key: CAMEL-1450 > URL: https://issues.apache.org/activemq/browse/CAMEL-1450 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 1.6.0 >Reporter: Stephen Mullins >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.0.0 > > Attachments: CAMEL-1450.patch, CAMEL-1450.v2.patch > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, when adding endpoints to the mbean server, all endpoints are > wrapped with ManagedEndpoint. This does not allow for custom attributes or > operations to be exposed on the custom endpoints. I would like the > InstrumentationLifecycleStrategy.onEndpointAdd() method to first check if the > endpoint is annotated with ManagedResource, if it is then register that > endpoint; if the endpoint is not annotated with ManagedResource then wrap it > with ManagedEndpoint and register. This way all endpoints still get > registered but any custom attributes or operations will be exposed through > jmx. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1450) Add custom endpoints to camel jmx mbean server
[ https://issues.apache.org/activemq/browse/CAMEL-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50961#action_50961 ] Claus Ibsen commented on CAMEL-1450: TODO: Update the CXF wiki page > Add custom endpoints to camel jmx mbean server > -- > > Key: CAMEL-1450 > URL: https://issues.apache.org/activemq/browse/CAMEL-1450 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 1.6.0 >Reporter: Stephen Mullins >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.0.0 > > Attachments: CAMEL-1450.patch, CAMEL-1450.v2.patch > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, when adding endpoints to the mbean server, all endpoints are > wrapped with ManagedEndpoint. This does not allow for custom attributes or > operations to be exposed on the custom endpoints. I would like the > InstrumentationLifecycleStrategy.onEndpointAdd() method to first check if the > endpoint is annotated with ManagedResource, if it is then register that > endpoint; if the endpoint is not annotated with ManagedResource then wrap it > with ManagedEndpoint and register. This way all endpoints still get > registered but any custom attributes or operations will be exposed through > jmx. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1504) HTTP_URI and HTTP_PATH message headers not concatenated when sending messages to http endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathis Schwuchow updated CAMEL-1504: Attachment: Patch_Issue_CAMEL-1504_V02.patch Added a check to ensure that there is exactly one "/" between URI and Path. A unit test extending the HttpGetTest is also included in the patch. > HTTP_URI and HTTP_PATH message headers not concatenated when sending messages > to http endpoint > -- > > Key: CAMEL-1504 > URL: https://issues.apache.org/activemq/browse/CAMEL-1504 > Project: Apache Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 2.0-M1 >Reporter: Mathis Schwuchow > Attachments: Patch_Issue_CAMEL-1504_V01.patch, > Patch_Issue_CAMEL-1504_V02.patch > > > When a message is sent to an http endpoint, the path specified in the > HTTP_PATH header is ignored. > In the HttpProducer.createMethod() of the camel-http component, the URI is > taken from the HTTP_URI header or the endpoint, but the HTTP_PATH header is > not concatenated. > See also the discussion on the mailing list: > http://www.nabble.com/Setting-a-path-in-message-header-with-Camel-http-2.0M1-td22781504.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Gardner updated CAMEL-1507: Attachment: camel-mail-test2.zip This contains a very simple maven project that has a main method that will send out an email. It's definitely NOT intended for inclusion as-is (but I'll check the box since you can include anything in it if you really WANT to) I just modified the default archetype and built a simple attachment processor that will attach the logo.gif to the message and send out the email. If you want to use this, it might save you the 5 minutes it would take you to do something similar to test how this works with sending out actual emails to test it. (It will work with gmail accounts that allow SMTP - just modify the YOURNAMEHERE and YOURPASSWORDHERE appropriately... I almost submitted it with my name and password in plaintext - which would have been rather dumb :) ) > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Attachments: camel-mail-test2.zip, mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1506) Recursively scan multipart nodes of an email for attachments - not just top level nodes
[
https://issues.apache.org/activemq/browse/CAMEL-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50955#action_50955
]
Claus Ibsen commented on CAMEL-1506:
Willem
This header
public static final String DEFAULT_ALTERNATE_BODY_HEADER = "mail_alternateBody";
Should be in MailConstants.java and it should follow the Camel 2.0 convention:
eg like {{CamelMailAlternativeBody}}
> Recursively scan multipart nodes of an email for attachments - not just top
> level nodes
> ---
>
> Key: CAMEL-1506
> URL: https://issues.apache.org/activemq/browse/CAMEL-1506
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.0.0
>Reporter: Ryan Gardner
>Assignee: Willem Jiang
>Priority: Minor
> Attachments: MailContentAttachmentScanning.patch
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> The current code will only scan the top level of a multipart message. This
> misses any attachments that are under another node.
> All unit tests still run for me after applying this patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1450) Add custom endpoints to camel jmx mbean server
[ https://issues.apache.org/activemq/browse/CAMEL-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-1450: -- Assignee: Claus Ibsen (was: Hadrian Zbarcea) > Add custom endpoints to camel jmx mbean server > -- > > Key: CAMEL-1450 > URL: https://issues.apache.org/activemq/browse/CAMEL-1450 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 1.6.0 >Reporter: Stephen Mullins >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.0.0 > > Attachments: CAMEL-1450.patch, CAMEL-1450.v2.patch > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, when adding endpoints to the mbean server, all endpoints are > wrapped with ManagedEndpoint. This does not allow for custom attributes or > operations to be exposed on the custom endpoints. I would like the > InstrumentationLifecycleStrategy.onEndpointAdd() method to first check if the > endpoint is annotated with ManagedResource, if it is then register that > endpoint; if the endpoint is not annotated with ManagedResource then wrap it > with ManagedEndpoint and register. This way all endpoints still get > registered but any custom attributes or operations will be exposed through > jmx. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1506) Recursively scan multipart nodes of an email for attachments - not just top level nodes
[ https://issues.apache.org/activemq/browse/CAMEL-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50952#action_50952 ] Willem Jiang commented on CAMEL-1506: - Sure, I will. > Recursively scan multipart nodes of an email for attachments - not just top > level nodes > --- > > Key: CAMEL-1506 > URL: https://issues.apache.org/activemq/browse/CAMEL-1506 > Project: Apache Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.0.0 >Reporter: Ryan Gardner >Assignee: Willem Jiang >Priority: Minor > Attachments: MailContentAttachmentScanning.patch > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The current code will only scan the top level of a multipart message. This > misses any attachments that are under another node. > All unit tests still run for me after applying this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1506) Recursively scan multipart nodes of an email for attachments - not just top level nodes
[ https://issues.apache.org/activemq/browse/CAMEL-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50951#action_50951 ] Claus Ibsen commented on CAMEL-1506: Willem when you get this fixed in Camel you should ping Lars from the SMX team as the Mail component in SMX was the base we used for the Camel one as well. So they have parts of code that is similar. So this bug could also exists in SMX. > Recursively scan multipart nodes of an email for attachments - not just top > level nodes > --- > > Key: CAMEL-1506 > URL: https://issues.apache.org/activemq/browse/CAMEL-1506 > Project: Apache Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.0.0 >Reporter: Ryan Gardner >Assignee: Willem Jiang >Priority: Minor > Attachments: MailContentAttachmentScanning.patch > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The current code will only scan the top level of a multipart message. This > misses any attachments that are under another node. > All unit tests still run for me after applying this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1503) javax.xml.transform.Source and StreamSource wrapped should be easier to route with JMS
[ https://issues.apache.org/activemq/browse/CAMEL-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1503. Resolution: Fixed Introduced StreamCache being able to write to an output stream and thus used in a type converter to convert from StreamCache to Serializable. This allows us to send Streams to JMS or MINA that will be serialized, and now they can be serialized and thus work out of the box. Before end users needed to convert to etc. String before sending to a JMS queue with Camel. Trunk: 760833, 760886 Thanks to gert and willem for help and inspiration > javax.xml.transform.Source and StreamSource wrapped should be easier to route > with JMS > -- > > Key: CAMEL-1503 > URL: https://issues.apache.org/activemq/browse/CAMEL-1503 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core, camel-jms >Affects Versions: 1.6.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0.0 > > > See SM-1826 > What end users need to do is to use .convertBodyTo(String.class) before > sending to a JMS queue with Camel when the payload is XML based, eg the > javax.xml.transform.Source class that can be wrapped in a StreamCache as well. > It should be able to route out of the box by converting to byte[] in the JMS > producer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1508) TypeConverter - Can find Object type converter even though there is a more specialized converter to use
[ https://issues.apache.org/activemq/browse/CAMEL-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-1508. Resolution: Fixed Fix Version/s: (was: 1.6.1) Only fixing on trunk as DefaulttTypeConverter is a bit different in 1.x trunk: 760877 > TypeConverter - Can find Object type converter even though there is a more > specialized converter to use > --- > > Key: CAMEL-1508 > URL: https://issues.apache.org/activemq/browse/CAMEL-1508 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 1.6.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0.0 > > > The code travels down the super to fast. And the code that checks for Object > and inherited types in the end of the lookup code should be run as last > resort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: BatchProcessor interrupt side effects
L.S.,
First of all, thanks for taking the time to review the code and come
up with these suggestions. Yes, I think it would probably make sense
to leverage the helper classes available in java.util.concurrent
instead of doing Thread.sleep() ourselves and then interrupting the
thread again when an Exchange arrives. Just wonder if we can't just
rely on some thread-safe queue or latch to provide the same semantics,
but anyway you're welcome to raise a JIRA issue and attach your
proposed patch there.
Regards,
Gert Vanthienen
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/4/1 huntc :
>
> I have noticed that the BatchProcessor class uses the Thread class interrupt
> method to wake the run loop from sleeping within the enqueueExchange method.
>
> The unfortunate side effect of this is that if the run loop is in the middle
> of processing exchanges, and the processing involves something slow like
> establishing a JMS connection over SSL, then the processing can become
> interrupted.
>
> This all became apparent during some performance testing that resulted in
> continuously adding exchanges to the aggregator, the threshold becoming
> reached, and then trying to enqueue the aggregated result to a JMS queue.
>
> If my analysis of the BatchProcessor is correct then I would recommend a
> Condition object being used instead of relying upon interrupting a thread.
> Perhaps something like the following (untested - could be mistakes of course
> - assumes present Camel 1.6 trunk):
>
>
> private class BatchSender extends Thread {
>
> private boolean enqueuedExchange = false;
> private Lock runLock = new ReentrantLock();
> private Condition runCondition = runLock.newCondition();
>
> private LinkedBlockingQueue queue;
>
> public BatchSender() {
> super("Batch Sender");
> this.queue = new LinkedBlockingQueue();
> }
>
> �...@override
> public void run() {
> runLock.lock();
> try {
> do {
> try {
> if (!enqueuedExchanged) {
> runCondition.await(batchTimeout,
> TimeUnit.MILLISECONDS);
> if (!enqueuedExchanged) {
> queue.drainTo(collection, batchSize);
> }
> }
>
> if (enqueuedExchanged) {
> enqueuedExchange = false;
>
> runLock.unlock();
> try {
> while (isInBatchCompleted(queue.size())) {
> queue.drainTo(collection, batchSize);
> }
>
> if (!isOutBatchCompleted()) {
> continue;
> }
>
> } finally {
> runLock.lock();
> }
> }
>
> runLock.unlock();
> try {
> try {
> sendExchanges();
> } catch (Exception e) {
> getExceptionHandler().handleException(e);
> }
>
> } finally {
> runLock.lock();
> }
>
> } catch (InterruptedException e) {
> break;
> }
>
> } while (true);
>
> } finally {
> runLock.unlock();
> }
>
> }
>
> public void cancel() {
> interrupt();
> }
>
> public void enqueueExchange(Exchange exchange) {
> queue.add(exchange);
> runLock.lock();
> try {
> enqueuedExchange = true;
> runCondition.signal();
> } finally {
> runLock.unlock();
> }
> }
>
> private void sendExchanges() throws Exception {
> Iterator iter = collection.iterator();
> while (iter.hasNext()) {
> Exchange exchange = iter.next();
> iter.remove();
> processExchange(exchange);
> }
> }
> }
>
>
> I acknowledge that the above is more complex than what is there presently
> but I think the complexity is necessary. Cancellations will still result in
> an interrupt and behave as they presently do. The major difference is
> considering what the condition is going into a sleep state (nothing enqueued
> that hasn't had its predicate tested), and when it comes out of sleep (if it
> has been), what must then be done. Either exchanges have been enqueued or it
> is time to process exchanges. Even if exchanges have been en
[jira] Created: (CAMEL-1508) TypeConverter - Can find Object type converter even though there is a more specialized converter to use
TypeConverter - Can find Object type converter even though there is a more specialized converter to use --- Key: CAMEL-1508 URL: https://issues.apache.org/activemq/browse/CAMEL-1508 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 1.6.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0.0, 1.6.1 The code travels down the super to fast. And the code that checks for Object and inherited types in the end of the lookup code should be run as last resort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
On Wed, Apr 1, 2009 at 11:51 AM, Roman Kalukiewicz wrote: > I would definitely support #1. > > #3 is not so good as a default one because it can cause some side effects > like when you use in-out JMS endpoint. If nothing listens to the queue, then > you will end up with 6 messages in request queue instead of one (assuming > you don't use transactions). > > BTW Last time when I was looking at it there was no easy way to do #3 even > if you want it (to have redeliveries, but send an exception in case they > fail). Yeah #3 should really be let TransactionErrorHandler support onException. Allowing you to catch certain exceptions and let it be handled so there are no rollback. > > Roman > > 2009/3/31 Claus Ibsen > >> Hi >> >> As we work on the Camel 2.0 I would suggest that we start a discussion >> what should be the preferred error handler defaults in Camel 2.0. >> What we currently have is the DLC is default and it does 6 retries >> with 1 sec apart and then just log an ERROR and ends the exchange. >> >> We have 3 different error handler types >> - no error handler (= disabled) >> - DeadLetterChannel (= default in 1.x) >> - TransactionErrorHandler (= using Spring TX) >> >> As people can use Camel in different runtimes and with different needs >> for error handling we cannot have a default that fits all situations. >> >> We could for instance do >> >> 1) >> Disable error handling by default. >> >> This would be the least surprises for end users. If there is some >> exception then it would be propagated back to the caller. >> We could even optimize the logic in Camel to avoid adding the >> interceptor that adds the noErrorHandler. >> >> +1 from me >> >> >> 2) >> Keep it as is >> big -1 from me. We have the luxury of being able to change defaults >> before 2.0 is released. So we should do it!!! >> >> >> 3) >> Use DeadLetterChannel but add a feature so it avoids failure handling >> it by default. So it will be able to do retries but if it fails all >> together >> it will propagate the exception back to the caller as if the have been >> no error handler at all. >> >> This feature could also be useable for end users in other situations, >> eg retry IOExceptions and in case of a all attempts failed then >> propgate the excpetion back to the caller. >> >> What should the option name be: >> - moveToDeadLetterQueue=false >> - handled=false (like the handled we have at onException) >> >> +1 as well. We can even do #1 and #3 >> >> >> 4) >> For TX its mostly all the Spring XML garbage that is needed to setup >> TX that can be a bit hard to get configure correct. >> So the JMS component have a transacted=true option to allow to do this >> itself or discover if there is a Spring TX manager already. >> >> Maybe we can default to use transactionErrorHandler if we can find a >> Spring TX manager. But this would only work for certain transports >> that support TX, and that is mostly only JMS and JDBC. >> >> So what should happens for routing not involving those, eg camel-cxf, >> over file to a mail etc? >> Could be confusing, if Camel uses TX for certain routes and the other >> for the other routes. >> >> So what we have now with the transacted=true option is good as end >> users need to explicit declare this option. >> We could maybe add this for the JDBC based components as well: JPA, JDBC, >> SQL. >> >> >> Any thoughts? >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
I would definitely support #1. #3 is not so good as a default one because it can cause some side effects like when you use in-out JMS endpoint. If nothing listens to the queue, then you will end up with 6 messages in request queue instead of one (assuming you don't use transactions). BTW Last time when I was looking at it there was no easy way to do #3 even if you want it (to have redeliveries, but send an exception in case they fail). Roman 2009/3/31 Claus Ibsen > Hi > > As we work on the Camel 2.0 I would suggest that we start a discussion > what should be the preferred error handler defaults in Camel 2.0. > What we currently have is the DLC is default and it does 6 retries > with 1 sec apart and then just log an ERROR and ends the exchange. > > We have 3 different error handler types > - no error handler (= disabled) > - DeadLetterChannel (= default in 1.x) > - TransactionErrorHandler (= using Spring TX) > > As people can use Camel in different runtimes and with different needs > for error handling we cannot have a default that fits all situations. > > We could for instance do > > 1) > Disable error handling by default. > > This would be the least surprises for end users. If there is some > exception then it would be propagated back to the caller. > We could even optimize the logic in Camel to avoid adding the > interceptor that adds the noErrorHandler. > > +1 from me > > > 2) > Keep it as is > big -1 from me. We have the luxury of being able to change defaults > before 2.0 is released. So we should do it!!! > > > 3) > Use DeadLetterChannel but add a feature so it avoids failure handling > it by default. So it will be able to do retries but if it fails all > together > it will propagate the exception back to the caller as if the have been > no error handler at all. > > This feature could also be useable for end users in other situations, > eg retry IOExceptions and in case of a all attempts failed then > propgate the excpetion back to the caller. > > What should the option name be: > - moveToDeadLetterQueue=false > - handled=false (like the handled we have at onException) > > +1 as well. We can even do #1 and #3 > > > 4) > For TX its mostly all the Spring XML garbage that is needed to setup > TX that can be a bit hard to get configure correct. > So the JMS component have a transacted=true option to allow to do this > itself or discover if there is a Spring TX manager already. > > Maybe we can default to use transactionErrorHandler if we can find a > Spring TX manager. But this would only work for certain transports > that support TX, and that is mostly only JMS and JDBC. > > So what should happens for routing not involving those, eg camel-cxf, > over file to a mail etc? > Could be confusing, if Camel uses TX for certain routes and the other > for the other routes. > > So what we have now with the transacted=true option is good as end > users need to explicit declare this option. > We could maybe add this for the JDBC based components as well: JPA, JDBC, > SQL. > > > Any thoughts? > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
[jira] Assigned: (CAMEL-1506) Recursively scan multipart nodes of an email for attachments - not just top level nodes
[ https://issues.apache.org/activemq/browse/CAMEL-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-1506: --- Assignee: Willem Jiang > Recursively scan multipart nodes of an email for attachments - not just top > level nodes > --- > > Key: CAMEL-1506 > URL: https://issues.apache.org/activemq/browse/CAMEL-1506 > Project: Apache Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.0.0 >Reporter: Ryan Gardner >Assignee: Willem Jiang >Priority: Minor > Attachments: MailContentAttachmentScanning.patch > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The current code will only scan the top level of a multipart message. This > misses any attachments that are under another node. > All unit tests still run for me after applying this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1507) Allow sending multipart/alternative MIME messages with both a plain-text and text/html body, and allow sending images inline
[ https://issues.apache.org/activemq/browse/CAMEL-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-1507: --- Assignee: Willem Jiang > Allow sending multipart/alternative MIME messages with both a plain-text and > text/html body, and allow sending images inline > > > Key: CAMEL-1507 > URL: https://issues.apache.org/activemq/browse/CAMEL-1507 > Project: Apache Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.0-M1 >Reporter: Ryan Gardner >Assignee: Willem Jiang > Attachments: mulitpartAlternativePatch.patch > > > To send a multipart/alternative email you have to follow a pretty specific > course. > This adds a property (which is poorly named in this patch) to the > MailConfiguration that names the header that contains the plaintext version > of the email, and adds a property where you can embed images inline. If an > attachment has a filename starting with "cid:" then this will add the > "Content-ID" header to that multipart body - which will allow the email > client to put the image in the appropriate place when it is viewed. (i.e. the > html email has something like and the attachment is > named 'cid:0001' - when it sees an inline attachment with "Content-ID: 0001" > it will put it in the right spot) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Moving Camel releases to Nexus
+1 Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Hadrian Zbarcea : > Forwarding to the correct address. > > Begin forwarded message: > >> From: James Strachan >> Date: March 31, 2009 2:31:50 PM EDT >> To: priv...@camel.apache.org >> Subject: Re: [DISCUSS] Moving Camel releases to Nexus >> Reply-To: priv...@camel.apache.org >> >> Shouldn't this be on the Dev list? >> >> >> On 31/03/2009, Hadrian Zbarcea wrote: >>> >>> Hi, >>> >>> Apache has a Nexus repository manager at [1] and a new release >>> procedure described [2]. The new Camel snapshots are already deployed >>> in Nexus thanks to Gert. I'd recommend deploying future camel >>> releases in Nexus. There is an INFRA-1950 [3] issue open that awaits >>> our decision. >>> >>> My +1 >>> Hadrian >>> >>> [1] https://repository.apache.org/index.html >>> [2] http://maven.apache.org/developers/release/releasing.html >>> [3] https://issues.apache.org/jira/browse/INFRA-1950 >>> >>> >> >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ > >
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
L.S., I'm in favor of disabling error handling by default as well. People should really configure this to suit their environment. And with my ServiceMix hat on, this would be a big improvement as well -- error handling should be configured there based on the properties of the given message flow (e.g. transaction or not, clustered or not, ...). Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Claus Ibsen : > Hi > > As we work on the Camel 2.0 I would suggest that we start a discussion > what should be the preferred error handler defaults in Camel 2.0. > What we currently have is the DLC is default and it does 6 retries > with 1 sec apart and then just log an ERROR and ends the exchange. > > We have 3 different error handler types > - no error handler (= disabled) > - DeadLetterChannel (= default in 1.x) > - TransactionErrorHandler (= using Spring TX) > > As people can use Camel in different runtimes and with different needs > for error handling we cannot have a default that fits all situations. > > We could for instance do > > 1) > Disable error handling by default. > > This would be the least surprises for end users. If there is some > exception then it would be propagated back to the caller. > We could even optimize the logic in Camel to avoid adding the > interceptor that adds the noErrorHandler. > > +1 from me > > > 2) > Keep it as is > big -1 from me. We have the luxury of being able to change defaults > before 2.0 is released. So we should do it!!! > > > 3) > Use DeadLetterChannel but add a feature so it avoids failure handling > it by default. So it will be able to do retries but if it fails all > together > it will propagate the exception back to the caller as if the have been > no error handler at all. > > This feature could also be useable for end users in other situations, > eg retry IOExceptions and in case of a all attempts failed then > propgate the excpetion back to the caller. > > What should the option name be: > - moveToDeadLetterQueue=false > - handled=false (like the handled we have at onException) > > +1 as well. We can even do #1 and #3 > > > 4) > For TX its mostly all the Spring XML garbage that is needed to setup > TX that can be a bit hard to get configure correct. > So the JMS component have a transacted=true option to allow to do this > itself or discover if there is a Spring TX manager already. > > Maybe we can default to use transactionErrorHandler if we can find a > Spring TX manager. But this would only work for certain transports > that support TX, and that is mostly only JMS and JDBC. > > So what should happens for routing not involving those, eg camel-cxf, > over file to a mail etc? > Could be confusing, if Camel uses TX for certain routes and the other > for the other routes. > > So what we have now with the transacted=true option is good as end > users need to explicit declare this option. > We could maybe add this for the JDBC based components as well: JPA, JDBC, SQL. > > > Any thoughts? > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
