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 claus.ib...@gmail.com: 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
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 hzbar...@gmail.com: Forwarding to the correct address. Begin forwarded message: From: James Strachan james.strac...@gmail.com 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 hzbar...@gmail.com 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/
[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.
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 claus.ib...@gmail.com 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
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
On Wed, Apr 1, 2009 at 11:51 AM, Roman Kalukiewicz roman.kalukiew...@gmail.com 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 claus.ib...@gmail.com 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: 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 hu...@mac.com:
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 enqueued then flow
can still drop down into sending exchanges if the batch thresholds have been
reached i.e.
[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.
[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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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] 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] 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.
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 gert.vanthie...@gmail.comwrote: 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 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
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] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects
[
https://issues.apache.org/activemq/browse/CAMEL-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 QueueExchange queue;
private boolean exchangeQueued = false;
private Lock queueMutex = new ReentrantLock();
private Condition queueCondition = queueMutex.newCondition();
public BatchSender() {
super(Batch Sender);
this.queue = new LinkedListExchange();
}
public void cancel() {
interrupt();
}
private void drainQueueTo(CollectionExchange 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();
[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-tabpanelfocusedCommentId=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] Commented: (CAMEL-1509) DefaultCamelContext.isStarting returns incorrect status
[
https://issues.apache.org/activemq/browse/CAMEL-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
Re: [DISCUSS] Move the Camel features into Camel
+1 On Thu, Apr 2, 2009 at 2:05 AM, Freeman Fang freeman.f...@gmail.com 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-tabpanelfocusedCommentId=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.
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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: helloworld!/hello] 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] 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-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] 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-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] 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] 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] 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] 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-tabpanelfocusedCommentId=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 image src=cid:0001 / 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
+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/
