Re: header names (sans dots)
On Mon, Jan 19, 2009 at 7:54 AM, Ramon Buckland ramon.buckl...@gmail.com wrote: We have the chance with Camel 2.0 where its not backwards compatible out-of-the-box in all cases. So its better to fix it now, or we have to wait until Camel 3.0 I would say fix it now. There are other cases also where dotted notation does not work well either. I can't recall all instances at the moment but recall groovy I had an issue once, and some other random places. I assume there are far more locations than just ftp also, are we brave enough to do a change all task, or just as we find them ? I can remove them as part of CAMEL-1241. Yeah we need to refactor all components when we do the name style change. I think you should align your component with the current style in FTP/File component. As the file language is dependent on keys to be consistent. So when we do the big change later we get this sorted at that time. regards ramon -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: camel-flatpack: write to flatpack format?
Hi Please add a ticket for this RFE and use the voting system in JIRA so we know what the community wants. We love contributions so if you are giving it a go to implement it: http://activemq.apache.org/contributing.html One way or the other. For instance doing so research with the flatpack how or if its possible to write back. I think I remember that it wasn't really supported in flatpack itself. I might remember wrong. On Mon, Jan 19, 2009 at 4:12 PM, Matteo Redaelli matteo.redae...@libero.it wrote: Hello I read in the wiki [Camel-Flatpack] only supports consuming from flatpack files to Object model. Any news about You can not (yet) write from Object model to flatpack format Any news regarding when writing from Object model to flatpack format is supported? 2.0? Thanks in advance Matteo -- View this message in context: http://www.nabble.com/camel-flatpack%3A-write-to-flatpack-format--tp21544963s22882p21544963.html Sent from the Camel - Development mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [CONF] Apache Camel: TidyMarkup (page edited)
Hi No need to apologize. Thanks for the contribution. Keep it up and as always family should come first :) On Tue, Jan 20, 2009 at 11:06 PM, Ramon Buckland ramon.buckl...@gmail.com wrote: Thanks Claus, apologies I have been stuck between work meetings and my twin girls to get that doco written. (never did) thanks for writing it .. and Yes Jon, I thought it very funny (apt) of your fix for the manual .. good work.! r. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Apache Camel - Ohloh restarted
Hi Looks like it the TLP transition kinda restarted the stats at Ohloh. Maybe we could get in touch with the people behind to get it kinda merged so we are back on track. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Components setting data on OUT
On Sat, Jan 24, 2009 at 9:08 PM, William Tam email.w...@gmail.com wrote: What we have stored in Headers today in Camel is both: - user headers - and system headers (added by Camel itself). I am starting to be more and more convinced that we should separate the two. So any headers that a users has enforced to be set should be kept in one Map and the others that the components set internally (such as SQL number of rows returned, or whatnot we have, there are many) in another Map. It means that a component would have to look for header in more than one place. Besides, the distinction of user vs system header is not always clear. For example, the operation name header for cxf endpoint can be set by user but it is also created by cxf component. I am sure there are many more examples. There is another header category: protocol headers. A protocol header is not really a user or system header. Protocol headers are header propagated from protocol like HTTP, which we do want to preserve in message header. The user headers is always preserved and copied along in the routing. User can always clear/remove unwanted headers. The system headers should be short lived as they are not really useable. So they are alive in the next step (process) in the route, and when the pipeline invokes next route thereafter these information is cleared. Separating these will also make the routing/tracing a bit easier as Users can recognize their own headers instead its mixed with all the noise the Camel components add. I wonder we can leverage/extend the HeaderFilterStrategy mechanism. Currently, it is only used for filtering unwanted headers (in both request and response direction) when we propagate headers between Camel and external messages (like HTTP). HeaderFilterStrategy is (or will be) associated with an endpoint. We could make HeaderFilterStrategy available to the exchange object. So, when an endpoint creates an exchange, the exchange gets a header filter strategy. Then, pipeline can do something like this to filter unwanted header: message.filterHeaders(). The header filter strategy is highly customizable for each endpoint (can have a component wide default) and it can be looked up from registry. Good pointers William. Yeah we can revist it after you have moved the header filters to the endpoint. Then we can check up upon how to leverage it as you suggest. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: git mirror
Hi +1 Can git do patch and apply patches properly? Kinda tired of SVN not having a good patch build in. patch -p0 does not handle file rename, delete etc. to well A patch hell when you get bigger patches to get it merged into the codebase Yeah the feature to stove away current code is great. IDEA has such a feature for SVN = shelve changes. On Tue, Jan 27, 2009 at 1:32 PM, Jon Anstey jans...@gmail.com wrote: +1 On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Hi all, At the risk of opening up a can of worms, would it be possible and/or is anyone interested in having a git mirror of camel's svn repo at http://jukka.zitting.name/git/ ? - aaron -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738878 - in /camel/trunk/camel-core/src/test/java/org/apache/camel: ./ component/file/ management/
(domainName + :type=routes,*), null);
+s = mbsc.queryNames(new ObjectName(domainName + :type=routes,*),
null);
assertEquals(Could not find 1 route: + s, 1, s.size());
-
}
public void testCounters() throws Exception {
-
MockEndpoint resultEndpoint = resolveMandatoryEndpoint(mock:end,
MockEndpoint.class);
resultEndpoint.expectedBodiesReceived(helloworld!/hello);
sendBody(direct:start, helloworld!/hello);
@@ -79,7 +73,6 @@
verifyCounter(mbsc, new ObjectName(domainName + :type=routes,*));
verifyCounter(mbsc, new ObjectName(domainName +
:type=processors,*));
-
}
protected void verifyCounter(MBeanServerConnection beanServer,
ObjectName name) throws Exception {
@@ -93,17 +86,17 @@
assertNotNull(Expected attribute found. MBean registered under a
+ 'domain:name=Stats,*' key must be of type
PerformanceCounter.class,
valueofNumExchanges);
-assertTrue(valueofNumExchanges == 1);
+assertEquals(Long.valueOf(1), valueofNumExchanges);
Long valueofNumCompleted = (Long)beanServer.getAttribute(pcob,
NumCompleted);
assertNotNull(Expected attribute found. MBean registered under a
+ 'domain:name=Stats,*' key must be of type
PerformanceCounter.class,
valueofNumCompleted);
-assertTrue(valueofNumCompleted == 1);
+assertEquals(Long.valueOf(1), valueofNumCompleted);
Long valueofNumFailed = (Long)beanServer.getAttribute(pcob,
NumFailed);
assertNotNull(Expected attribute found. MBean registered under a
+ 'domain:name=Stats,*' key must be of type
PerformanceCounter.class,
valueofNumFailed);
-assertTrue(valueofNumFailed == 0);
+assertEquals(Long.valueOf(0), valueofNumFailed);
Double valueofMinProcessingTime =
(Double)beanServer.getAttribute(pcob, MinProcessingTimeMillis);
assertNotNull(Expected attribute found. MBean registered under a
+ 'domain:name=Stats,*' key must be of type
PerformanceCounter.class,
@@ -131,7 +124,6 @@
assertNotNull(Expected last completion time to be available,
beanServer.getAttribute(pcob,
LastExchangeCompletionTime));
-
}
protected RouteBuilder createRouteBuilder() {
Modified:
camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
URL:
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java?rev=738878r1=738877r2=738878view=diff
==
---
camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
(original)
+++
camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
Thu Jan 29 15:03:12 2009
@@ -26,21 +26,20 @@
* a client.
*
* @version $Revision$
- *
*/
public class JmxInstrumentationWithConnectorTest extends
JmxInstrumentationUsingDefaultsTest {
protected static final String JMXSERVICEURL =
-service:jmx:rmi:///jndi/rmi://localhost:2000/jmxrmi/camel;
+service:jmx:rmi:///jndi/rmi://localhost:2123/jmxrmi/camel;
protected JMXConnector clientConnector;
@Override
protected void setUp() throws Exception {
-sleepForConnection = 2000;
-System.setProperty(JmxSystemPropertyKeys.CREATE_CONNECTOR, True);
+sleepForConnection = 3000;
+System.setProperty(JmxSystemPropertyKeys.CREATE_CONNECTOR, true);
// need to explicit set it to false to use non-platform mbs
-System.setProperty(JmxSystemPropertyKeys.USE_PLATFORM_MBS, False);
-System.setProperty(JmxSystemPropertyKeys.REGISTRY_PORT, 2000);
+System.setProperty(JmxSystemPropertyKeys.USE_PLATFORM_MBS, false);
+System.setProperty(JmxSystemPropertyKeys.REGISTRY_PORT, 2123);
super.setUp();
}
@@ -65,8 +64,7 @@
protected MBeanServerConnection getMBeanConnection() throws Exception {
if (mbsc == null) {
if (clientConnector == null) {
-clientConnector = JMXConnectorFactory.connect(
-new JMXServiceURL(JMXSERVICEURL), null);
+clientConnector = JMXConnectorFactory.connect(new
JMXServiceURL(JMXSERVICEURL), null);
}
mbsc = clientConnector.getMBeanServerConnection();
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738999 - in /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf: CxfEndpoint.java CxfExchange.java CxfMessage.java converter/CxfConverter.java
());
+if (tc != null) {
+return tc.convertTo(type, exchange, embedded);
+}
+}
+}
+}
+}
+
+return null;
+}
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738999 - in /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf: CxfEndpoint.java CxfExchange.java CxfMessage.java converter/CxfConverter.java
On Fri, Jan 30, 2009 at 7:04 AM, William Tam email.w...@gmail.com wrote:
Hi Claus,
The code in CxfMessage#getBody was checking if a message body was a
org.apache.cxf.message.MessageContentList. If so, it extracted the
first element and applied converter to the first element. That piece
of logic now resides in the CxfConverter.convertTo, which is a
FallbackConverter. Let me know if I am missing something,
Thanks,
William
Great I kinda forgot from the commit log that you deleted 2 files. The
content of these files is not logged :)
And I just wanted to raise a flag in case there was still something in
the CXF that should be looked at.
On Fri, Jan 30, 2009 at 12:23 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi Willem
There might be some left overs still there. I remember Jiang added
something to CxfMessage#getBody (or someplace like that) that would
kinda do something like that below.
Maybe that code is still there?
There is a ticket in JIRA somewhere about it, I can find it if you
need it. Ticket reported by me on camel-cxf and fixed by Jiang.
On Thu, Jan 29, 2009 at 9:35 PM, w...@apache.org wrote:
Author: wtam
Date: Thu Jan 29 20:35:54 2009
New Revision: 738999
URL: http://svn.apache.org/viewvc?rev=738999view=rev
Log:
use FallbackConverter in camel-cxf component, which means we can get rid of
CxfMessage and CxfExchange class. Very cool.
Removed:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfExchange.java
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfMessage.java
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
URL:
http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java?rev=738999r1=738998r2=738999view=diff
==
---
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(original)
+++
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
Thu Jan 29 20:35:54 2009
@@ -25,8 +25,6 @@
import org.apache.camel.CamelContext;
import org.apache.camel.CamelException;
import org.apache.camel.Consumer;
-import org.apache.camel.Exchange;
-import org.apache.camel.ExchangePattern;
import org.apache.camel.HeaderFilterStrategyAware;
import org.apache.camel.Processor;
import org.apache.camel.Producer;
@@ -97,11 +95,6 @@
return new CxfConsumer(this, processor);
}
-@Override
-public Exchange createExchange(ExchangePattern pattern) {
-return new CxfExchange(this, pattern);
-}
-
public boolean isSingleton() {
return true;
}
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
URL:
http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java?rev=738999r1=738998r2=738999view=diff
==
---
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
(original)
+++
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
Thu Jan 29 20:35:54 2009
@@ -22,9 +22,13 @@
import org.apache.camel.Converter;
import org.apache.camel.Endpoint;
+import org.apache.camel.Exchange;
+import org.apache.camel.FallbackConverter;
+import org.apache.camel.TypeConverter;
import org.apache.camel.component.cxf.CxfSpringEndpoint;
import org.apache.camel.component.cxf.DataFormat;
import
org.apache.camel.component.cxf.spring.CxfEndpointBeanDefinitionParser.CxfSpringEndpointBean;
+import org.apache.camel.spi.TypeConverterRegistry;
import org.apache.camel.spring.SpringCamelContext;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -89,4 +93,41 @@
return DataFormat.valueOf(name.toUpperCase());
}
+/**
+ * Use a fallback type converter so we can convert the embedded list
element
+ * if the value is MessageContentsList. The algorithm of this
converter
+ * finds the first non-null list element from the list and applies
convertion
+ * to the list element.
+ *
+ * @param type the desired type to be converted to
+ * @param exchange optional exchange which can be null
+ * @param value the object to be converted
+ * @param registry type converter registry
+ * @return the converted value of the desired type
[HEADS UP] - File component changes in Camel 2.0
Hi
As some of you know the file component have had a major refactor ...
actually you can nearly consider it as a rewrite in Camel 2.0.
This mail is about a few remaining issues I want to give a heads up
upon and feedback:
Force a filename to be provided when wring a file
I want to force file producer always requiring a header value with the
filename to write.
What we have in Camel 1.x is that if no filename header is provided it
will fallback to use the message id as the filename.
For me that has no use, as its kinda like telling a database here is
some data store it somewhere, without providing, schema, table, column
names.
So I want it to reject writing a file and report an exception that the
filename is missing.
The file language supports you if you want to use the message id as
the filename. Just set the header value as: ${id}
And also remove option: ignoreFileNameHeader
Thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [HEADS UP] - File component changes in Camel 2.0
Hi
Yeah please take a look at the GenericFileExclusiveReadLockStrategy
and see if you can implement it as a implementation of this interface?
Then it can be added into camel 2.0 as an other option to choose.
But beware that the code in trunk is currently have 2 file components.
FileComponent is the old one that is currently active
NewFileComponent is the new one temporary there side by side until its
rock solid and can replace the FileComponent.
The trick is that you can modify the file component file
Index: src/main/resources/META-INF/services/org/apache/camel/component/file
===
--- src/main/resources/META-INF/services/org/apache/camel/component/file
(revision 739943)
+++ src/main/resources/META-INF/services/org/apache/camel/component/file
(working copy)
@@ -15,5 +15,5 @@
# limitations under the License.
#
-class=org.apache.camel.component.file.FileComponent
-strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory
\ No newline at end of file
+class=org.apache.camel.component.file.NewFileComponent
+strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory
\ No newline at end of file
Where you just use the NewFileComponent and the New factory.
On Mon, Feb 2, 2009 at 3:54 PM, Aaron Crickenberger
aaron.crickenber...@intalgent.com wrote:
On a slightly related tangent, I'm partly responsible for the hackish code
in FileConsumer's (old) isUnchanged() method (
https://issues.apache.org/activemq/browse/CAMEL-250).
Camel 1.5's exclusiveReadLock feature is unfortunately still picking up
files too early, so I have to fall back to the deprecated behavior. This
happens regardless of the file processing strategy (delete, rename, etc.)
Is there any chance the hackish double-polling stuff can be put back in to
2.0 as a non-default file locking strategy? I can take a crack at it, I
just wasn't sure if the code was still in flux.
- aaron
On Mon, Feb 2, 2009 at 4:44 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Fri, Jan 30, 2009 at 5:40 PM, Aaron Crickenberger
aaron.crickenber...@intalgent.com wrote:
I would hesitate if only because requiring a particular header seems off,
are there other components that do the same?
I haven't looked much at Camel 2.0's code, but it looks like camel-1.x's
file component's expression property could support both scenarios. Use
a
default ${id} expression, but allow user to configure w/ a ${in.header}
expression that barks if the header's not present, no?
That is correct.
Thanks for the feedback. We will leave it as is.
- aaron
On Fri, Jan 30, 2009 at 9:49 AM, James Strachan
james.strac...@gmail.comwrote:
So long as files are written in some directory and they are unique and
preserve order - does it matter if they are generated (from the
message ID say) or the user explicitly gives some name? Like Jon I'd
be tempted ot leave the default behaviour?
2009/1/30 Claus Ibsen claus.ib...@gmail.com:
Hi
As some of you know the file component have had a major refactor ...
actually you can nearly consider it as a rewrite in Camel 2.0.
This mail is about a few remaining issues I want to give a heads up
upon and feedback:
Force a filename to be provided when wring a file
I want to force file producer always requiring a header value with the
filename to write.
What we have in Camel 1.x is that if no filename header is provided it
will fallback to use the message id as the filename.
For me that has no use, as its kinda like telling a database here is
some data store it somewhere, without providing, schema, table, column
names.
So I want it to reject writing a file and report an exception that the
filename is missing.
The file language supports you if you want to use the message id as
the filename. Just set the header value as: ${id}
And also remove option: ignoreFileNameHeader
Thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [HEADS UP] - File component changes in Camel 2.0
On Fri, Jan 30, 2009 at 5:40 PM, Aaron Crickenberger
aaron.crickenber...@intalgent.com wrote:
I would hesitate if only because requiring a particular header seems off,
are there other components that do the same?
I haven't looked much at Camel 2.0's code, but it looks like camel-1.x's
file component's expression property could support both scenarios. Use a
default ${id} expression, but allow user to configure w/ a ${in.header}
expression that barks if the header's not present, no?
That is correct.
Thanks for the feedback. We will leave it as is.
- aaron
On Fri, Jan 30, 2009 at 9:49 AM, James Strachan
james.strac...@gmail.comwrote:
So long as files are written in some directory and they are unique and
preserve order - does it matter if they are generated (from the
message ID say) or the user explicitly gives some name? Like Jon I'd
be tempted ot leave the default behaviour?
2009/1/30 Claus Ibsen claus.ib...@gmail.com:
Hi
As some of you know the file component have had a major refactor ...
actually you can nearly consider it as a rewrite in Camel 2.0.
This mail is about a few remaining issues I want to give a heads up
upon and feedback:
Force a filename to be provided when wring a file
I want to force file producer always requiring a header value with the
filename to write.
What we have in Camel 1.x is that if no filename header is provided it
will fallback to use the message id as the filename.
For me that has no use, as its kinda like telling a database here is
some data store it somewhere, without providing, schema, table, column
names.
So I want it to reject writing a file and report an exception that the
filename is missing.
The file language supports you if you want to use the message id as
the filename. Just set the header value as: ${id}
And also remove option: ignoreFileNameHeader
Thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [jira] Commented: (CAMEL-1302) Documentation - Add camel-bindy documentation
Hi Bindy is a component donated by Charles Moulliard that choosed that name. I guess its named like this sine it does annotation based POJO binding from other data formats, currently only CSV. On Fri, Jan 30, 2009 at 4:36 PM, William Tam email.w...@gmail.com wrote: BTW, I am curious about the name bindy. What does it mean? On Fri, Jan 30, 2009 at 1:28 AM, Claus Ibsen (JIRA) j...@apache.org wrote: [ https://issues.apache.org/activemq/browse/CAMEL-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=49034#action_49034 ] Claus Ibsen commented on CAMEL-1302: Charles the wiki page is here you should update: http://camel.apache.org/bindy.html Documentation - Add camel-bindy documentation - Key: CAMEL-1302 URL: https://issues.apache.org/activemq/browse/CAMEL-1302 Project: Apache Camel Issue Type: Sub-task Components: camel-bindy Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Need example demonstrating camel-mail support of endpoint sending multipart/alternative message
On Tue, Feb 3, 2009 at 9:19 PM, MarkBi mabis...@cs.indiana.edu wrote: Need an example demonstrating camel-mail support of endpoint sending a multipart/alternative message (plain text body and equivalent html body). ./src/test/java/org/apache/camel/component/mail/MimeMessageConsumeTest.java is an example using javamail transport to send a multipart/alternative but not the camel-mail endpoint. If an example is not readily available, does camel-mail support this or is it a known limitation due to single body exchange? If it is a limitation then is it possible to send 2nd part as attachment (but without filename, disposition, etc...) and with the appropriate alternative content types. Many thanks! Hi I dont think we have such an example. Many of the wiki documentation is usually based on real unit tests. And you have looked what we got. We love contributions, so if you feel like it then please give it a stab at it to add this feature/example that you need. http://camel.apache.org/contributing.html -- View this message in context: http://www.nabble.com/Need-example-demonstrating-camel-mail-support-of-endpoint-sending-multipart-alternative-message-tp21818001s22882p21818001.html Sent from the Camel - Development mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
[Camel 2.0] - Help testing refactored File component
Hi In Camel 2.0 we have refactored the File component to leverage a VFS within Camel itself (common code/interface is named GenericFileXXX) As the file component is used extensivly within Camel itself and to test all camel components it would be great if we could give it a test drive on various OS before making the change permanent. So if you have the time then please test it as: 1) You can change to use NewFileComponent by: Change these lines: class=org.apache.camel.component.file.FileComponent strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory To: class=org.apache.camel.component.file.NewFileComponent strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory In the file: src/main/resources/META-INF/services/org/apache/camel/component/file 2) Run tests in camel-core, camel-spring, camel-ftp, or if you have the time the full package :) mvn clean install For a period of time we will have both file components in Camel 2.0 (the old and the new) side by side. The idea is to keep the old in case something was overlooked and we can switch back for comparison. When everything works and is rock solid then we will remove the old one and make the new the default one. After this test and if it goes well, then we will switch to use the NewFileComponent in Camel trunk code and run with it for a while, and give TeamCity its chance to run extensivly test with it. But before that I would love to iron out any obscure issues on other platforms, than what I use (Mac OS) -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang willem.ji...@gmail.com wrote: Hi Claus, I'm monitoring the tests in windows box for a while, now it looks good :) I just have th quick note for the NewFileComponent. If we plan to rename the newfile component to file component when all the file tests become stable, we don't need to mark the FileComponent as deprecated or we should add this information into the FileComponent java doc. Because current user can't change they code to use NewFileComponent now and the NewFileComponent will finally be rename to FileComponent. Am I right? Yes it should eventually be renamed form NewFileComponent to FileComponent. We are in a kind of in between state right now. The faster/better we can test it on different OS then faster we can change the default in camel-core to use NewFileComponent, using the service/.../file trick. Then the old File component that is marked as @deprecated will not be used at all. It is just there in case there is a strange bug, then we can swtich over and use it for comparison. After eg a week or so, and Team City is also happy then we can do the big switch and remove the @deprecated and rename the NewFile to File. Willem Claus Ibsen wrote: Hi In Camel 2.0 we have refactored the File component to leverage a VFS within Camel itself (common code/interface is named GenericFileXXX) As the file component is used extensivly within Camel itself and to test all camel components it would be great if we could give it a test drive on various OS before making the change permanent. So if you have the time then please test it as: 1) You can change to use NewFileComponent by: Change these lines: class=org.apache.camel.component.file.FileComponent strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory To: class=org.apache.camel.component.file.NewFileComponent strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory In the file: src/main/resources/META-INF/services/org/apache/camel/component/file 2) Run tests in camel-core, camel-spring, camel-ftp, or if you have the time the full package :) mvn clean install For a period of time we will have both file components in Camel 2.0 (the old and the new) side by side. The idea is to keep the old in case something was overlooked and we can switch back for comparison. When everything works and is rock solid then we will remove the old one and make the new the default one. After this test and if it goes well, then we will switch to use the NewFileComponent in Camel trunk code and run with it for a while, and give TeamCity its chance to run extensivly test with it. But before that I would love to iron out any obscure issues on other platforms, than what I use (Mac OS) -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
Hi I enabled it on trunk right now: New Revision: 741515 On Fri, Feb 6, 2009 at 9:39 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi I will change the code in trunk to use the NewFileComponent later this afternoon. Then we have the weekend for the team city servers to crunch on testing as well. Willem fixes the last remaning issues on the windows box, and I think I got the occasional failing ones on the HP/AIX boxes as well. The change is only the META-INF/service/ .../ file trick by setting the file scheme to use NewFileComponent, instead of FileComponent. Then we can run with it for a while until we are all happy and can do the last transition and zap the old code. On Thu, Feb 5, 2009 at 11:07 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang willem.ji...@gmail.com wrote: Hi Claus, I'm monitoring the tests in windows box for a while, now it looks good :) I just have th quick note for the NewFileComponent. If we plan to rename the newfile component to file component when all the file tests become stable, we don't need to mark the FileComponent as deprecated or we should add this information into the FileComponent java doc. Because current user can't change they code to use NewFileComponent now and the NewFileComponent will finally be rename to FileComponent. Am I right? Yes it should eventually be renamed form NewFileComponent to FileComponent. We are in a kind of in between state right now. The faster/better we can test it on different OS then faster we can change the default in camel-core to use NewFileComponent, using the service/.../file trick. Then the old File component that is marked as @deprecated will not be used at all. It is just there in case there is a strange bug, then we can swtich over and use it for comparison. After eg a week or so, and Team City is also happy then we can do the big switch and remove the @deprecated and rename the NewFile to File. Willem Claus Ibsen wrote: Hi In Camel 2.0 we have refactored the File component to leverage a VFS within Camel itself (common code/interface is named GenericFileXXX) As the file component is used extensivly within Camel itself and to test all camel components it would be great if we could give it a test drive on various OS before making the change permanent. So if you have the time then please test it as: 1) You can change to use NewFileComponent by: Change these lines: class=org.apache.camel.component.file.FileComponent strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory To: class=org.apache.camel.component.file.NewFileComponent strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory In the file: src/main/resources/META-INF/services/org/apache/camel/component/file 2) Run tests in camel-core, camel-spring, camel-ftp, or if you have the time the full package :) mvn clean install For a period of time we will have both file components in Camel 2.0 (the old and the new) side by side. The idea is to keep the old in case something was overlooked and we can switch back for comparison. When everything works and is rock solid then we will remove the old one and make the new the default one. After this test and if it goes well, then we will switch to use the NewFileComponent in Camel trunk code and run with it for a while, and give TeamCity its chance to run extensivly test with it. But before that I would love to iron out any obscure issues on other platforms, than what I use (Mac OS) -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
[HEADS-UP] - Validating unknown options with prefix for lenient endpoints
Hi
As a kinda nice working on CAMEL-1328 I discovered that you could pass
on bogus httpClient parameters in the URI options as the endpoint is
lenient.
So I added feature into camel-core to be able to validate this before
hand and catch if end user have made a type mistake.
eg in this sample we configure httpClient.xxx=true but there are no
xxx options on HttpClient
public void configure() {
from(direct:start).setHeader(HTTP_METHOD,
POST).to(http://www.google.com?httpClient.xxx=true;);
}
If the endpoint is lenient as in the case with Http component, it
would not before hand catch this. So we need to trigger the validation
in the HttpComponent
With this new method in DefaultComponent:
validateUnknownParameters(uri, parameters, httpClient.);
// http client can be configured from URI options
HttpClientParams clientParams = new HttpClientParams();
IntrospectionSupport.setProperties(clientParams, parameters,
httpClient.);
// validate that we could resolve all httpClient. parameters
as this component is lenient
validateUnknownParameters(uri, parameters, httpClient.);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [VOTE] Release Apache Camel 1.6.0 (RC1)
+1 yeah On Thu, Feb 12, 2009 at 3:52 PM, Jon Anstey jans...@gmail.com wrote: Looks good except for a few minor documentation things: In the NOTICE.txt I made the following change -Copyright 2005-2006 The Apache Software Foundation +Copyright 2007-2009 The Apache Software Foundation Its been incorrect since Camel 1.0 so I don't think its a showstopper ;) Also there were a few old web site URLs lying around in READMEs. Again no biggie. Here's my +1 On Thu, Feb 12, 2009 at 2:16 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: A new apache-camel-1.6.0-RC1 is out with 166 new features, improvements and bug fixes. Please find the distro here: http://people.apache.org/~hadrian/apache-camel-1.6.0-RC1/maven2/http://people.apache.org/%7Ehadrian/apache-camel-1.6.0-RC1/maven2/ The tarballs are here http://people.apache.org/~hadrian/apache-camel-1.6.0-RC1/maven2/org/apache/camel/apache-camel/1.6.0/http://people.apache.org/%7Ehadrian/apache-camel-1.6.0-RC1/maven2/org/apache/camel/apache-camel/1.6.0/ Please vote to approve this release binary [ ] +1 Release the binary as Apache Camel 1.6.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r743762 - in /camel/trunk/components/camel-restlet/src: main/java/org/apache/camel/component/restlet/ test/java/org/apache/camel/component/restlet/
RestletQueryTest extends ContextTestSupport {
private static final String QUERY_STRING = foo=bartest=123;
-
@Override
protected RouteBuilder createRouteBuilder() {
-
return new RouteBuilder() {
@Override
public void configure() throws Exception {
from(restlet:http://localhost:9080/users/{username};)
.process(new SetUserProcessor());
-
}
-
};
}
class SetUserProcessor implements Processor {
public void process(Exchange exchange) throws Exception {
-assertEquals(QUERY_STRING,
exchange.getIn().getHeader(RestletConstants.QUERY_STRING,
-String.class));
+assertEquals(QUERY_STRING,
exchange.getIn().getHeader(RestletConstants.QUERY_STRING, String.class));
}
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Hudson CI builds for Apache Camel
On Mon, Feb 16, 2009 at 8:44 AM, Gert Vanthienen gert.vanthie...@skynet.be wrote: Claus, How about adding a Continuous Integration page on http://camel.apache.org/developers.html? +1 And btw add links to both 1.x and trunk Regards, Gert Claus Ibsen wrote: Hi Great with the hudson, nice and easy overview of once a day build. I would like to add a link to it from the Camel wiki pages. Where is a good location for such a link? The link should point to: http://hudson.zones.apache.org/hudson/job/Camel/ On Tue, Feb 10, 2009 at 2:12 PM, Jon Anstey jans...@gmail.com wrote: Aha! JIRA has been created :) On Tue, Feb 10, 2009 at 9:37 AM, Gert Vanthienen gert.vanthie...@skynet.bewrote: Jon, Yes, you can. Instructions can be found on http://wiki.apache.org/general/Hudson. Regards, Gert Jon Anstey wrote: Cool stuff. Thanks for getting this set up! Now I wonder if I can get an account on hudson... :) On Tue, Feb 10, 2009 at 9:04 AM, Gert Vanthienen gert.vanthie...@skynet.bewrote: L.S., I have set up CI builds for Apache Camel on hudson.zones.apache.org, both for trunk and for the camel-1.x branch. Since our builds are running for over an hour, I have currently configured these to check for svn updates only twice per day -- amounting to a total of approx. 4 hours of build time on the build server per day. The first few builds have run into technical difficulties, but now that those have been resolved, the weather reports should start improving soon. I'll keep an extra eye on things for a few days to iron out any remaining problems in the build setup. Regards, Gert -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 - Keys for header problem
Hi
We have a bullet on the Camel 2.0 design page:
http://camel.apache.org/camel-20-design.html
Bullet:
using Camel${component}${name} pattern as header keys instead of using
package names with dots that isn't likely to be transported by JMS or
other transport types
Currently we have mixed content using the old style (using package
names) and the new style.
What I would like to get done before we have a M1 version is to get
this fixed beforehand.
As the change involves looking into all components and fixing it one
by one it would take some time.
If you are in doubt why we should do it, then i will quote what
Jonathan wrote on IRC
this is CamelCase style
Well spotted Jon, of course we should have CamelCase in Camel :)
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] Async messages and UOWs
Hi I am ready On Mon, Feb 16, 2009 at 8:34 AM, Gert Vanthienen gert.vanthie...@skynet.be wrote: Hadrian, Count me in. Regards, Gert Hadrian Zbarcea wrote: Hi, We are planning a brainstorming session around CAMEL-1336, UOWs and async messaging on irc the #camel channel on Tue 02/17/2009 at 13:00 GMT. Please join us and express your thoughts if interested. We will post the transcript of that discussion on this mailing list as well, in case you'll miss it. Hadrian -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Wed, Feb 18, 2009 at 3:07 AM, Willem Jiang willem.ji...@gmail.com wrote:
I think the component developers should aware these header if they want
to use them in their component.
I have a quick question about this change of camel-cxf component.
As you know cxf message using the dots name as the header key, like the
Message.RESPONSE_CODE, Message.PROTOCOL_HEADERS etc. These headers are
used wildly in camel-cxf component and application user may use them
direly in their processor if they familiar with CXF.
If we want to support the CamelCase style header key in camel-cxf
component.Do we need to extract mapping layer between the camel-cxf
message and cxf message?
I don't know if we can get enough benefits to overcome the inconvenience
of CamelCase style header.
For the JMS , we map the header key with dot separator to slash
separator back and forth in the JMS transport binding layer. And we can
isolate this kind of special in JMS.
Just my 2 cents.
Willem
How do you handle sending SOAP over JMS that CXF support? Do you do
any tricks there as well to conform to the JMS spec?
I do think that any header we expose/set in Camel should be the
CamelCase style. Then whatever other framework does is that framework
choice.
But yeah its some task to look into each and every component and fix
it to the new style.
William Tam wrote:
I agreed with the convention. Just one question, are we going to have
component neutral headers that can be understood by more than one
component? If we are, what's the convention and where should they go
in the source? The obvious reason is the interoperability between
components. For example, if I am writing a component that needs to
understand http headers. my component will then have to check for
CamelHttpResponseCode and CamelRestletResponseCode to be able to work
with Http and Restlet components.
On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
We have a bullet on the Camel 2.0 design page:
http://camel.apache.org/camel-20-design.html
Bullet:
using Camel${component}${name} pattern as header keys instead of using
package names with dots that isn't likely to be transported by JMS or
other transport types
Currently we have mixed content using the old style (using package
names) and the new style.
What I would like to get done before we have a M1 version is to get
this fixed beforehand.
As the change involves looking into all components and fixing it one
by one it would take some time.
If you are in doubt why we should do it, then i will quote what
Jonathan wrote on IRC
this is CamelCase style
Well spotted Jon, of course we should have CamelCase in Camel :)
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Tue, Feb 17, 2009 at 4:57 PM, William Tam email.w...@gmail.com wrote:
I agreed with the convention. Just one question, are we going to have
component neutral headers that can be understood by more than one
component? If we are, what's the convention and where should they go
in the source? The obvious reason is the interoperability between
components. For example, if I am writing a component that needs to
understand http headers. my component will then have to check for
CamelHttpResponseCode and CamelRestletResponseCode to be able to work
with Http and Restlet components.
I think each component should keep the headers in its own namespace.
So yeah you component should check for both.
In fact it can probably just check for endsWith(ResponseCode) to
cater for different prefixes.
On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
We have a bullet on the Camel 2.0 design page:
http://camel.apache.org/camel-20-design.html
Bullet:
using Camel${component}${name} pattern as header keys instead of using
package names with dots that isn't likely to be transported by JMS or
other transport types
Currently we have mixed content using the old style (using package
names) and the new style.
What I would like to get done before we have a M1 version is to get
this fixed beforehand.
As the change involves looking into all components and fixing it one
by one it would take some time.
If you are in doubt why we should do it, then i will quote what
Jonathan wrote on IRC
this is CamelCase style
Well spotted Jon, of course we should have CamelCase in Camel :)
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper - Foos
+1 On Wed, Feb 18, 2009 at 3:33 PM, Jon Anstey jans...@gmail.com wrote: +1 On Wed, Feb 18, 2009 at 10:58 AM, Hadrian Zbarcea hzbar...@gmail.comwrote: +1 I think the merges back to the camel-1.x are a nuisance we can live with and will almost disappear after the fist hump. Hadrian On Feb 18, 2009, at 8:37 AM, James Strachan wrote: 2009/2/18 Claus Ibsen claus.ib...@gmail.com: On Wed, Feb 18, 2009 at 1:49 PM, James Strachan james.strac...@gmail.com wrote: One naming convention I really like from the Google Collections library is using the plural name of a type/interface/base class as the helper class for static helper methods. So we could rename things like ExchangeHelper to Exchanges, CamelContextHelper to CamelContexts. Much neater IMHO. These helper classes are all internal mostly for Camel implementation details; so wondering if it'd make sense to refactor them for 2.0? Thoughts? +1 Like java.util.Collections or java.util.Arrays :) What about those util classes? ResolverUtil (I dislike this name, as its not a light weight util class) And if we had a StringUtil that many framework have, should it be Strings And ObjectHelper should be Objects? A bit close to Object/String maybe hard to spot. Yeah! Whenever working with Objects in Google collections its actually quite easy to remember after a while. Seems more natural - once you're over the hump - than using Foo[Helper|Utils|Util|WhateverElse] etc I often can't remember if its Helper or Util or Utils :) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: question on HttpMessage.populateInitialHeaders
On Tue, Feb 24, 2009 at 2:34 AM, William Tam email.w...@gmail.com wrote:
In HttpMessage.populateInitialHeaders(), we only propagate parameters
for GET request. Does anyone see any harm in propagating other
parameters of HTTP methods?
I was wondering if the API below can return parameters for POST etc?
Maybe the answer is obvious but I thought that API below fetches the
GET URI parameters?
So which other operations can it also get parameters from?
For POST aren't paramenters not stored as HTTP headers?
//if the request method is Get, we also populate the http
request parameters
if (request.getMethod().equalsIgnoreCase(GET)) {
names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String)names.nextElement();
Object value = request.getParameter(name);
map.put(name, value);
}
}
Thanks,
William
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Discussion of scope for next Apache Camel 1.x release
Hi I was wondering if we should start a discussion on the scope for the next Apache Camel 1.x release (notice 1.x branch) As we have always done minor versions and no patch releases I was wondering if we should focus on doing a - 1.6.1 patch release so end users have a stable release that should be drop in compatible - or a new 1.7.0 release I am in favor of focusing on a 1.6.1 release. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Where exception handling should set a handled exception?
Hi Roman Could you add a route example to that. AFAIR this is *only* with the try .. handle DSLs ? I can enlighten that on the DeadLetterChannel we store previoysly occured exception as a property when we do redelivery. There is a constant KEY for it on the Exchange (Camel 2.0) String EXCEPTION_CAUGHT = CamelExceptionCaught; On Wed, Feb 25, 2009 at 12:10 PM, Roman Kalukiewicz roman.kalukiew...@gmail.com wrote: Hello! Recently I created an issue (CAMEL-1356) about exception handling and now I'm not really sure if it is really a bug or not. So I'm asking for your opinions. The problem is that when exception is caught it is set as a 'caught.exception' header on IN message. It means that if an exception is thrown on an exchange that already has OUT message it will be lost after the first step of a pipeline. We have few possible solutions here: 1) Keep it as it is - then we know where to look for this header in the first step of the pipeline - we can also use bean integration and @Header annotation to retrieve it) 2) Put the exception to header on OUT message if it is present - then it will be preserved in the pipeline. But then first step of the pipeline has to be clever - it has to look for it in OUT message. Moreover it is more general problem - if we allow OUT messages there, then you cannot use for example setHeader(foo) (you can, but it is useless, as out is propagated anyway) 3) Put it into exchange property - maybe the best solution as it is propagated, and we always know where to look for the exception. It will not be lost at some endpoint also. I believe this change should by put to 2.0 only as it might break someones exception handling completely, shouldn't it? This time I don't want to start flame about need for in/out messages once again, but... ;) Roman -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
Hi I am working on this now, to change it to CamelCase. I am adding xxxConstants classes to the component where we can put the constants for the key names. This allows end users to easy spot which keys we have. I decided for xxxConstants over Constants when end users work with multiple components and want to import Constants then there is a ambiguity. Hence the component prefix, eg. JmsConstants, HttpConstants And in the future we could merge them into a org.apache.camel.Constants or org.apache.camel.Keys class. In the core the keys are stored on the Exchange that William started with. We can later decide if we want a Constants class as well, or whatever. The values for the keys will be changed to use the new CamelCase syntax. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Data-driven routing
Hi
BTW: We might consider whit Camel 2.0 to add a sample for a real
dynamic router where you can create
the route in java code and start it for those that are using such thing.
This sample uses the dynamic recipient list that is not totally the same:
http://camel.apache.org/dynamic-router.html
On Fri, Feb 27, 2009 at 11:16 AM, James Strachan
james.strac...@gmail.com wrote:
2009/2/26 jbower1950 jim.bo...@gmail.com:
I have tried that approach. It was pretty intuitive and made sense. The
problem came when I had two routes from the same source (e.g., a log), one
portion of which I wanted to route to one topic, the other part going to
another topic. It appeared that, using the DSL with two routes, one message
would go to one route (and get resolved properly), then the next would go to
the next route (and not get resolved properly).
So, graphically:
Source 1 -- Xpath 1 -- Process A -- Sink 1
Source 1 -- Xpath 2 -- Process A -- Sink 2
It seemed that message 1 hit the first route and ended up in the right
place. Message 2, which should have been resolved by the first route, went
to the second route and did not proceed (no match on the xpath filter).
It depends a little on what the load balancing mechanism used inside
the endpoint.
For example if Source 1 was a JMS topic the above would work perfectly.
However the general case is going to be you want multiple filters to
be part of the same route.
If so just change your code to reuse the same route for the same
source string. e.g.
for (Foo foo : foos) {
String u = foo.getFromEndpointUri();
String xp = foo.getXPath();
Class type = foo.getBeanType(); // or processor type
getFromFor(u).
filter().xpath(xp).bean(type).
end(); // this is important to close the filter block!
}
...
/** returns the route for the given endpoint */
RouteType getFromFor(String endpoint) {
RouteType answer = routesMap.get(endpoint);
if (answer == null) {
answer = from(endpoint);
routesMap.put(endpoint, answer);
}
return answer;
}
basically you'd then the concatenating the routes together so all
filters on a single endpoint are part of the same route. So you'd be
doing in pseudo code...
from(source1).
filter().xpath(xpath1).bean(bean1).end().
filter().xpath(xpath2).bean(bean2).end().
etc
Another approach which is similar - but avoids issues if folks forget
the 'end()' and so is a little bit more rugged - is to treat each of
those routes as independent routes with their own URIs - then
separately chain them together in a separate route on the real
endpoint.
e.g.
public void configure() {
MultimapString,String uriMap = ...;
ListFoo foos = ... // some query
for (Foo foo : foos) {
String realUri = foo.getFromEndpointUri();
String xp = foo.getXPath();
Class type = foo.getBeanType(); // or processor type
// lets add a route from the uri and filter to the given
processor
String newUri = createNewUri(); // returns say direct:1234
from(newUri).filter().xpath(xp).bean(type);
// lets map the newUri to the real uri 'realUri'
multimap.put(realUri, newUri);
}
// now lets bind these routes to the real URIs...
for (EntryString,ListString entry : multimap.entries()) {
String realUri = entry.getKey();
ListString indiviualUris = entry.getValue();
from(realUri).to(indvidualUris);
}
}
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r748757 - /camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
On Sat, Feb 28, 2009 at 1:07 AM, hadr...@apache.org wrote:
Author: hadrian
Date: Sat Feb 28 00:07:13 2009
New Revision: 748757
URL: http://svn.apache.org/viewvc?rev=748757view=rev
Log:
Fix assertion to pass when a non-String value matches an expected String
value.
Modified:
camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
Modified:
camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
URL:
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java?rev=748757r1=748756r2=748757view=diff
==
---
camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
(original)
+++
camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
Sat Feb 28 00:07:13 2009
@@ -318,7 +318,7 @@
public void run() {
assertTrue(No header with name + headerName + found.,
actualHeader != null);
- assertEquals(Header of message, headerValue, actualHeader);
+ assertEquals(Header of message, headerValue,
actualHeader.toString());
What if the headerValue is Integer (if it can) dont you hit a
assertEquals(Object, Object) instead of (Integer, Integer)
Just wondering?
Maybe we can use Camels type converter to convert both values to a
String instead of .toString() ?
}
});
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Problems in implementing Loadbalance using ActiveMQ and Camel
Hi On Thu, Feb 26, 2009 at 11:05 PM, dasalav lavanya.das...@dowjones.com wrote: Hi My requirement is: i have an input queue of Active MQ 5.1. the messages keeps adding to it. These messages are to be consumed by 3 differerent consumers. But each consumer queue should have a limit to 2. If the consumer queue is full, the producer should stop sending messages to that queue and proceed with the others. I am trying to implement this functionality using round robin of Camel 1.5 like this. from(fromDest).loadBalance().roundRobin().to(loadbal1,loadbal2,loadbal3); Note: I haven't found any source to limit the size of consumer queue. Please help me. A consumer queue only allowing 2 elements is a really harsh SLA. Why cant it be higher? Whats the reason? You need some kind of producer to these queue that can try to put it, and if it fails it will try the next queue in a round robin fashion or some other algorithm. When you try today to put on a full queue do you get a rejection or does it block until there is room? I am wondering how this is supported by JMS. Have you tried asking at the ActiveMQ forum as well? Thanks in advance. -- View this message in context: http://www.nabble.com/Problems-in-implementing-Loadbalance-using-ActiveMQ-and-Camel-tp22234799p22234799.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 API - Proposal of new support package to fix bad tangles
Hi I am using Structure 101 to view the Camel API and have found some hot spots to clear. - DataFormatType was implementing DataFormat (fixed) - SPI had a bad tangle (fixed) - Language had a bad tangle (fixed) However we do have some support classes (abstract base classes) in camel.impl that are reused outside .impl. Currently its mostly the ExpressionAdapter to assist impl. Expression. I would like to propose a new package in Camel for such common classes. As the util package is a kinda mixed up package currently org.apache.camel.support And we can move: ExpressionAdapter ExpressionSupport PredicateSupport That are most likely to be used outside camel.impl in eg. processor, language, builder and other packages where Expression/Preidcates is also highly used. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
On Tue, Mar 3, 2009 at 2:26 PM, Willem Jiang willem.ji...@gmail.com wrote: Hi Claus If the ThreadContextClassLoader is the user's bundle's classloader, and the user bundle doesn't import the org.apache.camel.jms package. The ObjectHelper can't load the right DefaultQueueBrowseStrategy class by using the bundle's classlaoder. Ah got it. So by changing to the JMS class we know its gonna find it in camel-jms as its the same bundle as it self :) Willem Claus Ibsen wrote: On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang willem.ji...@gmail.com wrote: Hi, I think we should leverage the ThreadContextClassLoader to load the right class. Since OSGI has elegant mechanism to get control of the class's version and handle the relationship of the classes. I don't want to walk around this mechanism by looking over all the bundler's context for a class. But this was the problem with the JMS stuff. ObjectHelper.loadClass will use the ThredContextClassLoader first. So I can not see if that would work. Just my 2 cents. Willem. Claus Ibsen wrote: Hi In Camel we use ObjectHelper.loadClass to load classes on the fly. Could there be some issues with this in OSGi platforms? We got a report today with using camel-jms that tries to load a spring queue browser class on the fly. So we can support Spring 2.0 also as this class was introduced in Spring 2.5.x. I was wondering if we should add API for pluggable class resolvers? Eg. ClassResolver API in SPI and then a getter to it from CamelContext. Or is the ObjectHelper sufficient? Do you need to get hold of some bundle context to load classes in OSGi or is the regular class loading okay? Gertv, Willem you are the ones that are most into OSGi. You thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r749973 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/component/mock/ main/java/org/apache/camel/processor/interceptor/ test/java/org/apache/camel/component/mock/ test
) {
- TypeConverter tc =
exchange.getContext().getTypeConverterRegistry().lookup(StreamCache.class,
body.getClass());
- if (tc != null) {
- try {
- StreamCache newBody = tc.convertTo(StreamCache.class,
exchange, body);
- if (newBody != null) {
- exchange.getIn().setBody(newBody);
- }
- MessageHelper.resetStreamCache(exchange.getIn());
- } catch (NoTypeConversionAvailableException ex) {
- // ignore if in is not of StreamCache type
- }
+ try {
+ StreamCache newBody =
exchange.getIn().getBody(StreamCache.class);
+ if (newBody != null) {
+ exchange.getIn().setBody(newBody);
}
+ MessageHelper.resetStreamCache(exchange.getIn());
+ } catch (NoTypeConversionAvailableException ex) {
+ // ignore if in is not of StreamCache type
}
return proceed(exchange, callback);
}
- public boolean proceed(Exchange exchange, AsyncCallback callback) {
- if (getProcessor() instanceof AsyncProcessor) {
+ public boolean proceed(Exchange exchange, AsyncCallback callback) {
+ if (getProcessor() instanceof AsyncProcessor) {
return ((AsyncProcessor) getProcessor()).process(exchange,
callback);
} else {
try {
Modified:
camel/trunk/camel-core/src/test/java/org/apache/camel/component/mock/MockEndpointTest.java
URL:
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/component/mock/MockEndpointTest.java?rev=749973r1=749972r2=749973view=diff
==
---
camel/trunk/camel-core/src/test/java/org/apache/camel/component/mock/MockEndpointTest.java
(original)
+++
camel/trunk/camel-core/src/test/java/org/apache/camel/component/mock/MockEndpointTest.java
Wed Mar 4 12:06:11 2009
@@ -112,6 +112,8 @@
MockEndpoint resultEndpoint = getMockEndpoint(mock:result);
resultEndpoint.expectedMessageCount(6);
+ // wait at most 2 sec to speedup unit testing
+ resultEndpoint.setResultWaitTime(2000);
resultEndpoint.assertIsNotSatisfied();
}
@@ -141,7 +143,6 @@
resultEndpoint.assertIsSatisfied();
resultEndpoint.reset();
-
// assert failure when value is different
resultEndpoint.expectedHeaderReceived(header, value1);
sendHeader(header, value);
@@ -162,10 +163,21 @@
resultEndpoint.assertIsNotSatisfied();
}
+ public void testExpectationOfHeaderWithNumber() throws
InterruptedException {
+ MockEndpoint resultEndpoint = getMockEndpoint(mock:result);
+ resultEndpoint.reset();
+
+ // assert we can assert using other than string, eg numbers
+ resultEndpoint.expectedHeaderReceived(number, 123);
+ sendHeader(number, 123);
+ resultEndpoint.assertIsSatisfied();
+
+ resultEndpoint.assertIsNotSatisfied();
+ }
+
protected void sendMessages(int... counters) {
for (int counter : counters) {
- template.sendBodyAndHeader(direct:a,
createTestMessage(counter),
- counter, counter);
+ template.sendBodyAndHeader(direct:a,
createTestMessage(counter), counter, counter);
}
}
@@ -181,7 +193,7 @@
return list;
}
- protected void sendHeader(String name, String value) {
+ protected void sendHeader(String name, Object value) {
template.sendBodyAndHeader(direct:a, body, name, value);
}
Modified:
camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
URL:
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java?rev=749973r1=749972r2=749973view=diff
==
---
camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
(original)
+++
camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
Wed Mar 4 12:06:11 2009
@@ -38,6 +38,7 @@
MockEndpoint endpoint = getMockEndpoint(mock:results);
endpoint.expectedMessageCount((int) dataSet.getSize());
+ endpoint.expectedHeaderReceived(foo, 123);
assertMockEndpointsSatisfied();
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r750021 - in /camel/branches/camel-1.x: ./ camel-core/src/main/java/org/apache/camel/util/ components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/ compon
On Thu, Mar 5, 2009 at 2:10 AM, Willem Jiang willem.ji...@gmail.com wrote:
Hi Claus,
Since Camel 1.x doesn't support the onException, I'd like to revert the
SpringOnExceptionNotNormalizedClassNameTest part and keep the change of
ObjectHelper.
Ah I got it, the problem was that onexception did not exists as a
package name for unit testing 1.x.
Yeah that is fine to remove the unit tests. We have them in trunk.
The feature onException for error handling is of course also available
in Camel 1.x
Willem
davscl...@apache.org wrote:
Author: davsclaus
Date: Wed Mar 4 14:25:18 2009
New Revision: 750021
URL: http://svn.apache.org/viewvc?rev=750021view=rev
Log:
Merged revisions 750017 via svnmerge from
https://svn.apache.org/repos/asf/camel/trunk
r750017 | davsclaus | 2009-03-04 15:20:14 +0100 (Wed, 04 Mar 2009) | 1 line
CAMEL-1418: Normalizes class names before loading to avoid \n or other
chars by Spring DSL configuration with xml tags on newlines or hidden spaces
etc.
Added:
camel/branches/camel-1.x/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
- copied unchanged from r750017,
camel/trunk/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
camel/branches/camel-1.x/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
- copied unchanged from r750017,
camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
Modified:
camel/branches/camel-1.x/ (props changed)
camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
Propchange: camel/branches/camel-1.x/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Mar 4 14:25:18 2009
@@ -1 +1 @@
-/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956
+/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956,750017
Propchange: camel/branches/camel-1.x/
--
Binary property 'svnmerge-integrated' - no diff available.
Modified:
camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
URL:
http://svn.apache.org/viewvc/camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java?rev=750021r1=750020r2=750021view=diff
==
---
camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
(original)
+++
camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
Wed Mar 4 14:25:18 2009
@@ -478,6 +478,9 @@
* @return the class or null if it could not be loaded
*/
public static Class? loadClass(String name, ClassLoader loader) {
+ // must clean the name so its pure java name, eg remoing \n or
whatever people can do in the Spring XML
+ name = normalizeClassName(name);
+
// try context class loader first
Class clazz = doLoadClass(name,
Thread.currentThread().getContextClassLoader());
if (clazz == null) {
@@ -843,4 +846,23 @@
}
}
+ /**
+ * Cleans the string to pure java identifier so we can use it for
loading class names.
+ * p/
+ * Especially from Sping DSL people can have \n \t or other characters
that otherwise
+ * would result in ClassNotFoundException
+ *
+ * @param name the class name
+ * @return normalized classname that can be load by a class loader.
+ */
+ public static String normalizeClassName(String name) {
+ StringBuffer sb = new StringBuffer(name.length());
+ for (char ch : name.toCharArray()) {
+ if (ch == '.' || Character.isJavaIdentifierPart(ch)) {
+ sb.append(ch);
+ }
+ }
+ return sb.toString();
+ }
+
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel in Sonar
On Fri, Mar 6, 2009 at 2:49 PM, Jon Anstey jans...@gmail.com wrote: The Sonar guys were kind enough to add Camel to their public server. http://www.nabble.com/Re%3A-New-projects-in-public-sonar-instance--p22360333.html Take a peek at how well we do here http://nemo.sonar.codehaus.org/project/index/org.apache.camel:camel-parent Very cool Jon. I was about to suggest if we could get that in house at fuse. Very cool. -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel in Sonar
Hi Could you add a link to it somewhere, there is an existing page where Gert added the links to public hudson something with developer On Fri, Mar 6, 2009 at 3:13 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Mar 6, 2009 at 2:49 PM, Jon Anstey jans...@gmail.com wrote: The Sonar guys were kind enough to add Camel to their public server. http://www.nabble.com/Re%3A-New-projects-in-public-sonar-instance--p22360333.html Take a peek at how well we do here http://nemo.sonar.codehaus.org/project/index/org.apache.camel:camel-parent Very cool Jon. I was about to suggest if we could get that in house at fuse. Very cool. -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 API - Discuss - Exchange.getException() change to Exception
Hi The Exchange.getException() method is based on Throwable. I think this is wrong and we should change it to Exception. We should let the java.lang.Error left alone to the JDK itself to handle it, so end users cannot try .. catch(Throwable) and thus hide java.lang.OutOfMemoryError etc. The camel-core has this issue as well with catching Throwables around its code. It should only catch Exception. And I am prepareing a patch to fix this. Any objections to change it to Exception and fix the camel-core? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:39 AM, orton o_hu...@yahoo.com wrote:
Hi,
I've been trying to use the MINA component for UDP data delivery but have
been having some issues and was wondering if anyone else has seen this
error.
I'm sending small packets (100Bytes) as fast as I can (sequentially from a
single client) but after around 35,000 packets sent, the Camel client
abruptly stops without any errors/exceptions. I first tried this with the
1.6 release and saw this problem and recently downloaded and compiled the
2.0 core and components but still have the same issue. When I use MINA with
TCP, I don't have this problem...
Here's what I have for code:
-
public void init( String serverIP, int serverPort ) {
uri = mina:udp:// + serverIP + : + serverPort +
?sync=false;
System.out.println(Camel URI: + uri);
}
public void sendMessages(int numOfMessages, int messageSize) throws
Exception {
CamelContext context = new DefaultCamelContext();
context.start();
Endpoint endpoint = context.getEndpoint(uri);
Exchange exchange =
endpoint.createExchange(ExchangePattern.InOnly);
Producer producer = endpoint.createProducer();
producer.start();
for (int i = 0; i numOfMessages; i++) {
String s = [Publisher]: Test Body Message: + i;
exchange.getIn().setBody(s);
producer.process(exchange);
}
producer.stop();
}
I looked through various forums and saw some memory leak issues, but wasn't
sure if this is related?
If anyone can help, would be much appreciated!!
What version of Camel and Mina are you using?
Mina is in the works of doing a Mina 2.0 that might be much better.
When its release we will upgrade it in Camel 2.0 as well.
Yes the memory leaks is interresting? Where did you find them?
And whats the relevanse of you test? Sending 65.000 udp packages to yourself?
Are you using Camel to be the Mina server as well? Or do you send it
to another JVM?
Using TCP that works. Are you using the exact same sample but just
change udp to tcp in the endpoint URI?
Orton
--
View this message in context:
http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22426433.html
Sent from the Camel - Development (activemq) mailing list archive at
Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
Hi
I have commited a fix to UPD in camel-mina on both 1.6.1 and 2.0
https://issues.apache.org/activemq/browse/CAMEL-1444
Could you try it out on your system?
2.0-SNAPSHOT is automatic build and published at apache maven snapshot repo.
http://camel.apache.org/download.html
I cant remember if 1.6.1-SNAPSHOT also is, it kinda got lost on in TLP
move recently.
On Tue, Mar 10, 2009 at 11:24 AM, Claus Ibsen claus.ib...@gmail.com wrote:
BTW I think I have seen some UDP issue with camel-mina about
acquiring/releasing mina byte buffer.
Damm that API is not so easy to work with - should be improved in mina 2.0
So it could relate to your issue as well
On Tue, Mar 10, 2009 at 8:43 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Tue, Mar 10, 2009 at 2:39 AM, orton o_hu...@yahoo.com wrote:
Hi,
I've been trying to use the MINA component for UDP data delivery but have
been having some issues and was wondering if anyone else has seen this
error.
I'm sending small packets (100Bytes) as fast as I can (sequentially from a
single client) but after around 35,000 packets sent, the Camel client
abruptly stops without any errors/exceptions. I first tried this with the
1.6 release and saw this problem and recently downloaded and compiled the
2.0 core and components but still have the same issue. When I use MINA with
TCP, I don't have this problem...
Here's what I have for code:
-
public void init( String serverIP, int serverPort ) {
uri = mina:udp:// + serverIP + : + serverPort +
?sync=false;
System.out.println(Camel URI: + uri);
}
public void sendMessages(int numOfMessages, int messageSize) throws
Exception {
CamelContext context = new DefaultCamelContext();
context.start();
Endpoint endpoint = context.getEndpoint(uri);
Exchange exchange =
endpoint.createExchange(ExchangePattern.InOnly);
Producer producer = endpoint.createProducer();
producer.start();
for (int i = 0; i numOfMessages; i++) {
String s = [Publisher]: Test Body Message: + i;
exchange.getIn().setBody(s);
producer.process(exchange);
}
producer.stop();
}
I looked through various forums and saw some memory leak issues, but wasn't
sure if this is related?
If anyone can help, would be much appreciated!!
What version of Camel and Mina are you using?
Mina is in the works of doing a Mina 2.0 that might be much better.
When its release we will upgrade it in Camel 2.0 as well.
Yes the memory leaks is interresting? Where did you find them?
And whats the relevanse of you test? Sending 65.000 udp packages to yourself?
Are you using Camel to be the Mina server as well? Or do you send it
to another JVM?
Using TCP that works. Are you using the exact same sample but just
change udp to tcp in the endpoint URI?
Orton
--
View this message in context:
http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22426433.html
Sent from the Camel - Development (activemq) mailing list archive at
Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:19 PM, orton o_hu...@yahoo.com wrote: What version of Camel and Mina are you using? I tried it out on the Camel 1.6 bin release and I compiled the Camel 2.0 snapshot in svn and both appeared to have the same problem... mina-core for both appear to be 1.1.7 Mina is in the works of doing a Mina 2.0 that might be much better. When its release we will upgrade it in Camel 2.0 as well. Yes the memory leaks is interresting? Where did you find them? I only saw some references in past forums and some of my co-workers have mentioned them to me also, will look for more details and send to you And whats the relevanse of you test? Sending 65.000 udp packages to yourself? Are you using Camel to be the Mina server as well? Or do you send it to another JVM? We're trying to do some simple stress and overhead testing on the Camel components... We really like what you guys have done with it and find the patterns extremely useful. We want to see how suitable it is for applications with high throughput, low latency needs and what the extra cost for using Camel is. I have separate servers in different VM's but on the same host for now. Using TCP that works. Are you using the exact same sample but just change udp to tcp in the endpoint URI? I send the exact same samples with UDP and TCP... Just tried the multicast one and it gives me the same issue as the UDP one... Thanks for the info. Have you seen my mails about commit a fix? Could you try again with a version of Camel that has the fix build. The problem would probably not manifest itself if you use 2 separate JVM's - 1 for server, 1 for client -- View this message in context: http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22434032.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Discuss - Exchange.getException() change to Exception
Committed revision 752465. On Wed, Mar 11, 2009 at 12:58 PM, James Strachan james.strac...@gmail.com wrote: 2009/3/11 Claus Ibsen claus.ib...@gmail.com: On Wed, Mar 11, 2009 at 12:20 PM, James Strachan james.strac...@gmail.com wrote: 2009/3/10 Claus Ibsen claus.ib...@gmail.com: Hi The Exchange.getException() method is based on Throwable. I think this is wrong and we should change it to Exception. We should let the java.lang.Error left alone to the JDK itself to handle it, so end users cannot try .. catch(Throwable) and thus hide java.lang.OutOfMemoryError etc. The camel-core has this issue as well with catching Throwables around its code. It should only catch Exception. And I am prepareing a patch to fix this. Any objections to change it to Exception and fix the camel-core? Sounds fine to me. So long as we can catch programming bugs (e.g. NullPointerException in some custom processor code) that should be fine. ? NPE is a RuntimeException so it would be just as it always have been. Its just that we let java.lang.Error to the JDK itself, so when it reports OutOfMemoryError, and that infinite stack trace error and what else then Camel do NOT catch it. Yes - sorry thats what I meant. That checked runtime exceptions should be catchable - but errors like OOM shouldnt. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
Hi Just for the good sake. We have identified an issue and fixed it in camel-mina on trunk. Thanks to Orton for providing a sample case that surfaced the issue. Now it works like a charm and doesnt stall using UDP. On Wed, Mar 11, 2009 at 10:05 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Can you create a zip with a sample project that demonstrates this issue? I would like to take a look. Its interresting that creating a new producer once in a while resolves it. eg you get a brand new MINA session to work with. On Tue, Mar 10, 2009 at 8:01 PM, orton o_hu...@yahoo.com wrote: One more thing... Right now, I'm just catching all Exceptions and printing them out. When the component stops sending, usually no exceptions are thrown... Not sure if they are getting swallowed up somewhere lower. However, one time I ran it, for some reason I did get this: Exception caught: Could not write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] org.apache.camel.CamelExchangeException: Could not write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] at org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:47) at org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) at edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) at edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:84) -- View this message in context: http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22441278.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Thu, Mar 12, 2009 at 5:31 PM, orton o_hu...@yahoo.com wrote: Hi Again, Thanks Claus for the fix! That resolved the issue I was having with the MINA sender and I can run it a lot longer. Unfortunately :( however, I get this problem now after many more messages: Messages Sent: [Publisher]: Test Body Message: 2366999 Messages Sent: [Publisher]: Test Body Message: 2367999 Messages Sent: [Publisher]: Test Body Message: 2368999 Exception caught: Cannot write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 2369836] org.apache.camel.CamelExchangeException: Cannot write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 2369836] at org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:52) at org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) at edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) at edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:133) In this case, I'm sending 30 Byte messages one after another as fast as I can and it gets to 2.3 million messages or so. I'm not sure if I'm running out of memory (perhaps the garbage collection is cleaning up things fast enough)? Thoughts? Thanks again! You should just catch the exception and continue with sending. It should be able to send the rest. Eg you can do a retry to send it again. You are using UDP so the QoS is not as high as TCP. Claus Ibsen-2 wrote: Hi Just for the good sake. We have identified an issue and fixed it in camel-mina on trunk. Thanks to Orton for providing a sample case that surfaced the issue. Now it works like a charm and doesnt stall using UDP. On Wed, Mar 11, 2009 at 10:05 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Can you create a zip with a sample project that demonstrates this issue? I would like to take a look. Its interresting that creating a new producer once in a while resolves it. eg you get a brand new MINA session to work with. On Tue, Mar 10, 2009 at 8:01 PM, orton o_hu...@yahoo.com wrote: One more thing... Right now, I'm just catching all Exceptions and printing them out. When the component stops sending, usually no exceptions are thrown... Not sure if they are getting swallowed up somewhere lower. However, one time I ran it, for some reason I did get this: Exception caught: Could not write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] org.apache.camel.CamelExchangeException: Could not write body on the exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] at org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:47) at org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) at edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) at edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:84) -- View this message in context: http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22441278.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- View this message in context: http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22479515.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [CONF] Apache Camel: Stream caching (page created)
Gert
Do you mind documenting how it can be configured in Spring XML also?
And please add a link to it from [Dead Letter Channel], in see also
and maybe a little {tip:}
On Thu, Mar 12, 2009 at 10:21 PM, conflue...@apache.org wrote:
Page Created : CAMEL : Stream caching
Stream caching has been created by Gert Vanthienen (Mar 12, 2009).
Content:
Stream caching
While stream types (like StreamSource, InputStream and Reader) are commonly
used in messaging for performance reasons, they also have an important
drawback: they can only be read once. In order to be able to work with
message content multiple times, the stream needs to be cached.
By default, streams are caching in memory. In Camel 2.0, large stream
messages (over 64 Kb) will be cached in a temporary file instead – Camel
itself will handle deleting the temporary file once the cached stream is no
longer necessary.
Using stream caching
Implicitly enabled for multicast and dead letter channel
Some EIPs require that the message content can be read multiple times.
Stream caching will be automatically enabled when using these EIPs in your
routes:
Multicast will implicitly cache streams to ensure that all the endpoints can
access the message content
Dead Letter Channel uses stream caching to ensure that the message content
can actually be read again when redelivering a message
Explicitly configure stream caching
In Apache Camel, you can explicitly enable stream caching in a route with
the streamCaching DSL method:
from(direct:a).streamCaching().to(mock:a);
You can also enable it for all the routes in routebuilder:
streamCaching();
from(direct:b).to(mock:b);
How it works?
In order to determine if a type requires caching, we leverage the type
converter feature. Any type that requires stream caching can be converted
into an org.apache.camel.StreamCache instance.
Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) -
Bug/feature request
Unsubscribe or edit your notifications preferences
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [VOTE] Release Apache Camel 2.0-M1
+1 On Thu, Mar 12, 2009 at 10:53 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Resending to the right list. Sorry for the duplicate post. Hadrian On Mar 12, 2009, at 5:51 PM, Hadrian Zbarcea wrote: The first milestone build of Camel 2.0, apache-camel-2.0-M1, is out with an absolute record 368 new features, improvements and bug fixes. With the exception of very late additions that we'll iron out in the next release 2.0-M1 is impressively stable. Most of the API changes from the 1.x line are already made, so we do not anticipate significant API changes on the 2.x line from here on. Please find the distro here: http://people.apache.org/~hadrian/apache-camel-2.0-M1/maven2/ The tarballs are here http://people.apache.org/~hadrian/apache-camel-2.0-M1/maven2/org/apache/camel/apache-camel/2.0-M1/ Please vote to approve this release binary. While only the PMC votes are binding we encourage all community members to try it out and cast their vote. Your opinion is highly valued and appreciated! [ ] +1 Release the binary as Apache Camel 2.0-M1 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Proposal of new support package to fix bad tangles
On Fri, Mar 13, 2009 at 12:22 PM, James Strachan james.strac...@gmail.com wrote: Cool - I was gonna suggest putting some of the adapter classes into the SPI package as a place for folks extending Camel to put things? No biggie though, seems the issue is resolved now. Yeah they are in util now. Not the best home I think. But the response didnt come in, in fact one wasnt in favor of a new package. However I would still consider a support package for Camel related types. And a plain util for JDK core type helpers, such as String manipulation, File IO, and whatelse. 2009/3/8 Claus Ibsen claus.ib...@gmail.com: Hi I fixed the package tangle so we keep the current package structure as is. On Mon, Mar 2, 2009 at 6:42 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi I am using Structure 101 to view the Camel API and have found some hot spots to clear. - DataFormatType was implementing DataFormat (fixed) - SPI had a bad tangle (fixed) - Language had a bad tangle (fixed) However we do have some support classes (abstract base classes) in camel.impl that are reused outside .impl. Currently its mostly the ExpressionAdapter to assist impl. Expression. I would like to propose a new package in Camel for such common classes. As the util package is a kinda mixed up package currently org.apache.camel.support And we can move: ExpressionAdapter ExpressionSupport PredicateSupport That are most likely to be used outside camel.impl in eg. processor, language, builder and other packages where Expression/Preidcates is also highly used. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 - About type converter degrade performance issue
Hi In Camel 1.6.0 and 2.0 we have had a performance issue that could seriously degrade performance by x2-x10 when you did stress test by sending 1000 msg/sec. The cause of this is the TypeConverter that will throw a NoSuchTypeConverterExists when Camel cannot converter to the desired type. We do this internally in Camel in some areas of the code where we will ignore this exception and eg. continue. We did a fix for this performance issue in the stream cache but this was just a fix in once place. Lately this issue surfaced again in camel-mina when using UDP. So I have been experimenting with doing a fix once for all. I suggest to: - add 2 new methods to TypeConverter that returns *null* instread of throwing the NoSuchTypeConverterExists exception. I have named them: tryConvertTo. But maybe there is a better name? - add 1 new method on Message to get the body using the try convert to instead. I have named the method: tryGetBody(T). But maybe there is a better name? - Use tryGetBody internally in Camel where we today do try .. catch(NoSuchTypeConverterExists) - Then we can expose the regular getBody(T) for the end users, and let it act as it does today by throwing the exception - We can also optimize the DefaultTypeConverter to let it look in the miss cache first if it have tried to convert this before but could not If the tryGetBody, tryConvertTo are you to your liking we can also do: - add a new method to TypeConvert: boolean canConvertTo(T, value) - add a new method to Message: boolean canGetBody(T, value) - then use that method as guard before doing the regular convertTo/getBody But this requires that you always use this as guard, to be sure that the NoSuchTypeConverterExists is not thrown And it also requires that we use the miss cache to not do 2x convertions, 1 for the boolean check, and then 1 for the actual convertion It also requires that the body can be converted multiple times. Whether solution 1 or 2 we also need to check the other components and fix it internally as well, so we dont have a situation like mina with UDP that was affected by the performance drawback. In my experiment I have the first solution up and running. Any thoughts? I will create a JIRA ticket for this one as well so we wont forget it. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel - JMXConnector Thread
Hi
I was working on CAMEL-1462 and I was wondering why the
JMXConnectorThread created in
DefaultInstrumentationAgent#createJmxConnector is not set as daemon?
eg in the code below there should be a: connector.setDaemon(true)
// Start the connector server asynchronously (in a separate thread).
Thread connectorThread = new Thread() {
public void run() {
try {
cs.start();
} catch (IOException ioe) {
LOG.warn(Could not start JMXConnector thread., ioe);
}
}
};
connectorThread.setName(Camel JMX Connector Thread [ + url + ]);
connectorThread.start();
LOG.info(JMX Connector thread started and listening at: + url);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel - JMXConnector Thread
Hi
Another minor note.
We might wanna make sure the threads we create in Camel is using the
same API so end users can be 100% in control of thread creation.
Eg in WebSphere to use its WorkManager API to control threads.
So maybe some ExectutorService is needed as well? Just wondering /
thinking loud.
On Tue, Mar 17, 2009 at 10:24 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
I was working on CAMEL-1462 and I was wondering why the
JMXConnectorThread created in
DefaultInstrumentationAgent#createJmxConnector is not set as daemon?
eg in the code below there should be a: connector.setDaemon(true)
// Start the connector server asynchronously (in a separate thread).
Thread connectorThread = new Thread() {
public void run() {
try {
cs.start();
} catch (IOException ioe) {
LOG.warn(Could not start JMXConnector thread., ioe);
}
}
};
connectorThread.setName(Camel JMX Connector Thread [ + url + ]);
connectorThread.start();
LOG.info(JMX Connector thread started and listening at: + url);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel - JMXConnector Thread
On Tue, Mar 17, 2009 at 10:44 AM, Willem Jiang willem.ji...@gmail.com wrote:
+1 for using the Executor to support the managed thread.
Hi
I have fixed this now and will commit a fix in short time on trunk.
Willem
Claus Ibsen wrote:
Hi
Another minor note.
We might wanna make sure the threads we create in Camel is using the
same API so end users can be 100% in control of thread creation.
Eg in WebSphere to use its WorkManager API to control threads.
So maybe some ExectutorService is needed as well? Just wondering /
thinking loud.
On Tue, Mar 17, 2009 at 10:24 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
I was working on CAMEL-1462 and I was wondering why the
JMXConnectorThread created in
DefaultInstrumentationAgent#createJmxConnector is not set as daemon?
eg in the code below there should be a: connector.setDaemon(true)
// Start the connector server asynchronously (in a separate thread).
Thread connectorThread = new Thread() {
public void run() {
try {
cs.start();
} catch (IOException ioe) {
LOG.warn(Could not start JMXConnector thread., ioe);
}
}
};
connectorThread.setName(Camel JMX Connector Thread [ + url + ]);
connectorThread.start();
LOG.info(JMX Connector thread started and listening at: + url);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - About type converter degrade performance issue
Hi Could you test on the SMX side? We have changed how the getBody(Class type) behaves. Now it returns null if it cannot convert. You should use the getMandatoryBody(Class type) instead if you want to be sure the payload can be converted. Maybe it affects the camel-jbi component in SMX. On Thu, Mar 19, 2009 at 10:37 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi I had a chat with James about it, and we came to a conclusion. See the JIRA for summary. I am running final unit tests now on the change. Will commit later today if all passes. On Wed, Mar 18, 2009 at 2:53 PM, William Tam email.w...@gmail.com wrote: +1 on overloading methods. On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Any thoughts on this one? It all boils down to a suggestion to add 1 methods to the org.apache.camel.Message API new method: - tryGetBody(Class type) or overload existing with a boolean to indicate ignore exception and return null - getBody(Class, true) The same applies for the org.apache.camel.spi.TypeConverter interface as we need a method on the line as above new method: - tryConvertTo(Class type) or overload existing with a boolean to indicate ignore exception and return null - convertTo(Class, true) The boolean thing is maybe a nice one as it have the same method name. On Mon, Mar 16, 2009 at 7:32 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi In Camel 1.6.0 and 2.0 we have had a performance issue that could seriously degrade performance by x2-x10 when you did stress test by sending 1000 msg/sec. The cause of this is the TypeConverter that will throw a NoSuchTypeConverterExists when Camel cannot converter to the desired type. We do this internally in Camel in some areas of the code where we will ignore this exception and eg. continue. We did a fix for this performance issue in the stream cache but this was just a fix in once place. Lately this issue surfaced again in camel-mina when using UDP. So I have been experimenting with doing a fix once for all. I suggest to: - add 2 new methods to TypeConverter that returns *null* instread of throwing the NoSuchTypeConverterExists exception. I have named them: tryConvertTo. But maybe there is a better name? - add 1 new method on Message to get the body using the try convert to instead. I have named the method: tryGetBody(T). But maybe there is a better name? - Use tryGetBody internally in Camel where we today do try .. catch(NoSuchTypeConverterExists) - Then we can expose the regular getBody(T) for the end users, and let it act as it does today by throwing the exception - We can also optimize the DefaultTypeConverter to let it look in the miss cache first if it have tried to convert this before but could not If the tryGetBody, tryConvertTo are you to your liking we can also do: - add a new method to TypeConvert: boolean canConvertTo(T, value) - add a new method to Message: boolean canGetBody(T, value) - then use that method as guard before doing the regular convertTo/getBody But this requires that you always use this as guard, to be sure that the NoSuchTypeConverterExists is not thrown And it also requires that we use the miss cache to not do 2x convertions, 1 for the boolean check, and then 1 for the actual convertion It also requires that the body can be converted multiple times. Whether solution 1 or 2 we also need to check the other components and fix it internally as well, so we dont have a situation like mina with UDP that was affected by the performance drawback. In my experiment I have the first solution up and running. Any thoughts? I will create a JIRA ticket for this one as well so we wont forget it. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel/XMPP 1.6/2.0 - OutOfMemoryError: Java heap space
On Thu, Mar 19, 2009 at 4:20 PM, orton o_hu...@yahoo.com wrote:
Heard from a co-worker:
When you send a message to the XMPP server (in this case, OpenFire) it sends
a copy back to you and that message has to be dispatched or the queue on the
client side will grow and eventually blow up. So it seems that its necessary
to call muc.nextMessage().
I did a quick mod to the Camel 2.0 XMPP component and added the
nextMessage() call to try it out and it does appear to work without throwing
the OOM exception.
In XmppGroupChatProducer:
public void process(Exchange exchange) {
...
}
try {
chat.sendMessage(message);
chat.nextMessage();
} catch (XMPPException e) {
throw new RuntimeXmppException(e);
}
}
Same thing prolly has to be done for the XmppPrivateChatProducer
Is this something you can add into the baseline code James?
Hi
Excellent. Can you create a ticket in JIRA, then we have a track
record of the changes in Camel
http://camel.apache.org/support.html
Thanks!
orton wrote:
Hi James,
I haven't had a chance to use JProbe yet, but will attempt that later
today
A few things I noticed were:
The Smack 3.0.4 client has a history of memory issues and there were
several threads on the Ignite forums regarding the memory issues. I did
some testing on my own on the Smack client and if I simply do continuous
muc.sendMessages, then I run into Out of Memory exceptions. Someone
suggested doing a muc.nextMessage() (which is basically a pull on the muc
room) after the sendMessage and that actually prevents the OOM error (it
also reduces the efficiency by quite a bit). I'll try with the Smack 3.1.0
libraries but I believe the issue still persists in the latest version.
Though not a permanent fix, it might be useful until Ignite fixes all the
OOM issues with the Smack clients.
Here are some references to the OOM errors at Ignite:
http://www.igniterealtime.org/community/message/189102
James.Strachan wrote:
Running your app using a profiler (either the one in the JDK or JProbe
or something) would provide useful diagnostics as to what's hogging
all the RAM - is it the Smack client or something in Camel.
2009/3/17 orton o_hu...@yahoo.com:
Ran some more tests with more memory for the publisher and subscriber,
and it
still runs out of memory. If I give the the sending and receiving JVM
each
-Xms256M -Xmx512M -Xmn40M
It runs out of memory at around 54000 4KB messages sent and received.
Doubling the memory causes it to die around 102000 4KB messages sent and
received
Any help would be greatly appreciated! Thanks...
--
View this message in context:
http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22562234.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--
View this message in context:
http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22601446.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - About type converter degrade performance issue
On Thu, Mar 19, 2009 at 4:09 PM, Willem Jiang willem.ji...@gmail.com wrote: Hi Claus, Current servicemix-camel component is still using Camel 1.x. I just went through the code and found that camel-jbi component uses the ExchangeHelper.convertToType() to covert the camel message body into a Source object for JBI to use. I think it is OK for this change. Good. ExchangeHelper.convertToType() will *now* return null if the conversion was not possible. So there are no more exceptions thrown. If you need to conversion to succeed, then you can use convertToMandatoryType() that will throw NoTypeConversionAvailableException willem Claus Ibsen wrote: Hi Could you test on the SMX side? We have changed how the getBody(Class type) behaves. Now it returns null if it cannot convert. You should use the getMandatoryBody(Class type) instead if you want to be sure the payload can be converted. Maybe it affects the camel-jbi component in SMX. On Thu, Mar 19, 2009 at 10:37 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi I had a chat with James about it, and we came to a conclusion. See the JIRA for summary. I am running final unit tests now on the change. Will commit later today if all passes. On Wed, Mar 18, 2009 at 2:53 PM, William Tam email.w...@gmail.com wrote: +1 on overloading methods. On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Any thoughts on this one? It all boils down to a suggestion to add 1 methods to the org.apache.camel.Message API new method: - tryGetBody(Class type) or overload existing with a boolean to indicate ignore exception and return null - getBody(Class, true) The same applies for the org.apache.camel.spi.TypeConverter interface as we need a method on the line as above new method: - tryConvertTo(Class type) or overload existing with a boolean to indicate ignore exception and return null - convertTo(Class, true) The boolean thing is maybe a nice one as it have the same method name. On Mon, Mar 16, 2009 at 7:32 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi In Camel 1.6.0 and 2.0 we have had a performance issue that could seriously degrade performance by x2-x10 when you did stress test by sending 1000 msg/sec. The cause of this is the TypeConverter that will throw a NoSuchTypeConverterExists when Camel cannot converter to the desired type. We do this internally in Camel in some areas of the code where we will ignore this exception and eg. continue. We did a fix for this performance issue in the stream cache but this was just a fix in once place. Lately this issue surfaced again in camel-mina when using UDP. So I have been experimenting with doing a fix once for all. I suggest to: - add 2 new methods to TypeConverter that returns *null* instread of throwing the NoSuchTypeConverterExists exception. I have named them: tryConvertTo. But maybe there is a better name? - add 1 new method on Message to get the body using the try convert to instead. I have named the method: tryGetBody(T). But maybe there is a better name? - Use tryGetBody internally in Camel where we today do try .. catch(NoSuchTypeConverterExists) - Then we can expose the regular getBody(T) for the end users, and let it act as it does today by throwing the exception - We can also optimize the DefaultTypeConverter to let it look in the miss cache first if it have tried to convert this before but could not If the tryGetBody, tryConvertTo are you to your liking we can also do: - add a new method to TypeConvert: boolean canConvertTo(T, value) - add a new method to Message: boolean canGetBody(T, value) - then use that method as guard before doing the regular convertTo/getBody But this requires that you always use this as guard, to be sure that the NoSuchTypeConverterExists is not thrown And it also requires that we use the miss cache to not do 2x convertions, 1 for the boolean check, and then 1 for the actual convertion It also requires that the body can be converted multiple times. Whether solution 1 or 2 we also need to check the other components and fix it internally as well, so we dont have a situation like mina with UDP that was affected by the performance drawback. In my experiment I have the first solution up and running. Any thoughts? I will create a JIRA ticket for this one as well so we wont forget it. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Building camel failing
On Mon, Mar 23, 2009 at 11:56 AM, Gary Jones activ...@garydjones.name wrote: On Mon, Mar 23, 2009 at 10:14:26AM +, James Strachan wrote: Any idea which directory you were in when this failure occurred? The top level project directory, i.e. the one containing the README.txt file and so forth. Also which maven version are you using? Maven version: 2.0.10 Java version: 1.5.0_12 OS name: windows xp version: 5.1 arch: x86 Family: windows Willem Jiang is also a Camel committer and he uses Windows XP. Can you try with Maven 2.0.9? That is what we use for building the release. 2009/3/23 Gary Jones activ...@garydjones.name: I tried to build camel based on the latest source from svn, and it failed. Following the instructions on the website I eventually got to (note: -e is my own addition, hoping to get some more info about the problem): mvn -e -Dtest=false clean install [...many lines of output...] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - invalid flag: -author Command line was:C:\Programme\Develop\Java\1.5se\jre\..\bin\javadoc.exe -J-Xmx500m @options -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Need Camel Wiki edit karma
On Mon, Mar 23, 2009 at 7:31 PM, Marat Bedretdinov marat.bedretdi...@gmail.com wrote: Claus, Could you give me Camel wiki edit karma so that I can document my latest patch? What is your username on the wiki? The search is really slow and can timeout if we search on name etc. Thanks, Marat -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] Snapshot deploy from Hudson to Nexus
+1 Would that apply for both Camel 1.x and trunk? AFAIR we don't have SNAPSHOT builds of 1.x published any more, requested by end users to be published again. On Mon, Mar 23, 2009 at 8:52 PM, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., Right now, we have two build servers: - Camel builds for deploying nightly snapshots are running on http://projects.open.iona.com/builds/status - Camel builds are running fine on hudson.zones.apache.org for a few weeks now Apache also has a Nexus repository manager installed at http://repository.apache.org now. I'd like to start deploying our SNAPSHOTs to this repository from Hudson directly instead of using the separate build server. In the future, we should also be able to leverage Nexus for the release process as well, i.e. deploy the artifacts under vote to a Nexus staging repo and then just promote the artifacts into the release repo after teh vote. The major downside would be that the repository url for snapshots would change from http://people.apache.org/repo/m2-snapshot-repository/ to https://repository.apache.org/content/repositories/snapshots. Regards, 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/
Re: Camel Article
Hi Jon A great article. I guess the images for figure 1 and 2 will be fixed to display. At least they weren't displayed on my Safari browser this morning. BTW: I guess Charles will be commeting on that his bindy component can do CSV-POJO mapping. So the CSV-List-Object example can be easier in the future, eg. like the JAXB counter example, with @annotations in your POJO. On Mon, Mar 23, 2009 at 8:42 PM, Jon Anstey jans...@gmail.com wrote: I recently wrote up an article on Apache Camel for DZone. Check it out if you're interested! http://architects.dzone.com/articles/apache-camel-integration -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel Article
Hi Jon You should add a link to the article on the articles wiki page. On Mon, Mar 23, 2009 at 8:42 PM, Jon Anstey jans...@gmail.com wrote: I recently wrote up an article on Apache Camel for DZone. Check it out if you're interested! http://architects.dzone.com/articles/apache-camel-integration -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Building camel failing
Hi Thanks for reporting back. I added the note about 2.0.9 is currently used. On Tue, Mar 24, 2009 at 10:41 AM, Gary Jones activ...@garydjones.name wrote: On Mon, Mar 23, 2009 at 12:02:08PM +0100, Claus Ibsen wrote: On Mon, Mar 23, 2009 at 11:56 AM, Gary Jones wrote: On Mon, Mar 23, 2009 at 10:14:26AM +, James Strachan wrote: which maven version are you using? Maven version: 2.0.10 Java version: 1.5.0_12 OS name: windows xp version: 5.1 arch: x86 Family: windows Willem Jiang is also a Camel committer and he uses Windows XP. Can you try with Maven 2.0.9? That is what we use for building the release. That seems to be the cause of it :-( It's working for me now (i.e. with maven 2.0.9), so it looks like either maven introduced a bug in 2.0.10 or there is something in the Camel build process that relied on previously incorrect behaviour in 2.0.9. Might be worth mentioning in the build instructions on the website that it requires maven 2.0.9 at the moment, not the latest version. Thanks for your help, all. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Thu, Mar 26, 2009 at 3:10 AM, orton o_hu...@yahoo.com wrote: Hi Claus, Some of my co-workers have been trying to use the 1.6.1 MINA component and had some of the same issues as we had with 2.0 with regards to the component stopping after some number of consecutive messages. I was wondering (hoping) if the fix would be applied to 1.6.1 also? I just pulled 1.6.1 off the 1.x branch and it didn't appear to have the fix... Hi Can you try again. I have just committed a fix on the 1.6.1 also. And please report back if it works. Thanks! - Hi Just for the good sake. We have identified an issue and fixed it in camel-mina on trunk. Thanks to Orton for providing a sample case that surfaced the issue. Now it works like a charm and doesnt stall using UDP. -- View this message in context: http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22714860.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Camel/XMPP 1.6/2.0 - OutOfMemoryError: Java heap space
Hi Orton
Thanks for reporting again.
I have fixed it on trunk and 1.x
On Thu, Mar 26, 2009 at 7:14 PM, orton o_hu...@yahoo.com wrote:
Hi Claus/XMPP Component Developers,
Soo... the XMPP consumer runs out of memory also, unfortunately. Was doing a
stand alone consumer test and just found this out. I'm not sure what the
best way to handle it is, but I did try this and it works:
In the xmpp component, XmppConsumer.java, you have to call muc.nextMessage()
also (this is surprising, and I'm not sure why it has to be done on the
consumer side, but it works)
Here's my processPacket()
public void processPacket(Packet packet) {
Message message = (Message)packet;
if (LOG.isDebugEnabled()) {
LOG.debug(Recieved XMPP message: + message.getBody());
}
XmppExchange exchange = endpoint.createExchange(message);
try {
getProcessor().process(exchange);
muc.nextMessage(); // -- line added here. not sure if this
is the best place to call it, but it seems to work here
} catch (Exception e) {
LOG.error(Error while processing XMPP message, e);
}
}
Is it possible to put this into the 1.6.1 and 2.0 codebase?
Claus Ibsen-2 wrote:
On Thu, Mar 19, 2009 at 4:20 PM, orton o_hu...@yahoo.com wrote:
Heard from a co-worker:
When you send a message to the XMPP server (in this case, OpenFire) it
sends
a copy back to you and that message has to be dispatched or the queue on
the
client side will grow and eventually blow up. So it seems that its
necessary
to call muc.nextMessage().
I did a quick mod to the Camel 2.0 XMPP component and added the
nextMessage() call to try it out and it does appear to work without
throwing
the OOM exception.
In XmppGroupChatProducer:
public void process(Exchange exchange) {
...
}
try {
chat.sendMessage(message);
chat.nextMessage();
} catch (XMPPException e) {
throw new RuntimeXmppException(e);
}
}
Same thing prolly has to be done for the XmppPrivateChatProducer
Is this something you can add into the baseline code James?
Hi
Excellent. Can you create a ticket in JIRA, then we have a track
record of the changes in Camel
http://camel.apache.org/support.html
Thanks!
orton wrote:
Hi James,
I haven't had a chance to use JProbe yet, but will attempt that later
today
A few things I noticed were:
The Smack 3.0.4 client has a history of memory issues and there were
several threads on the Ignite forums regarding the memory issues. I did
some testing on my own on the Smack client and if I simply do continuous
muc.sendMessages, then I run into Out of Memory exceptions. Someone
suggested doing a muc.nextMessage() (which is basically a pull on the
muc
room) after the sendMessage and that actually prevents the OOM error (it
also reduces the efficiency by quite a bit). I'll try with the Smack
3.1.0
libraries but I believe the issue still persists in the latest version.
Though not a permanent fix, it might be useful until Ignite fixes all
the
OOM issues with the Smack clients.
Here are some references to the OOM errors at Ignite:
http://www.igniterealtime.org/community/message/189102
James.Strachan wrote:
Running your app using a profiler (either the one in the JDK or JProbe
or something) would provide useful diagnostics as to what's hogging
all the RAM - is it the Smack client or something in Camel.
2009/3/17 orton o_hu...@yahoo.com:
Ran some more tests with more memory for the publisher and subscriber,
and it
still runs out of memory. If I give the the sending and receiving JVM
each
-Xms256M -Xmx512M -Xmn40M
It runs out of memory at around 54000 4KB messages sent and received.
Doubling the memory causes it to die around 102000 4KB messages sent
and
received
Any help would be greatly appreciated! Thanks...
--
View this message in context:
http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22562234.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--
View this message in context:
http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22601446.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
View this message in context:
http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22727911.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [jira] Commented: (CAMEL-1499) LDAP documentation could be improved
On Mon, Mar 30, 2009 at 9:14 AM, huntc hu...@mac.com wrote: Please may I receive some karma then so that I can update the wiki pages. :working: Karma granted -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28CAMEL-1499%29-LDAP-documentation-could-be-improved-tp22766622p22777494.html Sent from the Camel Development mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
[DISCUSS] - Default error handler in Camel 2.0, what should we do?
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 btw: is the download wiki page at Camel updated if anyone needs to add http://repository.apache.org to be able to find the SNAPSHOTS of 1.x and 2.0? People are looking for the 1.6.1-SNAPSHOTS and would be great to just point to the download wiki page. On Tue, Mar 31, 2009 at 8:43 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: 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/ -- 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?
On Wed, Apr 1, 2009 at 6:40 AM, Willem Jiang willem.ji...@gmail.com wrote: +1 for 1) and 3). We need to find a better way to handle the TX with Spring by default. For the TX part people would like the *onException* feature to be possible as well. We have this kind of trick where you can use the DLC and let the TX be required by default, if you dont add the policy(required). What is needed though is that the onExcpetion is also integrated with the transactionErrorHandler. That would allow people to eg catch validation exceptions in TX routes and route these to another endpoint and eg dont rollback as this might be OK. Willem Claus Ibsen wrote: 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 Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
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: [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
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Hi The default error handler is now changed in Camel 2.0. On Wed, Apr 1, 2009 at 11:58 AM, Claus Ibsen claus.ib...@gmail.com wrote: 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 -- 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: CAMEL 2.0 - The remaining work
Hi Just an updated #1: DONE #3: DefaultErrorHandler = DONE On Thu, Apr 2, 2009 at 7:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: 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 -- 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: CAMEL 2.0 - The remaining work
On Fri, Apr 3, 2009 at 3:07 PM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Just an updated #1: DONE #3: DefaultErrorHandler = DONE #3: TransactionErrorHandler = DONE #3: DONE On Thu, Apr 2, 2009 at 7:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: 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 -- 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 -- 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] - Camel 2.0 - Easier Camel Spring Transaction configuration
Hi Latest progress now is that I have introduced the *transacted* DSL keyword in both Java DSL and Spring DSL. Its capable of auto lookup in the registry for the transaction policy so no need to wire it. For instance in this Spring XML route from uri=direct:okay/ transacted/ setBody constantTiger in Action/constant /setBody bean ref=bookService/ setBody constantElephant in Action/constant /setBody bean ref=bookService/ /route The transacted/ will look for beans of type org.apache.camel.spi.TransactedPolicy that you define in the XML like this !-- policy for required transaction used in our Camel routes -- bean id=PROPAGATION_REQUIRED class=org.apache.camel.spring.spi.SpringTransactionPolicy property name=transactionManager ref=txManager/ /bean And on top of that you dont have to setup the transacted error handler, eg notice we dont have any errorHandlerRef in the route XML at all. So what you only *must* do for defining a route as transacted is to add the *transacted* DSL keyword. Next step in improvement would be to handle that the PROPAGATION_REQUIRED bean is optional, so Camel can lookup and find the PlatformManager and default to required itself. Just like the JMS component can do with transacted=true URI option. On Mon, Apr 6, 2009 at 1:56 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Mon, Apr 6, 2009 at 10:12 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Background is CAMEL-1475, however the ticket title is a bit misleading This morning I got Camel to be able to use transacted routes without you have to remember to configure a transactedErrorHandler. This makes it a bit easier to use transacted routes in Camel. So what you must do is use the *policy* DSL to define that this route is transacted. It still requires all the spring XML gobble to setup the TX manager and all that verbose XML you cannot remember. We can look at improving this later, want to keep the two of them separated to not loose oversight. What I wants to discuss is that I think the *policy* DSL keyword is a bit too loose. I would like it to be renamed to something that states its transacted, eg a) transacted b) transaction c) transactedPolicy d) transactionPolicy As the JMS component have a special *transacted* URI option, I would like the DSL to use same name as well. So I am in favor of option A. I have worked a bit more on this. We keep the policy as is as it can be used for generic wrapping routes by an interceptor. We can use this for security stuff as well. I have instead added - transacted() - transacted(String ref) to the ProcessorDefinition so we in the Java DSL can indicate the route is transacted using a key word that states this than eg just policy. I am also working on being able to auto lookup the PROPAGATION_REQUIRED so you dont even have to specify a reference. Camel will just use the one found, if there are ONLY ONE TransactedPolicy bean defined in the registry. Next up is to be able to default to find the PlatformManager and just use a default REQUIRED policy so we dont even have to setup the PROPAGATION_REQUIRED bean in the XML. This will make it a bit easier to configure, then you just have to remember all the standard Spring TX XML stuff and then Camel can use it out of the box. Just you remember to add the *transacted* DSL in the route. PS: We could even consider adding a *transacted=true* pseudo URI option on DefaultComponent that will automatically added a *transacted* DSL to the route. Well just a whacky idea. CAMEL-1475 also hints some more improvements we can do with convention over configuration, eg if there is only one SpringTransactionPolicy in the XML then use that. -- 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 -- 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 -- 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: svn commit: r762633 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/ main/java/org/apache/camel/impl/ test/java/org/apache/camel/processor/
public class RoutePerformanceTest extends ContextTestSupport {
+ private static final Log LOG =
LogFactory.getLog(RoutePerformanceTest.class);
protected SimpleDataSet dataSet = new SimpleDataSet(1000);
@@ -44,8 +47,8 @@
long delta = System.nanoTime() - start;
- System.out.println(Took: + delta + ns);
- System.out.println(Took: + delta / 100 + millis);
+ LOG.debug(Took: + delta + ns);
+ LOG.debug(Took: + delta / 100 + millis);
}
Can we keep this at System.out or maybe INFO logging level, or
whatever it takes to let it output by default when you run mvn
test/install?
I used it as a quick glimpse to see if it runs at the usual
perforamance level, eg 4 sec on my laptop.
When we had that performance degrade in Camel 1.6.0 this tests would
take x10 but most of the other tests runs at usual speed.
So its q quick indicator if something is wrong if it suddenly takes
longer/much longer time.
--
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] - Camel 2.0 - Easier Camel Spring Transaction configuration
Next step in improvement would be to handle that the PROPAGATION_REQUIRED bean is optional, so Camel can lookup and find the PlatformManager and default to required itself. Just like the JMS component can do with transacted=true URI option. Okay I have added this feature now. Camel will auto lookup the PlatformTransactionManager and if it can find a single bean in the registry it will use it. If there are 2 or more it will thrown an exception so you can configure an explicit policy defining which manager you want to use. This allows us to minimize the XML wiring, to what the Spring TX itself requires = NO XML configuration for Camel is needed at all. Just remember to set the route as transacted using transacted/ that's it! -- 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: CAMEL 2.0 - The remaining work
Hi What remains now that must be done are: a) Resort stream cache. Allowing Camel to work seamless with SMX. We might wanna enable it by default globally as for instance the content based router with xpath predicates requires to read the XML stream multiple times. Even for transacted routes, so it must be enabled by default IMHO. b) SMX Camel feature in the Camel build (Gert) https://issues.apache.org/activemq/browse/CAMEL-1526 The other 20 or so tickets assigned for Camel 2.0 is not fixed as must be done. Feel free to move them to 2.1 or if they are minor work get it fixed. On Thu, Apr 2, 2009 at 7:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: 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 -- 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
Camel 1.x Spring XML namespace URI problem with redirects
Hi For background see http://fusesource.com/forums/thread.jspa?messageID=2455#2455 The problem is that the old Camel 1.x namespace URIs is automatic redirected to the new TLP location at the apache site. Can we do something so the old Camel 1.x namespace can be preserved so Eclipse and other tooling work out of the box? Jonathan, Hadrian you are good at this sort of problem? -- 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: d...@activemq.codehaus.org bounces
Hi The camel mailing list uses a different address. Can you check this wiki page how to subscribe etc. http://camel.apache.org/mailing-lists.html On Tue, Apr 14, 2009 at 1:57 PM, jpcook jonathan.c...@erars.plus.com wrote: Hi, I wanted to be added to the above group so I can pick up some camel issues but everytime I email that address it bounces. The email I wanted added was jonathan.co...@bbc.co.uk Also any ideas as to what would be a gentle introduction? I had my eyes on. https://issues.apache.org/activemq/browse/CAMEL-868 or https://issues.apache.org/activemq/browse/CAMEL-761 Or maybe there is something simpler? Thanks -- View this message in context: http://www.nabble.com/dev%40activemq.codehaus.org-bounces-tp23038094p23038094.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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
Re: d...@activemq.codehaus.org bounces
Hi Ah the text was outdated. Camel graduated as a top level project at Apache in December 2008 so you should mail to: dev@camel.apache.org instead. I have fixed the text. On Tue, Apr 14, 2009 at 2:20 PM, jpcook jonathan.c...@erars.plus.com wrote: Hi, I didn't want to subscribe to the mailing lists. I was reading under 'Using the Issue Tracker' here: http://camel.apache.org/contributing.html and it mentions that: 'If you want to have a go at fixing an issue you need to be in the list of activemq-developers on the issue tracker. To join the group, please mail the d...@activemq.codehaus.org mail list with the email address you used to register with the issue tracker and we'll add you to the group.' I tried emailing that mail address but it bounces? I wanted to have a go at fixing an issue :) Jonathan Claus Ibsen-2 wrote: Hi The camel mailing list uses a different address. Can you check this wiki page how to subscribe etc. http://camel.apache.org/mailing-lists.html On Tue, Apr 14, 2009 at 1:57 PM, jpcook jonathan.c...@erars.plus.com wrote: Hi, I wanted to be added to the above group so I can pick up some camel issues but everytime I email that address it bounces. The email I wanted added was jonathan.co...@bbc.co.uk Also any ideas as to what would be a gentle introduction? I had my eyes on. https://issues.apache.org/activemq/browse/CAMEL-868 or https://issues.apache.org/activemq/browse/CAMEL-761 Or maybe there is something simpler? Thanks -- View this message in context: http://www.nabble.com/dev%40activemq.codehaus.org-bounces-tp23038094p23038094.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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 -- View this message in context: http://www.nabble.com/dev%40activemq.codehaus.org-bounces-tp23038094p23038396.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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
Re: d...@activemq.codehaus.org bounces
Hi Jonathan You should have been granted karma in Camel JIRA so you should be able to assign tickets to yourself. On Tue, Apr 14, 2009 at 2:26 PM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Ah the text was outdated. Camel graduated as a top level project at Apache in December 2008 so you should mail to: dev@camel.apache.org instead. I have fixed the text. On Tue, Apr 14, 2009 at 2:20 PM, jpcook jonathan.c...@erars.plus.com wrote: Hi, I didn't want to subscribe to the mailing lists. I was reading under 'Using the Issue Tracker' here: http://camel.apache.org/contributing.html and it mentions that: 'If you want to have a go at fixing an issue you need to be in the list of activemq-developers on the issue tracker. To join the group, please mail the d...@activemq.codehaus.org mail list with the email address you used to register with the issue tracker and we'll add you to the group.' I tried emailing that mail address but it bounces? I wanted to have a go at fixing an issue :) Jonathan Claus Ibsen-2 wrote: Hi The camel mailing list uses a different address. Can you check this wiki page how to subscribe etc. http://camel.apache.org/mailing-lists.html On Tue, Apr 14, 2009 at 1:57 PM, jpcook jonathan.c...@erars.plus.com wrote: Hi, I wanted to be added to the above group so I can pick up some camel issues but everytime I email that address it bounces. The email I wanted added was jonathan.co...@bbc.co.uk Also any ideas as to what would be a gentle introduction? I had my eyes on. https://issues.apache.org/activemq/browse/CAMEL-868 or https://issues.apache.org/activemq/browse/CAMEL-761 Or maybe there is something simpler? Thanks -- View this message in context: http://www.nabble.com/dev%40activemq.codehaus.org-bounces-tp23038094p23038094.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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 -- View this message in context: http://www.nabble.com/dev%40activemq.codehaus.org-bounces-tp23038094p23038396.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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 -- 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: [Heads Up] added an OSGi system test for running Camel in Felix Equinox
Hi This is really great new. The OSGi world is not as trivial as at first sight. On Thu, Apr 16, 2009 at 5:47 PM, James Strachan james.strac...@gmail.com wrote: Just as a simple integration test to check our OSGi metadata is OK, I've created a little integration test case here... http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/ http://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/OSGiIntegrationTest.java for this issue https://issues.apache.org/activemq/browse/CAMEL-1536 using Pax Exam http://wiki.ops4j.org/display/paxexam/Pax+Exam I made a minimal test (so not using Spring and so forth). We should add another test using Spring I guess too. I found quite a lot of stuff was mandatory rather than optional (e.g. JMX stuff and JAXB stuff) so I tweaked the metadata for camel-core a little to make more imports optional. I hope that doesn't break anything :). We could always make those imports mandatory in camel-spring maybe? (Though even with camel-spring you might wanna use JavaConfig) So far Pax Exam seems pretty good - the only missing feature is being able to use the project's pom to figure out what versions of things to use (like ServiceMix Kernel integration tests do). -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.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
Camel on Hudson - why is camel-jetty not run?
Hi Looking at: http://hudson.zones.apache.org/hudson/job/Camel/lastBuild/testReport/ The camel-jetty component is not tested. Is there a reason for this? And the new camel-itest-osgi fails constantly. -- 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: Camel on Hudson - why is camel-jetty not run?
On Mon, Apr 20, 2009 at 2:13 PM, Jon Anstey jans...@gmail.com wrote: camel-jetty looks to be running it the last completed build http://hudson.zones.apache.org/hudson/job/Camel/114/org.apache.camel$camel-jetty/console What build are you looking at? I think the current one is still building so the results are not complete. Well I guess Hudson and Nexus spooked me this weekend. I was on Nexus 1.2.1 and upgraded to 1.3.3 and then suddenly camel-jetty started failing. It worked before :) And the failure in camel-jetty I did not see in the hudson build reports over the weekend. Well anyway its there. Just wondered if it was disabled for some reason. On Sun, Apr 19, 2009 at 5:33 AM, Claus Ibsen claus.ib...@gmail.com wrote: Hi Looking at: http://hudson.zones.apache.org/hudson/job/Camel/lastBuild/testReport/ The camel-jetty component is not tested. Is there a reason for this? And the new camel-itest-osgi fails constantly. -- 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 -- Cheers, Jon http://janstey.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
Re: [DISCUSS] Release Camel 2.0-M2 and 1.6.1
+1 to both On Tue, Apr 21, 2009 at 6:55 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Hi, I think quite a bit of progress has been made in the trunk and more patches applied on the 1.x branch. There is still some more work to be done on 2.0, but I think what we have is a great candidate for a M2 release. The time is also right for a Camel 1.6.1 maintenance release. Thoughts? Hadrian -- 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 - Camel 2.0 - Internal API reworkings] - Channel and AsyncProcessor
On Fri, Apr 24, 2009 at 10:17 AM, Willem Jiang willem.ji...@gmail.com wrote: +1 for introducing Channel into Camel world. For the AsyncProcessor part, it's is really difficult to understand. I think it is more than Call back, it will not block the calling thread which will be used in the camel-jhc component[1]. And I also did an enhancement[2] on the ErrorHandler of DeadLetterChannel by leveraging the AsyncProcessor to avoid the blocking the calling thread when the DeadLetterChannel waits for another retry. If the UnitOfWork can address these, I'm happy to give my +1 for removing the AsyncProcessor. If not, we need to find out a replacement before removing it. [1] http://cwiki.apache.org/CAMEL/asynchronous-processing.html [2] https://issues.apache.org/activemq/browse/CAMEL-1129 Yeah the AsyncProcessor and the callback notion currently implemented in Camel is flawed, brittle, broken, not used at all from end user perspective and it started to spread out into the code base where it should not have. I really think it should be removed, and if we need it, a new Async API introduced that resemble the JDK async support (for instance the Future). To fix it I really think we need to 1) Remove the existing AsyncProcessor 2) At a later stage add a new API that leverages the JDK API. About redelivery using different threads = Note the using another thread for redeliver is only feasable for non transacted routes. Transacted routes tend to depend on ThreadLocal and reuse session and other stuff. So the redeliver using different thread is not always desirable. Note: But the redelivery is only supported by DeadLetterChannel that does not support transacted routes anyway. So you can say we are safe here. But the end user does not have any choice to configure what they want. I do think that end users should have the choice which model they would like Camel to use for redelivery handling. And with the Channel we would have another possiblity for redelivery as we could just route the message back to the previous channel and let it have some delay time before its visible on the channel queue for re-processing. So Willam, it would be much easier to impl. the use different thread for redelivery when the Channel is more enhanced in Camel. For instance for InOnly routes where there are no caller waiting we can safely use others threads for redeliver (if not transacted) But for InOut we need to add our own barrier that waits until the UnitOfWork is complete before we can return the response. Again I cannot stress too much that the camel-core API needs this cleanup. You will get to this conclusion if you have been working 8h around the clock in the camel-core code for as long as I have. Willem Claus Ibsen wrote: Hi Camel riders As you know we are working on Camel 2.0 and we decided to do a 2nd milestone release. This gives us more time to start on some of the ideas and internal refactorings I wanted to do for Camel 2.1. After having dived really deed in the camel core codebase for the last 6+ months or longer, I feel that we need to cease the moment and do a more extensive house cleaning before the Camel 2.0 release. The house cleaning is only internal and will not affect end users of Camel. Here are 2 issues I would like to address in the foreseeable future. 1) Channel == To introduce a Channel between each node in the route path. The channel is a composite processor that is responsible for routing the exchange to the next node in the path. We already do this but there is no visible notion of a Channel. The Channel exists today as a series of interceptors and an error handler. Today this is wrapped at route build time and then we have a static list of processors the exchanges is routed through a runtime. So what I am working on is to composite this series of interceptors and error handler into a DefaultChannel class that has the logic to do needed work before an Exchange is routed to the next node. I have already discussed this a bit with Gert and James. James agreed that it a was time for introducing the Channel into Camel. So I have started experimenting with this and got it working locally. The Channel is in this first stage just wrapping the existing series of interceptors and error handler and thus the route logic is not affect. In the future the Channel will benefit in many ways as we can at runtime add routing logic for instance - enabling/disabling tracing (and other interceptors) at runtime without reloading routes - adding or removing interceptors at runtime without reloading routes - adding or removing JMX performance metrics at runtime without reloading routes - we could use it to blocking routing - enhanced tooling support - potential you could persist exchanges at the channel - later add true async processing with the help of the channel - easier to traverse the runtime route graph as we
Re: [DISCUSS - Camel 2.0 - Internal API reworkings] - Channel and AsyncProcessor
On Fri, Apr 24, 2009 at 11:23 AM, Guillaume Nodet gno...@gmail.com wrote: The goal of the AsyncProcessor is to not block the calling thread when using an InOut exchange mostly. For example, if you invoke a web service which takes a long time to answer, you don't really want the thread to be blocked for a few seconds simply waiting for the answer: it just does not scale welll. Not sure if the UnitOfWork stuff is sufficient to cover the InOut stuff. I do think we need a redesigned API for this that leverages the JDK concurrency stuff much more, e.g. the Future. And the current implementation is broken. And when you get the done callback, how do you get the result? There is nothing that resembles future.get() to get the response. For instance see this unit tests that shows its broken. And how are we supposed to get the response And the API to leverage the async processing is not on par with the other API where we have one liners for most of it. Commit rev: 768269. http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/component/seda/SedaAsyncProcessorTest.java?view=markuppathrev=768269 On Fri, Apr 24, 2009 at 07:21, Claus Ibsen claus.ib...@gmail.com wrote: Hi Camel riders As you know we are working on Camel 2.0 and we decided to do a 2nd milestone release. This gives us more time to start on some of the ideas and internal refactorings I wanted to do for Camel 2.1. After having dived really deed in the camel core codebase for the last 6+ months or longer, I feel that we need to cease the moment and do a more extensive house cleaning before the Camel 2.0 release. The house cleaning is only internal and will not affect end users of Camel. Here are 2 issues I would like to address in the foreseeable future. 1) Channel == To introduce a Channel between each node in the route path. The channel is a composite processor that is responsible for routing the exchange to the next node in the path. We already do this but there is no visible notion of a Channel. The Channel exists today as a series of interceptors and an error handler. Today this is wrapped at route build time and then we have a static list of processors the exchanges is routed through a runtime. So what I am working on is to composite this series of interceptors and error handler into a DefaultChannel class that has the logic to do needed work before an Exchange is routed to the next node. I have already discussed this a bit with Gert and James. James agreed that it a was time for introducing the Channel into Camel. So I have started experimenting with this and got it working locally. The Channel is in this first stage just wrapping the existing series of interceptors and error handler and thus the route logic is not affect. In the future the Channel will benefit in many ways as we can at runtime add routing logic for instance - enabling/disabling tracing (and other interceptors) at runtime without reloading routes - adding or removing interceptors at runtime without reloading routes - adding or removing JMX performance metrics at runtime without reloading routes - we could use it to blocking routing - enhanced tooling support - potential you could persist exchanges at the channel - later add true async processing with the help of the channel - easier to traverse the runtime route graph as we can traverse the Channel, where we can have next/prev or the like methods - and much more we can imagine 2) AsyncProcessor = I propose to remove the AsyncProcessor all together. I had a chat with James about it and it was an experiment by Hiram back in early 2007. Basically he had not worked on the code since, and its not really put into good use. But sadly over time the AsyncProcessor have spread itself into other core parts of Camel. The basic idea was to attach a callback to a route so you could do some commit work after the exchange is finished. This idea is actually superseded by the UnitOfWork (introduced by James) that is better for this kind of work. And we have schduled an overhaul for UnitOfWork in Camel 2.1 to allow more of our components to take advantage of this and also expose DSLs for end users to attach their custom processors or route. The code in Camel core that is affected by the AsyncProcessor is much more complex than regular Processor. In fact there are some areas where its not used correctly and causes unforseen side effects that only surfaces in some complex or rare unit tests. This issues is more apparent lately as more and more camel processors supports the async processor directly. The original code by Hiram only leverages the async callback in the file component as it was part of his initial code. No other areas benefits from this. The code is basically making it bloat and complex inside Camel itself. End users do not use this. I do not recall a single question on it in the user
Re: [DISCUSS - Camel 2.0 - Internal API reworkings] - Channel and AsyncProcessor
Hi Another aspect of the impacts of the AsyncProcessor is that debugging Camel routing is much more complex as well. This will pull of end users with Camel as they can not easily just single step in the route chain. With the AsyncProcessor gone life will be much easier for both the people that maintain the camel code and the end users using it. We have timer thereafter to add a more powerfull and real Async routing capablilites into Camel, that more resemble what already in the JDK concurrency library. On Fri, Apr 24, 2009 at 2:19 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Apr 24, 2009 at 11:23 AM, Guillaume Nodet gno...@gmail.com wrote: The goal of the AsyncProcessor is to not block the calling thread when using an InOut exchange mostly. For example, if you invoke a web service which takes a long time to answer, you don't really want the thread to be blocked for a few seconds simply waiting for the answer: it just does not scale welll. Not sure if the UnitOfWork stuff is sufficient to cover the InOut stuff. I do think we need a redesigned API for this that leverages the JDK concurrency stuff much more, e.g. the Future. And the current implementation is broken. And when you get the done callback, how do you get the result? There is nothing that resembles future.get() to get the response. For instance see this unit tests that shows its broken. And how are we supposed to get the response And the API to leverage the async processing is not on par with the other API where we have one liners for most of it. Commit rev: 768269. http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/component/seda/SedaAsyncProcessorTest.java?view=markuppathrev=768269 On Fri, Apr 24, 2009 at 07:21, Claus Ibsen claus.ib...@gmail.com wrote: Hi Camel riders As you know we are working on Camel 2.0 and we decided to do a 2nd milestone release. This gives us more time to start on some of the ideas and internal refactorings I wanted to do for Camel 2.1. After having dived really deed in the camel core codebase for the last 6+ months or longer, I feel that we need to cease the moment and do a more extensive house cleaning before the Camel 2.0 release. The house cleaning is only internal and will not affect end users of Camel. Here are 2 issues I would like to address in the foreseeable future. 1) Channel == To introduce a Channel between each node in the route path. The channel is a composite processor that is responsible for routing the exchange to the next node in the path. We already do this but there is no visible notion of a Channel. The Channel exists today as a series of interceptors and an error handler. Today this is wrapped at route build time and then we have a static list of processors the exchanges is routed through a runtime. So what I am working on is to composite this series of interceptors and error handler into a DefaultChannel class that has the logic to do needed work before an Exchange is routed to the next node. I have already discussed this a bit with Gert and James. James agreed that it a was time for introducing the Channel into Camel. So I have started experimenting with this and got it working locally. The Channel is in this first stage just wrapping the existing series of interceptors and error handler and thus the route logic is not affect. In the future the Channel will benefit in many ways as we can at runtime add routing logic for instance - enabling/disabling tracing (and other interceptors) at runtime without reloading routes - adding or removing interceptors at runtime without reloading routes - adding or removing JMX performance metrics at runtime without reloading routes - we could use it to blocking routing - enhanced tooling support - potential you could persist exchanges at the channel - later add true async processing with the help of the channel - easier to traverse the runtime route graph as we can traverse the Channel, where we can have next/prev or the like methods - and much more we can imagine 2) AsyncProcessor = I propose to remove the AsyncProcessor all together. I had a chat with James about it and it was an experiment by Hiram back in early 2007. Basically he had not worked on the code since, and its not really put into good use. But sadly over time the AsyncProcessor have spread itself into other core parts of Camel. The basic idea was to attach a callback to a route so you could do some commit work after the exchange is finished. This idea is actually superseded by the UnitOfWork (introduced by James) that is better for this kind of work. And we have schduled an overhaul for UnitOfWork in Camel 2.1 to allow more of our components to take advantage of this and also expose DSLs for end users to attach their custom processors or route. The code in Camel core that is affected by the AsyncProcessor is much more
Re: [DISCUSS - Camel 2.0 - Internal API reworkings] - Channel and AsyncProcessor
On Fri, Apr 24, 2009 at 2:36 PM, James Strachan james.strac...@gmail.com wrote: 2009/4/24 Claus Ibsen claus.ib...@gmail.com: On Fri, Apr 24, 2009 at 11:23 AM, Guillaume Nodet gno...@gmail.com wrote: The goal of the AsyncProcessor is to not block the calling thread when using an InOut exchange mostly. For example, if you invoke a web service which takes a long time to answer, you don't really want the thread to be blocked for a few seconds simply waiting for the answer: it just does not scale welll. Not sure if the UnitOfWork stuff is sufficient to cover the InOut stuff. I do think we need a redesigned API for this that leverages the JDK concurrency stuff much more, e.g. the Future. And the current implementation is broken. And when you get the done callback, how do you get the result? Exchange.getOut() ? Yeah but then I have to use the classic Camel API. Not the 1 liners. See the recent unit test that was committed: SedaAsyncProcessorTest Then we have a sample to work with. The Exchange object kinda is the 'future' object. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.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
Re: Code formatter - Eclipse / checkstyle
Hi Take a look in the camel source. There should be some checkstyle files that Eclipse can use. In this folder /buildingtools/src/main/resources$ On Tue, Apr 28, 2009 at 9:19 AM, Charles Moulliard cmoulli...@gmail.com wrote: Hi, I'm looking for a template that I can use in Eclipse Ganymede 3.4 allowing to format my code according to checkstyle rules which are supported by Apache Camel community. Is such template existing ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer blog http://cmoulliard.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
Re: The jmsMessage is not set yet, call the super's createMessageId
Hi
The problem is that you are setting the header on the backing javax.jms.Message.
What you should do is set the header on the Camel Exchange/Message API.
So the code in your bean should be like this:
exchange.getIn().setHeader(route, b);
On Tue, Apr 28, 2009 at 8:36 PM, jbekas john+nab...@bekas.org wrote:
activemq 5.2.0
camel-2.0-M1
I'm trying to set a header on a JmsMessage based on content contained in the
message. I then use a choice statement to route to the next destination.
However, I receive the log message The jmsMessage is not set yet, call the
super's createMessageId when the header is tested.
I'm testing the content in a bean, pseudo-coded as
public class PreProcessor {
public void determineRouting(Exchange exchange) {
Message message = exchange.getIn().getBody(Message.class);
message.setHeader(route, a);
}
}
My route configuration looks like this
Predicate isA = header(route).isEqualTo(a);
Predicate isB = header(route).isEqualTo(b);
from(jms:queue:msgin)
.to(bean:preProcessor?method=determineRouting)
.choice()
.when(isA).to(direct:aProcessor)
.when(isB).to(direct:bProcessor);
Debugging where the log message happens, it appears that it occurs after my
PrePrecessor and before the choice:
at
org.apache.camel.component.jms.JmsMessage.createMessageId(JmsMessage.java:165)
at
org.apache.camel.impl.MessageSupport.getMessageId(MessageSupport.java:146)
at
org.apache.camel.component.jms.JmsMessage.copyFrom(JmsMessage.java:77)
at
org.apache.camel.processor.Pipeline.createNextExchange(Pipeline.java:183)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:86)
...
I've dug through the source and discovered that this log message is made if
the javax.jms.Message (aka jmsMessage) is not set on the
org.apache.camel.component.jms.JmsMessage in the exchange. It is set on the
copy in my original Exchange object. Judging from the code, it should be
copied when the Exchange is replicated, but that does not appear to be the
case.
My processing is successful, so the log message is a nuisance more than
anything. I'll have to tweak the log4j settings so that this message
doesn't pollute the logs a few million times a day.
Obviously someone thought it was important to check and see if the original
JmsMessage was passed along the processing route or not. Is this a bug?
I've tried various ways to prevent this, but without modifying camel source
code, it doesn't appear feasible.
Thoughts or suggestions?
-
Freelance Application Development Consultant
LinkedIn Profile: http://www.linkedin.com/in/johnbekasjr
http://www.linkedin.com/in/johnbekasjr
--
View this message in context:
http://www.nabble.com/The-jmsMessage-is-not-set-yet%2C-call-the-super%27s-createMessageId-tp23283591p23283591.html
Sent from the Camel Development mailing list archive at Nabble.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
Re: Facing problems while using Set Header camel Processor
Hi The JMS spec only allows a limited set of types and key names for JMS properties (aka headers). So its likely the result of the xpath expression is not a valid type and thus its dropped. You can use the Tracer to see how the message is routed and what it contains at the different points in the route graph. http://camel.apache.org/tracer.html You can try changing the xpath to a constant instead that should be a valid type setHeader ... constant1234/constant /setHeader You can force the xpath to return it as a valid JMS type, such as a string by setting the resultType=java.lang.String on the xpath. See more here: http://camel.apache.org/xpath.html On Wed, Apr 29, 2009 at 7:04 AM, sailaja p spind...@progress.com wrote: Hi All, I am facing some difficulty when deploying a Camel Spring XML configuration with Message Translator pattern and Set Header Processor into Service mix 3.4.0.1. I have defined a route with JMS Endpoint(TestMF)- Set Header Processor (Xpath) - JMS Endpoint (TestMF1) - Message Translator (Header) - Convert Body To (String) - JMS Endpoint (TestMF2). Below is my Camel configuration file and the input xml. Camel Configuration beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://activemq.apache.org/camel/schema/spring http://activemq.apache.org/camel/schema/spring/camel-spring-1.5.0.xsd; camelContext id=camelroute xmlns=http://activemq.apache.org/camel/schema/spring; route xmlns=http://activemq.apache.org/camel/schema/spring; id=null_1 from uri=jms:queue:TestMF id=JMS_0 / setHeader headerName=TestHeader id=SetHeader_0 xpath//Input/xpath /setHeader to uri=jms:queue:TestMF1 id=JMS_1 / transform id=MessageTranslator_0 descriptionA special filter to translate one data format into another/description headerTestHeader/header /transform convertBodyTo type=java.lang.String id=ConvertBodyTo_0 descriptionTo convert using the default content type to a particular type/description /convertBodyTo to uri=jms:queue:TestMF2 id=JMS_2 / /route /camelContext /beans Input File is Sample InputTest/Input /Sample I am sending the above input xml to the JMS Endpoint (Q1). I was expecting that the Set Header Process adds a Header to the message and it assigns XPath Expression output as a Header value (TestHeader=Test). But I didnt observe the header in the message received at JMS Endpoint (Q2). But the Message Translator is processing the message succesfully based on the header that is set by the Set Header Processor. I have two questions regarding this. 1. Why I didnt see the Header in the JMS Endpoint (Q2)? 2. Can I assign the node value to a header? Like assigning the following value to the header. Sample InputValueTest/Value/Input -- apply Xpath, /Sample/Input --- assign this Value1234/Value to a Header /Sample Thanks in advance, sailaja. -- View this message in context: http://www.nabble.com/Facing-problems-while-using-Set-Header-camel-Processor-tp23290594p23290594.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.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
Re: [DISCUSS] Break camel-core into camel-api and camel-core
On Wed, Apr 29, 2009 at 12:02 PM, Willem Jiang willem.ji...@gmail.com wrote: Hi riders, I'm thinking to do some refactoring of Camel test support to let camel-core depends on camel-test. In this way we just have one copy of TestSupport and CamelTestSupport. Because camel-test has the dependence of CamelContext , ProducerTemplate, Service, RouteBuilder, etc, I'd like to break current camel-core module into camel-api and camel-core, and the camel-test will depends on the camel-api only. Then we can share the camel-test code around all the camel-components and camel-core. Since CamelTestSupport has the dependency of the CamelBeanPostProcessor , we could put it into the camel-spring module. Any thought? If the only purpose is to keep camel-test in sync with camel-core then I am not keen on this. We have many interfaces and much more in camel-core that constitutes the API. We have the implementation in component, impl and processor. And working on both in a single project is much easier with SVN and your editor such as Eclipse or IDEA. In the works for Camel 2.0 we have changed or refactored the code numerous times and I doubt it would have been so easy if the code was split. Isnt it possible to keep camel-test in sync by some copy script that can copy the src from camel-core to camel-test so its automatic updated. Willem -- 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: Camel 2.0 Async Findings - Roadmap to a solution
Hi
This is just a short update on:
Ad 3)
The new Async API
I started iTunes with some good tunes from my youth gone wild period,
so I had a crack at prototype of the async API.
Here is the first unit test demonstrating how it could work with the
JDK Future API (for real async)
public class DefaultAsyncProcessorTemplateTest extends ContextTestSupport {
public void testRequestAsync() throws Exception {
AsyncProducerTemplate async = new DefaultAsyncProducerTemplate(context);
async.start();
Exchange exchange = new DefaultExchange(context);
exchange.getIn().setBody(Hello);
FutureExchange future = async.requestAsync(direct:start, exchange);
long start = System.currentTimeMillis();
System.out.println(Look ma I can do other stuff while the async runs);
Exchange result = future.get();
long delta = System.currentTimeMillis() - start;
System.out.println(Damn that async takes time so I had to
wait + delta + ms.);
assertEquals(Hello World, result.getOut().getBody());
async.stop();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
from(direct:start)
.delay(2000)
.transform(body().append( World)).to(mock:result);
}
};
}
}
And the console ouput when I run it
2009-04-30 10:43:56,585 [main ] INFO DefaultCamelContext
- Apache Camel (CamelContext:camel-1) started
2009-04-30 10:43:56,586 [main ] DEBUG
aultAsyncProcessorTemplateTest - Routing Rules are:
Look ma I can do other stuff while the async runs
2009-04-30 10:43:58,833 [pool-1-thread-1] DEBUG MockEndpoint
- mock:result 1 : Exchange[Message: Hello World] with
body: Hello World
Damn that async takes time so I had to wait 2134 ms.
2009-04-30 10:43:58,835 [main ] DEBUG
aultAsyncProcessorTemplateTest - tearDown test: testRequestAsync
On Thu, Apr 30, 2009 at 7:32 AM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
You might remember my previous topic about the AsyncProcessor.
http://www.nabble.com/-DISCUSS---Camel-2.0---Internal-API-reworkingsChannel-and--AsyncProcessor-td23210093.html
I had some more time to thinker about it and I believe I have a
roadmap for a solution that will work nicely for all.
1) Internal house cleaning in camel-core
2) Fix as much of the current broken AsyncCallback
3) Introduce new async API in Camel 2.0
4) Mark the current AsyncCallback as @deprecated in Camel 2.0m2
Ad 1)
The AsyncProcessing internally in Camel is overused and it just makes
it much more complex. By doing a house cleaning the codebase is much
easier to work with and it works as before.
In fact it allows us to do fix the broken AsyncCallback also so we can
get notification when the async exchange is done.
Ad 2)
The current notification in Camel is in fact broken. You never get the
expected notification when the async exchange is done. The idea of
this API was to get 2 notifications
- the 1st is when the original synch thread is done (the boolean is
true), eg when you submit the job.
- and then the 2nd when the async thread is done (the boolean is
false) but this is broken in Camel and you will not receive it.
And of top of this there are 2 flaws in the current API
- the current code requires that you manaully add seda steps in the
route to turn the route from sync into async. There was no code that
did this under the covers for you. However its doable and the in
fact its possible to route async. But an improve API would be better.
- The result of the async operation is not possible to get easily. No
you dont have access to the exchange that was done async. And no
exchange.getOut() will not give the result. What was missing in the
AsyncCallback API was to pass in the Exchange as well.
Ad 3)
I would like to introduce a new Async API that is more similar to the
JDK Future API. So you can use the Future get() to get hold of the
result.
This still needs some thinking and experimenting to see how its
doable. But an API that generally is like the Future would be much
better.
Ad 4)
I would also suggest that we (in Camel 2.0m2) mark AsyncCallback as
@deprecated with a note that we have planned a new Async API for Camel
2.0
Conclusion
I would like to go forward and get #1, (#2 and #4 would be great too)
committed into the codebase so we have a codebase in Camel that is
much easier to maintain and for new users to understand when they look
into the internals in Camel. And especially debugging and stepping
through the processing of Exchanges is much easier. As its just
regular method calls. And we get rid of the confusing code with what
to do in the AsyncCallbacks that was invading the internals in Camel.
Then I would
Re: [DISCUSS] Break camel-core into camel-api and camel-core
On Thu, Apr 30, 2009 at 11:38 AM, Willem Jiang willem.ji...@gmail.com wrote: Hi Claus, Here is another benefit of spreate the camel-api with camel-core. We could drop a clean line between the user API and internal API. None of the others do it that I am aware of. spring-core.jar does contain impl and API in same .jar. I was wondering if the OSGi export packages should reflect the public API of Camel, so we can leverage that to expose the public API. I would really dislike to work with two maven projects to maintain and work on Camel. I can live with sync the camel-test with camel-core by the copying script. Yeah its after all only 1 or 2 classes in camel-test. Thanks, Willem Claus Ibsen wrote: On Wed, Apr 29, 2009 at 12:02 PM, Willem Jiang willem.ji...@gmail.com wrote: Hi riders, I'm thinking to do some refactoring of Camel test support to let camel-core depends on camel-test. In this way we just have one copy of TestSupport and CamelTestSupport. Because camel-test has the dependence of CamelContext , ProducerTemplate, Service, RouteBuilder, etc, I'd like to break current camel-core module into camel-api and camel-core, and the camel-test will depends on the camel-api only. Then we can share the camel-test code around all the camel-components and camel-core. Since CamelTestSupport has the dependency of the CamelBeanPostProcessor , we could put it into the camel-spring module. Any thought? If the only purpose is to keep camel-test in sync with camel-core then I am not keen on this. We have many interfaces and much more in camel-core that constitutes the API. We have the implementation in component, impl and processor. And working on both in a single project is much easier with SVN and your editor such as Eclipse or IDEA. In the works for Camel 2.0 we have changed or refactored the code numerous times and I doubt it would have been so easy if the code was split. Isnt it possible to keep camel-test in sync by some copy script that can copy the src from camel-core to camel-test so its automatic updated. Willem -- 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: Camel 2.0 Async Findings - Roadmap to a solution
Hi
Just another update on #3. I had some more fun with Camel and
introduced a async() DSL in the route, to turn the route into async
from the point forward.
The unit test code explains it, and gives a hint how we can leverage this.
Any thoughts?
public class AsyncRouteTest extends ContextTestSupport {
public void testAsyncRoute() throws Exception {
MockEndpoint mock = getMockEndpoint(mock:result);
mock.expectedBodiesReceived(Bye World);
// send a request reply to the direct start endpoint
Object out = template.requestBody(direct:start, Hello);
// as it turns into a async route later we get a Future as response
assertIsInstanceOf(Future.class, out);
// cast to future
Future future = (Future) out;
System.out.println(Look ma I can do other stuff while the async runs);
// and use future to get the response
Exchange response = (Exchange) future.get();
// get the response from the OUT message
// TODO: add type converters so we can leverage them with
Future to get the
// body response more easily
assertEquals(Bye World, response.getOut().getBody());
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
// we start this route async
from(direct:start)
// we play a bit with the message
.transform(body().append( World))
// now turn the route into async from this point forward
// the caller will have a FutureExchange
returned as response in OUT
// to be used to grap the async response when he
fell like it
.async()
// from this point forward this is the async route
doing its work
// so we do a bit of delay to simulate heavy work
that takes time
.delay(1000)
// and we also play with the message so we can
prepare a response
.process(new Processor() {
public void process(Exchange exchange) throws
Exception {
assertEquals(Hello World,
exchange.getIn().getBody());
exchange.getOut().setBody(Bye World);
}
// and we use mocks for unit testing
}).to(mock:result);
}
};
}
--
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: Camel 2.0 Async Findings - Roadmap to a solution
Hi
Its me again. Yeah I am due for a run in due time, but just wanted to
demo something that is either powerful or scary
The code below uses the same route. But as we request a body and we
have declared we want the response as a String.class (the last
parameter)
Then Camel is clever or scary to use the Future to wait and get
the result and convert the body to the desired type, eg a String.
So the routing is really divided into sync/async but the end user sees
it as a single sync.
public void testAsyncRouteWithTypeConverted() throws Exception {
MockEndpoint mock = getMockEndpoint(mock:result);
mock.expectedBodiesReceived(Bye World);
// send a request reply to the direct start endpoint, but will use
// future type converter that will wait for the response
String response = template.requestBody(direct:start,
Hello, String.class);
assertEquals(Bye World, response);
assertMockEndpointsSatisfied();
}
So whats next is that you can just pass in the FutureString.class to
instruct Camel that you want the future handle back
and that it should return a String as the response.
Then Camel should be able to take it from there. With the future
handle the caller gets back in control when the routes hits the
async() DSL.
And can do other work as he like.
And when he want the response, he just:
FutureString future = template.requestBody(direct:start, Hello,
FutureString.class);
String response = future.get();
But then I guess this is impossible due to type erasure in java generics :(
No its not!!!
Okay time to hit the streets
--
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: Camel 2.0 Async Findings - Roadmap to a solution
On Thu, Apr 30, 2009 at 4:05 PM, Willem Jiang willem.ji...@gmail.com wrote:
Hi Claus,
Does the async() DSL will fork a thread for the further processing?
What's the difference between the async() DSL and send the message to a
seda endpoint?
Yes it forks a thread. Its the JDK Executor that handles this. That is
the beauty as we leverage the concurrency API in JDK.
The work I have done today is just experimental and thus nothing is
settled in stone. I just wanted to share what I have played with
today.
The different is that with async() DSL we leverage 100% the JDK
concurrency API for async callbacks. So async() DSL will return a
handle to the callback known as the Future handle from the JDK itself.
Then the original caller can use this handle to get the result.
With seda we do not leverage the JDK async API in the same sense. We
send a copy of the exchange to a JDK queue that a consumer in another
thread is listening.
Another difference is the seda is an endpoint. And thus we can use it
with the dynamic recipient list EIP patterns and all the other
patterns that work with endpoints. The async() is a DSL that is fixed
in that sence it breaks the current processing of the Exchange and
returns a Future handle to the original caller. And spaws a thread and
continues routing the exchange. All using the JDK async API.
The code for the async() DSL is basically:
public void process(final Exchange exchange) throws Exception {
// let it execute async and return the Future
CallableExchange task = new CallableExchange() {
public Exchange call() throws Exception {
for (Processor output : outputs) {
output.process(exchange);
}
return exchange;
}
};
FutureExchange future = executor.submit(task);
// set the future as response so we can get this handle and
get the response later
exchange.getOut().setBody(future);
}
It was just an experiment as I wanted to see if it was possible to
change the current route into async without seda.
Thanks,
Willem
Claus Ibsen wrote:
Hi
Just another update on #3. I had some more fun with Camel and
introduced a async() DSL in the route, to turn the route into async
from the point forward.
The unit test code explains it, and gives a hint how we can leverage this.
Any thoughts?
public class AsyncRouteTest extends ContextTestSupport {
public void testAsyncRoute() throws Exception {
MockEndpoint mock = getMockEndpoint(mock:result);
mock.expectedBodiesReceived(Bye World);
// send a request reply to the direct start endpoint
Object out = template.requestBody(direct:start, Hello);
// as it turns into a async route later we get a Future as response
assertIsInstanceOf(Future.class, out);
// cast to future
Future future = (Future) out;
System.out.println(Look ma I can do other stuff while the async
runs);
// and use future to get the response
Exchange response = (Exchange) future.get();
// get the response from the OUT message
// TODO: add type converters so we can leverage them with
Future to get the
// body response more easily
assertEquals(Bye World, response.getOut().getBody());
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
// we start this route async
from(direct:start)
// we play a bit with the message
.transform(body().append( World))
// now turn the route into async from this point forward
// the caller will have a FutureExchange
returned as response in OUT
// to be used to grap the async response when he
fell like it
.async()
// from this point forward this is the async route
doing its work
// so we do a bit of delay to simulate heavy work
that takes time
.delay(1000)
// and we also play with the message so we can
prepare a response
.process(new Processor() {
public void process(Exchange exchange) throws
Exception {
assertEquals(Hello World,
exchange.getIn().getBody());
exchange.getOut().setBody(Bye World);
}
// and we use mocks for unit testing
}).to(mock:result);
}
};
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com
Re: Release process started for camel 1.6.1 and 2.0-M2
Can ypu change AMQ to 5.2.0 then. On Thu, Apr 30, 2009 at 4:53 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: I already started on that, but stopped due to the dependencies on snaphosts. Until they are resolved I won't build a release. Hadrian On Apr 30, 2009, at 10:01 AM, Willem Jiang wrote: Hi Hadrian, Just a quick question, when will you cut the release ? Willem Hadrian Zbarcea wrote: If you know of any issues that *must* be fixed in these releases please let me know. Hadrian -- 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: Camel 2.0 Async Findings - Roadmap to a solution
On Thu, Apr 30, 2009 at 4:00 PM, Willem Jiang willem.ji...@gmail.com wrote:
How about introducing Async requestBody API to the template?
It just return a Future object, then we can turn the value of Future
into what we want.
Good idea. In fact I have done that already.
FutureObject requestAsyncBody(String endpoint, Object body);
But I wanted to start with a raw Exchange at first.
The idea is to have similar methods as the regular producer template,
so you can shoot in headers as well.
There is though something to think a bit more about is the exchange
patterns for inOnly how that can still have the need to return the
Future object as you might want to know when or if the task is done,
even thought there is no response for you.
So instead of void as return its probably gonna be something like Future.
I will later add another patch at the CAMEL-1572 ticket so you can
take a closer look at my experiments.
Willem
Claus Ibsen wrote:
Hi
Its me again. Yeah I am due for a run in due time, but just wanted to
demo something that is either powerful or scary
The code below uses the same route. But as we request a body and we
have declared we want the response as a String.class (the last
parameter)
Then Camel is clever or scary to use the Future to wait and get
the result and convert the body to the desired type, eg a String.
So the routing is really divided into sync/async but the end user sees
it as a single sync.
public void testAsyncRouteWithTypeConverted() throws Exception {
MockEndpoint mock = getMockEndpoint(mock:result);
mock.expectedBodiesReceived(Bye World);
// send a request reply to the direct start endpoint, but will use
// future type converter that will wait for the response
String response = template.requestBody(direct:start,
Hello, String.class);
assertEquals(Bye World, response);
assertMockEndpointsSatisfied();
}
So whats next is that you can just pass in the FutureString.class to
instruct Camel that you want the future handle back
and that it should return a String as the response.
Then Camel should be able to take it from there. With the future
handle the caller gets back in control when the routes hits the
async() DSL.
And can do other work as he like.
And when he want the response, he just:
FutureString future = template.requestBody(direct:start, Hello,
FutureString.class);
String response = future.get();
But then I guess this is impossible due to type erasure in java generics :(
No its not!!!
Okay time to hit the streets
--
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
