Re: How do i use a JMS Consumer in Camel DSL?
Yes. You just need to update the serviemix-camel component. Another work around method is using the serviceMix3 serivce unit instead of ServiceMix4's osgi bundle to deploy your camel context. But you may need to build up the camel-servicemix service-engine youself to add the camel-jms component into the it. Here is a FAQ[1] which discuss about it. [1] http://cwiki.apache.org/CAMEL/how-to-use-extra-camel-componets-in-servicemix-camel.html Willem triggershot wrote: Is it sufficient to update the servicemix-camel to use a JMS consumer in camel contexts?
Re: Aggregation error with Spring DSL
I have adapted the aggregation strategy of the splitter like this :
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
List requestMessages = new ArrayList();
if (oldExchange == null) {
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class);
// Get new and add it to the list
RequestMessage newReqMessage = newExchange.getOut().getBody(
RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
but no ArrayList are propagated after the split().
Where is the issue ?
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Mon, Jun 15, 2009 at 5:33 PM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi Charles
In Camel 2.0 the very first invocation to your aggregate the *old*
exchange is null.
So often you just return the new exchange as you do not have 2
messages to aggregate.
if (oldExchange == null) {
return newExchange;
}
This is changed in Camel 2.0 over 1.x. (eg recently change)
On Mon, Jun 15, 2009 at 5:31 PM, Charles Moulliardcmoulli...@gmail.com
wrote:
Hi,
The following error is generated :
Caused by: java.lang.NullPointerException
at
com.xpectis.x3s.core.util.x3sAggregationStrategy.aggregate(x3sAggregationStrategy.java:18)
at
org.apache.camel.processor.MulticastProcessor.doAggregate(MulticastProcessor.java:208)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequntiel(MulticastProcessor.java:190)
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:121)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
with my route :
bean id=aggregationStrat
class=com.xpectis.x3s.core.util.x3sAggregationStrategy /
!-- Split the collection of messages --
camel:split strategyRef=aggregationStrat
camel:ognlrequest.body/camel:ognl
!-- (1) Call the service to save the request message --
camel:bean ref=serviceHelper
method=createRequestMessage/
!-- (2) Validate the business message --
camel:bean ref=serviceHelper
method=validateRequestMessage/
!-- (3) Save business message --
camel:bean ref=serviceHelper
method=saveRequestMessage/
/camel:split
public class x3sAggregationStrategy implements AggregationStrategy {
public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
{
List requestMessages = new ArrayList();
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class); // =
LINE 18
// Get new and add it to the list
RequestMessage newReqMessage =
newExchange.getOut().getBody(RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
I try to collect all the RequestMessage and put it in a collection that I
will use after the split. How can I do that ?
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
Re: Aggregation error with Spring DSL
On Tue, Jun 16, 2009 at 10:35 AM, Charles Moulliardcmoulli...@gmail.com wrote:
I have adapted the aggregation strategy of the splitter like this :
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
List requestMessages = new ArrayList();
if (oldExchange == null) {
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class);
// Get new and add it to the list
RequestMessage newReqMessage = newExchange.getOut().getBody(
RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
but no ArrayList are propagated after the split().
Where is the issue ?
Charles you really need glasses or to use a few more minutes before
posting your problem. :)
What is wrong with this code below. I leave up to you to find out, but
its really easy to spot.
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Mon, Jun 15, 2009 at 5:33 PM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi Charles
In Camel 2.0 the very first invocation to your aggregate the *old*
exchange is null.
So often you just return the new exchange as you do not have 2
messages to aggregate.
if (oldExchange == null) {
return newExchange;
}
This is changed in Camel 2.0 over 1.x. (eg recently change)
On Mon, Jun 15, 2009 at 5:31 PM, Charles Moulliardcmoulli...@gmail.com
wrote:
Hi,
The following error is generated :
Caused by: java.lang.NullPointerException
at
com.xpectis.x3s.core.util.x3sAggregationStrategy.aggregate(x3sAggregationStrategy.java:18)
at
org.apache.camel.processor.MulticastProcessor.doAggregate(MulticastProcessor.java:208)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequntiel(MulticastProcessor.java:190)
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:121)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
with my route :
bean id=aggregationStrat
class=com.xpectis.x3s.core.util.x3sAggregationStrategy /
!-- Split the collection of messages --
camel:split strategyRef=aggregationStrat
camel:ognlrequest.body/camel:ognl
!-- (1) Call the service to save the request message --
camel:bean ref=serviceHelper
method=createRequestMessage/
!-- (2) Validate the business message --
camel:bean ref=serviceHelper
method=validateRequestMessage/
!-- (3) Save business message --
camel:bean ref=serviceHelper
method=saveRequestMessage/
/camel:split
public class x3sAggregationStrategy implements AggregationStrategy {
public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
{
List requestMessages = new ArrayList();
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class); // =
LINE 18
// Get new and add it to the list
RequestMessage newReqMessage =
newExchange.getOut().getBody(RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
I try to collect all the RequestMessage and put it in a collection that I
will use after the split. How can I do that ?
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
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Strange behaviour with camel and JMS queues
On Mon, Jun 15, 2009 at 5:41 PM, Tim83tim.str...@roots.be wrote:
I'm seeing some strange behaviour with camel 1.6 and camel 1.6.1
First issue relates to the exchange patterns.
I have setup a camel route that takes a message from a JMS queue, processes
the message and sends a message to another queue.
camel:route
camel:from uri=activemq:queue:source /
!-- some processing occurs here --
camel:to uri=activemq:queue:confirm?disableReplyTo=true
pattern=InOnly/
/camel:route
I added pattern=InOnly on my destination but if you look in the info
logging produced by camel, you'll notice that is still using the OutIn
pattern ?
Does anybody know how to solve this issue, as it's quite annoying...
I have newer seen a OutIn pattern before?
Are you sure its not InOut?
You could try with a simpler route, eg without all the processing to
see if it works with a simple
from(jms)-to(jms)
Maybe something happens during the processing that breaks something.
By default a JMS consumer is InOnly if the JMSReplyTo message it
consumes is empty/null.
So the InOnly should not be needed. But maybe your processing code
changes the pattern from InOnly to something else.
INFO: ID-./55643-1245079597289/2-0 -
to(activemq:queue:confirm?disableReplyTo=true), Pattern:OutIn ,
Headers:{JMSXGroupID=null, JMSCorrelationID=x, JMSType=null,
JMSExpiration=0, JMSMessageID=ID:49640-1245078470039-0:3:12:1:1,
JMSRedelivered=false, JMSDeliveryMode=2, JMSPriority=4, JMSReplyTo=null,
JMSTimestamp=1245079607451,
JMSDestination=temp-queue://ID:.-55639-1245079591886-0:0:2} ,
BodyType:java.util.HashMap , Body:{}}
15/06/2009 17:26:47 org.apache.camel.component.jms.JmsProducer process
Then camel prints out the following warning message.
WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
Exchange[JmsMessage: ActiveMQMapMessage {commandId = 60, responseRequired =
true, messageId = ID:-49640-1245078470039-0:3:12:1:1,
originalDestination = null, originalTransactionId = null, producerId =
ID:..-49640-1245078470039-0:3:12:1, destination =
temp-queue://ID:..55639-1245079591886-0:0:2, transactionId = null,
expiration = 0, timestamp = 1245079607451, arrival = 0, brokerInTime =
1245079607407, brokerOutTime = 1245079607407, correlationId = x, replyTo
= null, persistent = true, type = null, priority = 4, groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false, userID =
null, content = org.apache.activemq.util.byteseque...@b08658,
marshalledProperties = null, dataStructure = null, redeliveryCounter = 0,
size = 0, properties = null, readOnlyProperties = true, readOnlyBody = true,
droppable = false} ActiveMQMapMessage{ ... ] with destination: confirm
The warning is fixed in the next release - 1.6.2 and 2.0m2.
And the FUSE releases.
Second issue relates to the number of consumers started by camel
When upgrading from camel 1.6 to camel 1.6.1 I noticed that all of a sudden
I had 2 consumers for each JMS queue despite the fact that I do specify that
I only want one consumer???
bean id=jmsConfig
class=org.apache.camel.component.jms.JmsConfiguration
property name=connectionFactory ref=jmsFactory/
property name=transactionManager ref=jmsTransactionManager/
property name=transacted value=true/
property name=concurrentConsumers value=1/
/bean
Any idea what causing this strange behavior?
And does anybody know how to fix these issues?
You are the first to report something about having multiple consumers.
Maybe you route is being loaded twice?
You are welcome to create a small project that demonstrates the issues
you have a and submit it to a JIRA ticket.
Then we can take a look at it.
Thanks,
Tim
--
View this message in context:
http://www.nabble.com/Strange-behaviour-with-camel-and-JMS-queues-tp24037119p24037119.html
Sent from the Camel - Users 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: Aggregation error with Spring DSL
Shame on me. I do too much things at the same time.
oldExchange.getOut().setBody(requestMessages);
return newExchange; -- return oldExchange;
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Tue, Jun 16, 2009 at 10:41 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Tue, Jun 16, 2009 at 10:35 AM, Charles Moulliardcmoulli...@gmail.com
wrote:
I have adapted the aggregation strategy of the splitter like this :
public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
{
List requestMessages = new ArrayList();
if (oldExchange == null) {
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class);
// Get new and add it to the list
RequestMessage newReqMessage = newExchange.getOut().getBody(
RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
but no ArrayList are propagated after the split().
Where is the issue ?
Charles you really need glasses or to use a few more minutes before
posting your problem. :)
What is wrong with this code below. I leave up to you to find out, but
its really easy to spot.
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Mon, Jun 15, 2009 at 5:33 PM, Claus Ibsen claus.ib...@gmail.com
wrote:
Hi Charles
In Camel 2.0 the very first invocation to your aggregate the *old*
exchange is null.
So often you just return the new exchange as you do not have 2
messages to aggregate.
if (oldExchange == null) {
return newExchange;
}
This is changed in Camel 2.0 over 1.x. (eg recently change)
On Mon, Jun 15, 2009 at 5:31 PM, Charles Moulliardcmoulli...@gmail.com
wrote:
Hi,
The following error is generated :
Caused by: java.lang.NullPointerException
at
com.xpectis.x3s.core.util.x3sAggregationStrategy.aggregate(x3sAggregationStrategy.java:18)
at
org.apache.camel.processor.MulticastProcessor.doAggregate(MulticastProcessor.java:208)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequntiel(MulticastProcessor.java:190)
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:121)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
with my route :
bean id=aggregationStrat
class=com.xpectis.x3s.core.util.x3sAggregationStrategy /
!-- Split the collection of messages --
camel:split strategyRef=aggregationStrat
camel:ognlrequest.body/camel:ognl
!-- (1) Call the service to save the request message
--
camel:bean ref=serviceHelper
method=createRequestMessage/
!-- (2) Validate the business message --
camel:bean ref=serviceHelper
method=validateRequestMessage/
!-- (3) Save business message --
camel:bean ref=serviceHelper
method=saveRequestMessage/
/camel:split
public class x3sAggregationStrategy implements AggregationStrategy {
public Exchange aggregate(Exchange oldExchange, Exchange
newExchange)
{
List requestMessages = new ArrayList();
// Get old messages
requestMessages = oldExchange.getOut().getBody(List.class); //
=
LINE 18
// Get new and add it to the list
RequestMessage newReqMessage =
newExchange.getOut().getBody(RequestMessage.class);
requestMessages.add(newReqMessage);
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return newExchange;
}
}
I try to collect all the RequestMessage and put it in a collection
that I
will use after the split. How can I do that ?
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
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Strange behaviour with camel and JMS queues
Hi Claus, Claus Ibsen-2 wrote: I have newer seen a OutIn pattern before? Are you sure its not InOut? You could try with a simpler route, eg without all the processing to see if it works with a simple from(jms)-to(jms) Maybe something happens during the processing that breaks something. By default a JMS consumer is InOnly if the JMSReplyTo message it consumes is empty/null. So the InOnly should not be needed. But maybe your processing code changes the pattern from InOnly to something else. I'll let you know once I've done additional testing, but it does print out OutIn in my console?! Claus Ibsen-2 wrote: Second issue relates to the number of consumers started by camel When upgrading from camel 1.6 to camel 1.6.1 I noticed that all of a sudden I had 2 consumers for each JMS queue despite the fact that I do specify that I only want one consumer??? bean id=jmsConfig class=org.apache.camel.component.jms.JmsConfiguration property name=connectionFactory ref=jmsFactory/ property name=transactionManager ref=jmsTransactionManager/ property name=transacted value=true/ property name=concurrentConsumers value=1/ /bean Any idea what causing this strange behavior? And does anybody know how to fix these issues? You are the first to report something about having multiple consumers. Maybe you route is being loaded twice? I think you are correct it seems to the camel routes twice, actually I think the camel context is loaded twice. See logging below. Do you need an example project for this? or is it a known issue? 16/06/2009 11:24:34 org.apache.camel.impl.DefaultCamelContext start INFO: Apache Camel (CamelContext:camel) started 16/06/2009 11:24:34 org.springframework.web.context.ContextLoader initWebApplicationContext INFO: Root WebApplicationContext: initialization completed in 8181 ms 16/06/2009 11:24:34 org.apache.catalina.core.ApplicationContext log INFO: Initializing Spring FrameworkServlet 'spring' 16/06/2009 11:24:34 org.springframework.web.servlet.FrameworkServlet initServletBean INFO: FrameworkServlet 'spring': initialization started 16/06/2009 11:24:34 org.springframework.context.support.AbstractApplicationContext prepareRefresh INFO: Refreshing org.springframework.web.context.support.xmlwebapplicationcont...@1a41860: display name [WebApplicationContext for namespace 'spring-servlet']; startup date [Tue Jun 16 11:24:34 CEST 2009]; parent: org.springframework.web.context.support.xmlwebapplicationcont...@19ce47a 16/06/2009 11:24:34 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions INFO: Loading XML bean definitions from ServletContext resource [/WEB-INF/spring-servlet.xml] 16/06/2009 11:24:34 org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory INFO: Bean factory for application context [org.springframework.web.context.support.xmlwebapplicationcont...@1a41860]: org.springframework.beans.factory.support.defaultlistablebeanfact...@1f106ab 16/06/2009 11:24:34 org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@1f106ab: defining beans []; parent: org.springframework.beans.factory.support.defaultlistablebeanfact...@40bf04 16/06/2009 11:24:34 org.apache.camel.impl.DefaultCamelContext start INFO: Apache Camel (CamelContext:camel) started Tim -- View this message in context: http://www.nabble.com/Strange-behaviour-with-camel-and-JMS-queues-tp24037119p24051738.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Strange behaviour with camel and JMS queues
On Tue, Jun 16, 2009 at 12:40 PM, Tim83tim.str...@roots.be wrote: Hi Claus, Claus Ibsen-2 wrote: I have newer seen a OutIn pattern before? Are you sure its not InOut? You could try with a simpler route, eg without all the processing to see if it works with a simple from(jms)-to(jms) Maybe something happens during the processing that breaks something. By default a JMS consumer is InOnly if the JMSReplyTo message it consumes is empty/null. So the InOnly should not be needed. But maybe your processing code changes the pattern from InOnly to something else. I'll let you know once I've done additional testing, but it does print out OutIn in my console?! Claus Ibsen-2 wrote: Second issue relates to the number of consumers started by camel When upgrading from camel 1.6 to camel 1.6.1 I noticed that all of a sudden I had 2 consumers for each JMS queue despite the fact that I do specify that I only want one consumer??? bean id=jmsConfig class=org.apache.camel.component.jms.JmsConfiguration property name=connectionFactory ref=jmsFactory/ property name=transactionManager ref=jmsTransactionManager/ property name=transacted value=true/ property name=concurrentConsumers value=1/ /bean Any idea what causing this strange behavior? And does anybody know how to fix these issues? You are the first to report something about having multiple consumers. Maybe you route is being loaded twice? I think you are correct it seems to the camel routes twice, actually I think the camel context is loaded twice. See logging below. Do you need an example project for this? or is it a known issue? Ah I think we have it reported already. See this ticket: http://issues.apache.org/activemq/browse/CAMEL-1711 So you are running Camel as a spring web application? What container are you using? 16/06/2009 11:24:34 org.apache.camel.impl.DefaultCamelContext start INFO: Apache Camel (CamelContext:camel) started 16/06/2009 11:24:34 org.springframework.web.context.ContextLoader initWebApplicationContext INFO: Root WebApplicationContext: initialization completed in 8181 ms 16/06/2009 11:24:34 org.apache.catalina.core.ApplicationContext log INFO: Initializing Spring FrameworkServlet 'spring' 16/06/2009 11:24:34 org.springframework.web.servlet.FrameworkServlet initServletBean INFO: FrameworkServlet 'spring': initialization started 16/06/2009 11:24:34 org.springframework.context.support.AbstractApplicationContext prepareRefresh INFO: Refreshing org.springframework.web.context.support.xmlwebapplicationcont...@1a41860: display name [WebApplicationContext for namespace 'spring-servlet']; startup date [Tue Jun 16 11:24:34 CEST 2009]; parent: org.springframework.web.context.support.xmlwebapplicationcont...@19ce47a 16/06/2009 11:24:34 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions INFO: Loading XML bean definitions from ServletContext resource [/WEB-INF/spring-servlet.xml] 16/06/2009 11:24:34 org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory INFO: Bean factory for application context [org.springframework.web.context.support.xmlwebapplicationcont...@1a41860]: org.springframework.beans.factory.support.defaultlistablebeanfact...@1f106ab 16/06/2009 11:24:34 org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@1f106ab: defining beans []; parent: org.springframework.beans.factory.support.defaultlistablebeanfact...@40bf04 16/06/2009 11:24:34 org.apache.camel.impl.DefaultCamelContext start INFO: Apache Camel (CamelContext:camel) started Tim -- View this message in context: http://www.nabble.com/Strange-behaviour-with-camel-and-JMS-queues-tp24037119p24051738.html Sent from the Camel - Users 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
Information required about IN/OUT pattern of splitter EIP
Hi,
I'm a little confused about the split EIP pattern combined with aggregation
strategy. In the example (see http://camel.apache.org/splitter.html - Split
aggregate request/reply sample), the out exchange is used to retrieved the
body content and also to set it because the pattern is of type InOut.
I have created an aggregator but in my case, I must use the content of the
In to retrieve my body
List requestMessages = new ArrayList();
if (oldExchange == null) {
requestMessages.add(newExchange.getIn().getBody(RequestMessage.class));
newExchange.getOut().setBody(requestMessages);
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getIn().getBody(List.class);
// Get new and add it to the list
requestMessages.add(newExchange.getOut().getBody(RequestMessage.class));
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return oldExchange;
}
Questions :
- Is the split EIP an InOut pattern ?
- When I develop the aggregator like this, the headers of my messages have
disappeared when the endpoint called after the end of the split receives the
List of Objects. How can I avoid this ?
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
Avoiding type conversions with the direct component
Hi there, Quick (probably dumb) question. I'm looking to avoid a type conversion while using the direct: component. I've been of the opinion that using the direct: component is a nice way to break up my routes into nicely separated chunks. However I now find that sending a body with one of my (large) POJOs takes several seconds. Having profiled things I see that there is a NoTypeConversionAvailableException and then the stack trace shows that the object is being converted to a string, which then goes on to call a lot of JSON code I have. Here's a sample of the stack trace: ... com.classactionpl.gml.Feature.toString() java.lang.String.valueOf(Object) java.lang.StringBuilder.append(Object) org.apache.camel.NoTypeConversionAvailableException.(Object, Class) org.apache.camel.impl.converter.DefaultTypeConverter.doConvertTo(Class, Exchange, Object) org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(Class, Exchange, Object) org.apache.camel.impl.MessageSupport.getBody(Class, Object) org.apache.camel.impl.MessageSupport.getBody(Class) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback, DeadLetterChannel$RedeliveryData) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback) org.apache.camel.processor.Pipeline.process(Exchange, Exchange, AsyncCallback, Iterator, AsyncProcessor) org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, AsyncCallback) org.apache.camel.component.direct.DirectProducer.process(Exchange, AsyncCallback) org.apache.camel.processor.SendProcessor.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback, DeadLetterChannel$RedeliveryData) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback) org.apache.camel.processor.Pipeline.process(Exchange, Exchange, AsyncCallback, Iterator, AsyncProcessor) org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, AsyncCallback) org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessor, Exchange) org.apache.camel.processor.DelegateAsyncProcessor.process(Exchange) org.apache.camel.processor.loadbalancer.QueueLoadBalancer.process(Exchange) org.apache.camel.component.quartz.QuartzEndpoint.onJobExecute(JobExecutionContext) org.apache.camel.component.quartz.CamelJob.execute(JobExecutionContext) org.quartz.core.JobRunShell.run() org.quartz.simpl.SimpleThreadPool$WorkerThread.run() Any recommendations on how I should avoid this conversion? Kind regards, Christopher -- View this message in context: http://www.nabble.com/Avoiding-type-conversions-with-the-direct-component-tp24053271p24053271.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Why reference to bean methods called are not displayed in the log of camel for split
Hi,
Here is a snapshot of the log (mode INFO) generated during a split process.
As you can see, no reference to the method of my beans called during split
is displayed except when we left the split :
*BEFORE CALLING SPLIT*
13:36:08,328 | INFO | enerContainer-28 | TraceInterceptor |
rg.apache.camel.processor.Logger 88 |
ID-dell-charles-1745-1245080089715-2-62 *bean(ref: serviceHelper method:
parseRequest) *-- choice(request.headers.requestStatus = 'ACCEPTED',
request.headers.requestStatus = 'REJECTED'), Pattern:InOnly,
Properties:{CamelBeanHolder=bean: serviceHelper},
Headers:{requestStatus=ACCPT, requestId=15, messageType=OINP},
BodyType:java.util.ArrayList
*SPLIT IS CALLED*
13:36:08,343 | INFO | enerContainer-28 | TraceInterceptor |
rg.apache.camel.processor.Logger 88 |
ID-dell-charles-1745-1245080089715-2-62 split(request.body) --
split(request.body), Pattern:InOnly, Properties:{CamelBeanHolder=bean:
serviceHelper}, Headers:{requestStatus=ACCEPTED, CamelMulticastIndex=0,
requestId=15, CamelSplitSize=1, messageType=OINP, CamelSplitIndex=0},
BodyType:java.util.HashMap,
Body:{com.xpectis.x3s.model.backoffice.emx.oinp.in.inoinpmessage=com.xpectis.x3s.model.backoffice.emx.oinp.in.inoinpmess...@db6129
}
13:36:08,359 | INFO | enerContainer-28 | TraceInterceptor |
rg.apache.camel.processor.Logger 88 |
ID-dell-charles-1745-1245080089715-2-62 split(request.body) --
split(request.body), Pattern:InOnly, Properties:{CamelBeanHolder=bean:
serviceHelper}, Headers:{requestStatus=ACCEPTED, CamelMulticastIndex=0,
requestId=15, CamelSplitSize=1, CamelBeanMultiParameterArray=false,
messageType=OINP, CamelBeanMethodName=null, CamelSplitIndex=0},
BodyType:com.xpectis.x3s.platform.model.RequestMessage,
Body:com.xpectis.x3s.platform.model.requestmess...@6de7e3
13:36:08,390 | INFO | enerContainer-28 | TraceInterceptor |
rg.apache.camel.processor.Logger 88 |
ID-dell-charles-1745-1245080089715-2-62 split(request.body) --
split(request.body), Pattern:InOnly, Properties:{CamelBeanHolder=bean:
serviceHelper}, Headers:{requestId=15, messageType=OINP,
validationresult=com.xpectis.x3s.model.holder.validationresulthol...@1d9e15},
BodyType:com.xpectis.x3s.platform.model.RequestMessage,
Body:com.xpectis.x3s.platform.model.requestmess...@6de7e3
*SPLIT IS FINISHED*
13:36:08,531 | INFO | enerContainer-28 | TraceInterceptor |
rg.apache.camel.processor.Logger 88 |
ID-dell-charles-1745-1245080089715-2-62 *split(request.body) --
bean(ref: serviceHelper method: updateRequestStatus*), Pattern:InOnly,
Properties:{CamelBeanHolder=bean: serviceHelper},
BodyType:java.util.ArrayList,
Body:[com.xpectis.x3s.platform.model.requestmess...@6de7e3]
It should be nice to have such info in the log
Here is the route :
camel:from ref=directRequestMessageEndpoint /
!-- Split the collection of messages --
camel:split strategyRef=aggregationStrat
camel:ognlrequest.body/camel:ognl
!-- (1) Call the service to save the request message --
camel:bean ref=serviceHelper
method=createRequestMessage/
!-- (2) Validate the business message --
camel:bean ref=serviceHelper
method=validateRequestMessage/
!-- (3) Save business message --
camel:bean ref=serviceHelper
method=saveRequestMessage/
/camel:split
!-- Update Request status --
camel:bean ref=serviceHelper method=updateRequestStatus /
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
Re: Avoiding type conversions with the direct component
Hi Its the stream cache that forces this. Use the google search bar to search for stream cache and see how to disable it. On Tue, Jun 16, 2009 at 2:26 PM, huntchu...@mac.com wrote: Hi there, Quick (probably dumb) question. I'm looking to avoid a type conversion while using the direct: component. I've been of the opinion that using the direct: component is a nice way to break up my routes into nicely separated chunks. However I now find that sending a body with one of my (large) POJOs takes several seconds. Having profiled things I see that there is a NoTypeConversionAvailableException and then the stack trace shows that the object is being converted to a string, which then goes on to call a lot of JSON code I have. Here's a sample of the stack trace: ... com.classactionpl.gml.Feature.toString() java.lang.String.valueOf(Object) java.lang.StringBuilder.append(Object) org.apache.camel.NoTypeConversionAvailableException.(Object, Class) org.apache.camel.impl.converter.DefaultTypeConverter.doConvertTo(Class, Exchange, Object) org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(Class, Exchange, Object) org.apache.camel.impl.MessageSupport.getBody(Class, Object) org.apache.camel.impl.MessageSupport.getBody(Class) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback, DeadLetterChannel$RedeliveryData) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback) org.apache.camel.processor.Pipeline.process(Exchange, Exchange, AsyncCallback, Iterator, AsyncProcessor) org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, AsyncCallback) org.apache.camel.component.direct.DirectProducer.process(Exchange, AsyncCallback) org.apache.camel.processor.SendProcessor.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback, DeadLetterChannel$RedeliveryData) org.apache.camel.processor.DeadLetterChannel.process(Exchange, AsyncCallback) org.apache.camel.processor.Pipeline.process(Exchange, Exchange, AsyncCallback, Iterator, AsyncProcessor) org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) org.apache.camel.management.InstrumentationProcessor.process(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, AsyncCallback) org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, AsyncCallback) org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, AsyncCallback) org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessor, Exchange) org.apache.camel.processor.DelegateAsyncProcessor.process(Exchange) org.apache.camel.processor.loadbalancer.QueueLoadBalancer.process(Exchange) org.apache.camel.component.quartz.QuartzEndpoint.onJobExecute(JobExecutionContext) org.apache.camel.component.quartz.CamelJob.execute(JobExecutionContext) org.quartz.core.JobRunShell.run() org.quartz.simpl.SimpleThreadPool$WorkerThread.run() Any recommendations on how I should avoid this conversion? Kind regards, Christopher -- View this message in context: http://www.nabble.com/Avoiding-type-conversions-with-the-direct-component-tp24053271p24053271.html Sent from the Camel - Users (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: Avoiding type conversions with the direct component
On Tue, Jun 16, 2009 at 2:58 PM, huntchu...@mac.com wrote: Yes, it looks as though it is the stream cache, but what's interesting is that you can't disable the stream cache if you're using the default error handler: http://www.nabble.com/Re%3A-StreamCaching-in-Camel-1.6-to22305858.html So you've effectively got to disable the error handler for a route if you don't want to use the stream cache. This seems kind of awkward... does Camel 2.0 improve this situation? Yes we will disable StreamCache by default in Camel 2.0 and add a option to enable it per route. Then if people uses stream then they can enable the cache on demand in case they want to let Camel be able to error handling with redeliveris (as it need to read the stream more than once) or content based routing where you also need to read the content. -- View this message in context: http://www.nabble.com/Avoiding-type-conversions-with-the-direct-component-tp24053271p24053805.html Sent from the Camel - Users (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: Information required about IN/OUT pattern of splitter EIP
[15:59] cibsen chm007 its because of using AggregatorStrategy is
very low level
[15:59] cibsen you work on Exchange directly
[15:59] cibsen and it depends on how many processing steps you have
in the split sub route
[15:59] cibsen 1 = OUT
[15:59] cibsen 2+ = IN as Camel will use a Pipeline under the converers
[15:59] cibsen so Camel will do a OUT - IN in the next processor
[15:59] cibsen so OUT - IN to the AggregatorStrategy also
[15:59] cibsen its a bit confusing
[16:00] cibsen will be better when you can use a POJO for aggregation
On Tue, Jun 16, 2009 at 2:11 PM, Charles Moulliardcmoulli...@gmail.com wrote:
Hi,
I'm a little confused about the split EIP pattern combined with aggregation
strategy. In the example (see http://camel.apache.org/splitter.html - Split
aggregate request/reply sample), the out exchange is used to retrieved the
body content and also to set it because the pattern is of type InOut.
I have created an aggregator but in my case, I must use the content of the
In to retrieve my body
List requestMessages = new ArrayList();
if (oldExchange == null) {
requestMessages.add(newExchange.getIn().getBody(RequestMessage.class));
newExchange.getOut().setBody(requestMessages);
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getIn().getBody(List.class);
// Get new and add it to the list
requestMessages.add(newExchange.getOut().getBody(RequestMessage.class));
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return oldExchange;
}
Questions :
- Is the split EIP an InOut pattern ?
- When I develop the aggregator like this, the headers of my messages have
disappeared when the endpoint called after the end of the split receives the
List of Objects. How can I avoid this ?
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
Re: Information required about IN/OUT pattern of splitter EIP
What do you mean by 1 = OUT, 2+ = IN ?
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Tue, Jun 16, 2009 at 4:03 PM, Claus Ibsen claus.ib...@gmail.com wrote:
[15:59] cibsen chm007 its because of using AggregatorStrategy is
very low level
[15:59] cibsen you work on Exchange directly
[15:59] cibsen and it depends on how many processing steps you have
in the split sub route
[15:59] cibsen 1 = OUT
[15:59] cibsen 2+ = IN as Camel will use a Pipeline under the converers
[15:59] cibsen so Camel will do a OUT - IN in the next processor
[15:59] cibsen so OUT - IN to the AggregatorStrategy also
[15:59] cibsen its a bit confusing
[16:00] cibsen will be better when you can use a POJO for aggregation
On Tue, Jun 16, 2009 at 2:11 PM, Charles Moulliardcmoulli...@gmail.com
wrote:
Hi,
I'm a little confused about the split EIP pattern combined with
aggregation
strategy. In the example (see http://camel.apache.org/splitter.html -
Split
aggregate request/reply sample), the out exchange is used to retrieved
the
body content and also to set it because the pattern is of type InOut.
I have created an aggregator but in my case, I must use the content of
the
In to retrieve my body
List requestMessages = new ArrayList();
if (oldExchange == null) {
requestMessages.add(newExchange.getIn().getBody(RequestMessage.class));
newExchange.getOut().setBody(requestMessages);
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getIn().getBody(List.class);
// Get new and add it to the list
requestMessages.add(newExchange.getOut().getBody(RequestMessage.class));
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return oldExchange;
}
Questions :
- Is the split EIP an InOut pattern ?
- When I develop the aggregator like this, the headers of my messages
have
disappeared when the endpoint called after the end of the split receives
the
List of Objects. How can I avoid this ?
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
Re: Information required about IN/OUT pattern of splitter EIP
On Tue, Jun 16, 2009 at 4:10 PM, Charles Moulliardcmoulli...@gmail.com wrote:
What do you mean by 1 = OUT, 2+ = IN ?
Number of processors you have in the route. eg = the number of to
uri=xxx/ you have
1 =
split
to uri=foo/
/split
2+ =
split
to uri=foo/
to uri=bar/
to uri=baz/
/split
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Tue, Jun 16, 2009 at 4:03 PM, Claus Ibsen claus.ib...@gmail.com wrote:
[15:59] cibsen chm007 its because of using AggregatorStrategy is
very low level
[15:59] cibsen you work on Exchange directly
[15:59] cibsen and it depends on how many processing steps you have
in the split sub route
[15:59] cibsen 1 = OUT
[15:59] cibsen 2+ = IN as Camel will use a Pipeline under the converers
[15:59] cibsen so Camel will do a OUT - IN in the next processor
[15:59] cibsen so OUT - IN to the AggregatorStrategy also
[15:59] cibsen its a bit confusing
[16:00] cibsen will be better when you can use a POJO for aggregation
On Tue, Jun 16, 2009 at 2:11 PM, Charles Moulliardcmoulli...@gmail.com
wrote:
Hi,
I'm a little confused about the split EIP pattern combined with
aggregation
strategy. In the example (see http://camel.apache.org/splitter.html -
Split
aggregate request/reply sample), the out exchange is used to retrieved
the
body content and also to set it because the pattern is of type InOut.
I have created an aggregator but in my case, I must use the content of
the
In to retrieve my body
List requestMessages = new ArrayList();
if (oldExchange == null) {
requestMessages.add(newExchange.getIn().getBody(RequestMessage.class));
newExchange.getOut().setBody(requestMessages);
return newExchange;
} else {
// Get old messages
requestMessages = oldExchange.getIn().getBody(List.class);
// Get new and add it to the list
requestMessages.add(newExchange.getOut().getBody(RequestMessage.class));
// Add to the exchange
oldExchange.getOut().setBody(requestMessages);
return oldExchange;
}
Questions :
- Is the split EIP an InOut pattern ?
- When I develop the aggregator like this, the headers of my messages
have
disappeared when the endpoint called after the end of the split receives
the
List of Objects. How can I avoid this ?
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
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Consuming advisory messages in camel.
On Tue, Jun 16, 2009 at 4:34 PM, Eric Bouerericbo...@gmail.com wrote: Thanks Claus. This appears to be a very minor issue and not a problem as I thought it was, I was looking for direct access to AdvisorySupport Like I do with traditional AMQ client: Destination advisoryDestination = AdvisorySupport.getProducerAdvisoryTopic(destination) Spring JMS is a solution, I'm wondering if there is another more integrated way of doing so. There is a camel-activemq.jar to be used from Camel to use activemq over the generic camel-jms.jar So its possible to add features to this .jar for the advisory. However this .jar is in the AMQ project so I think you should get in touch with this project as well. To get their views on this. Claus Ibsen-2 wrote: On Thu, Jun 11, 2009 at 4:43 PM, Eric Bouerericbo...@gmail.com wrote: Hello. I can't figure out how to consume advisory messges in camel. Using simple java code I would use AdvisoryConsumer that can provide me details about the advisory message (Advisory type). Simply consuming from(activemq:topic:ActiveMQ.Advisory.Producer.Queue.MyQueue).to(someprocess()) doesn't help me figure out the Advisory type. Is it supported ? Hi What happens when you consume this advisor queue? Camel is basically just leveraging Spring JMS. So if you could get it to work with plain Spring JMS then we have something to look into. But to my knowledge there is no special code in there to support Advisory. Thanks. -- View this message in context: http://www.nabble.com/Consuming-advisory-messages-in-camel.-tp23982716p23982716.html Sent from the Camel - Users (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 -- View this message in context: http://www.nabble.com/Consuming-advisory-messages-in-camel.-tp23982716p24055681.html Sent from the Camel - Users (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
JBoss + ActiveMQ + Camel + Newbie
Hello forum, I am a newbie to ActiveMQ and Camel and I have a few questions which I am unable to fathom out myself. Firstly I will explain what I am trying to achieve. I need to create a messaging system over internet protocols. The messages need to be filtered based on content and sent to the appropiate Queue/Topic. I want to use ActiveMQ as my messaging provider and Camel to do the filtering/re-routing etc... All this then needs to sit in JBoss. A client application will connect to the Queues/Topics and download the messages. In time this will also need to send messages back to the server. I have ActiveMQ installed in JBoss 4.2.2.GA and it works fine. How do I get intergrate Camel into it? I understand that this is already included in ActiveMQ but I can't see how to control Camel routing. I created an MBean to sit in JBoss and configure a simple routing based on some example code from the fuse project. I have noticed that this uses CamelContext.start(). I don't want the MBean to do this, I want JBoss to start this up. When this is called I get multiple exception messages, one of which is: Failed to start ActiveMQ JMS Message Broker. Reason: javax.management.InstanceAlreadyExistsException: JBoss has already started ActiveMQ! I never wanted Camel to start it also. Is there a way of attaching Camel to the current ActiveMQ broker? I appologies if this is confusing, like I say I am a newbie and maybe barking up the wrong tree. Best Regards Chris Mitchell -- View this message in context: http://www.nabble.com/JBoss-%2B-ActiveMQ-%2B-Camel-%2B-Newbie-tp24056976p24056976.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Autowiring RouteBuilders defined as beans in Spring.
How about just allowing a class to be specified in the package scan? Some
kind of ContextAware scan handler that could process arbitrary classes? It
would be similar in many ways to a BeanPostProcessor and could default to
scanning for routes e.g.
packageScan
scanhandlerorg.apache.camel.scan.ComponentScanHandler/scanhandler
/packageScan
with an interface along the lines of
public interface ScanHandler{
public void processDiscoveredClasses(SetClass matching);
// or even with instantiated instances
public void processDiscoveredInstances(SetT matchingInstances);
}
Claus Ibsen-2 wrote:
On Mon, Jun 15, 2009 at 4:31 AM, Willem Jiangwillem.ji...@gmail.com
wrote:
Hi Stephen,
Claus created a same requirement[1] as yours, but I like your scanner
with exclude and include option more :)
Yeah Stephens works is really cool.
Now that we are into changing the DSL for route builder I have thought
of introducing a uber tag for that
As you can configure route builders as either a reference
rouuteBuilder or using the scanner packageScan.
routeBuilders
packageScan
...
/packageScan
routeBuilder ref=foo/
/routeBuilders
But this requires an extra XML tag and it makes the configuration a
bit more verbose.
And I guess its uncommon to use the combo of scanner and routeBuilder
ref together?
Thanks for your contribution.
[1]https://issues.apache.org/activemq/browse/CAMEL-1695
Willem
sgargan wrote:
Claus,
I've made a patch to allow the Ant like inclusion and exclusion you
suggested. I've opened an improvement Jira ticket for it with a patch
https://issues.apache.org/activemq/browse/CAMEL-1708.
Please shout if there is anything you'd like changed with it.
thx
ste
sgargan wrote:
Cheers Claus. The ant exclusions sound like a good idea. Let me take a
look at what that would involve.
thx for your help,
ste
Claus Ibsen-2 wrote:
On Wed, Jun 10, 2009 at 10:42 PM, sgargansgar...@qualcomm.com wrote:
In the 1.6 codeline it was possible to define routebuilders as beans
in
a
Spring context and have them wired into the camel context upon
intialization
e.g.
bean id=simpleHttpRoute class=org.simple.SimpleHttpToFileRoute
/
This bean would have been added to the context when the following
block
of
code in in the installRoutes method of the CamelContextFactoryBean
was
executed
protected void installRoutes() throws Exception {
if (autowireRouteBuilders != null
autowireRouteBuilders.booleanValue()) {
Map builders =
getApplicationContext().getBeansOfType(RouteBuilder.class, true,
true);
if (builders != null) {
for (Object builder : builders.values()) {
getContext().addRoutes((RouteBuilder) builder);
}
}
}
In the 2.0 codeline, this section has been removed (as part of a fix
for
the
following issue/feature http://bit.ly/n6ojs ) and the context defined
routes
do not get added. I was wondering what the reason was for dropping
this?
Was
it considered harmful?
You can use the routeBuilder ref=simpleHttpRoute/ in
camelContext.
Yes it was considered to magical. What if you have 2 camel contextes
then they would both
load up all the route builders they could find as spring beans.
And for users coming in to maintain the code would not be able to
figure
out
how the routes are kick started.
Yet alone the package could be a bit difficult to understand.
That reminds me, maybe if it was named package-scan it would be easier
to hint that.
I know the package scan can be used to initialise RouteBuilders it
finds
in
packages, but it can be annoying to exclude routes from this
mechanism,
for
instance where you have test RouteBuilders that happen to live in the
same
package in the test src tree, or where there are routes that
complicate
testing with setup and noise. Also in situations where you configure
the
RouteBean explicitly e.g. to inject values from properties files, it
is
much
cleaner to define the routes as beans.
I have been wondering if we should add ANT files matcher here as well,
so you can
specify includes/excludes as well.
Short of adding my own CamelContextAwareBean to do the same, Is there
a
different mechanism to do setup Routes this way?
Yes the routeBuilder ref tag.
Thanks in advance
Stephen.
--
View this message in context:
http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p23970613.html
Sent from the Camel - Users 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
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
View this message in context:
Getting camel's activemq: endpoints to work with Spring's flex-spring integration
Spring-Flex has a simplified way to get blazeds to find jms topics for things using Spring's JMS templates. Since (as far as I know) camel uses spring's jms templates, this should work well with camel. http://static.springframework.org/spring-flex/docs/1.0.x/reference/html/ch05s04.html is where it is documented. They say: --- For integration with JMS, a special JmsAdapter is provided that internally makes use of Spring's JmsTemplate, DestinationResolver,DefaultMessageListenerContainer and other such JMS abstractions for simplified interaction with JMS resources. The jms- message-destination XML namespace tag is used to expose JMS destinations as BlazeDS message destinations. The minimal attributes that must be specified are the destination id and exactly one of jms- destination, queue-name, or topic-name. A JMS ConnectionFactory reference is also required, but does not have to be explicitly specified if there is already one configured in the current application context with an id of connectionFactory. For example, to configure a BlazeDS message destination named chatIn that uses a Spring-managed ActiveMQ JMS queue with a local ActiveMQ installation: bean id=connectionFactory class=org.apache.activemq.ActiveMQConnectionFactory property name=brokerURL value=tcp://localhost:61616/ /bean bean id=chatInQueue class=org.apache.activemq.command.ActiveMQQueue constructor-arg value=queue.flex.chat.in/ /bean flex:jms-message-destination id=chatIn jms- destination=chatInQueue / Using queue-name or topic-name will cause the destination to be resolved using a Spring DestinationResolver. The destination-resolver, message-converter, and transaction-manager attributes may be used to set custom references to a Spring-managed DestinationResolver, MessageConverter, or TransactionManager respectively. It would seem that I should be able to do something like this: ... amq:connectionFactory id=jmsFactory brokerURL=vm://localhost/ ... flex:jms-message-destination id=someDestinationID jms- destination=fooTopic connectionFactory=jmsFactory / And then this should use springs default destination resolvers to find something being posted to my activemq:fooTopic endpoint? I'm going to try it this way and see how it works, but figured I'd post this question to see if I have some horribly wrong understanding of how this should work. Ryan
Re: Autowiring RouteBuilders defined as beans in Spring.
On Tue, Jun 16, 2009 at 10:21 PM, sgargan sgar...@qualcomm.com wrote:
I've put together some documentation for the feature, its not much. Claus
mentioned some kind of karma(?) to allow me to edit the confluence pages.
If you'd prefer I can just mail it to one of you, though I don't mind
adding
it. Just state a preference.
Hi
To get karma you need to create an account on the wiki pages. Just click
edit in the bottom of any of the camel
html wiki pages. Then state your username in a mail on this forum and I will
be able to grant your edit rights (= karma).
Cheers
ste
willem.jiang wrote:
Hi Stephen,
Claus created a same requirement[1] as yours, but I like your scanner
with exclude and include option more :)
Thanks for your contribution.
[1]https://issues.apache.org/activemq/browse/CAMEL-1695
Willem
sgargan wrote:
Claus,
I've made a patch to allow the Ant like inclusion and exclusion you
suggested. I've opened an improvement Jira ticket for it with a patch
https://issues.apache.org/activemq/browse/CAMEL-1708.
Please shout if there is anything you'd like changed with it.
thx
ste
sgargan wrote:
Cheers Claus. The ant exclusions sound like a good idea. Let me take a
look at what that would involve.
thx for your help,
ste
Claus Ibsen-2 wrote:
On Wed, Jun 10, 2009 at 10:42 PM, sgargansgar...@qualcomm.com
wrote:
In the 1.6 codeline it was possible to define routebuilders as beans
in
a
Spring context and have them wired into the camel context upon
intialization
e.g.
bean id=simpleHttpRoute class=org.simple.SimpleHttpToFileRoute
/
This bean would have been added to the context when the following
block
of
code in in the installRoutes method of the CamelContextFactoryBean
was
executed
protected void installRoutes() throws Exception {
if (autowireRouteBuilders != null
autowireRouteBuilders.booleanValue()) {
Map builders =
getApplicationContext().getBeansOfType(RouteBuilder.class, true,
true);
if (builders != null) {
for (Object builder : builders.values()) {
getContext().addRoutes((RouteBuilder) builder);
}
}
}
In the 2.0 codeline, this section has been removed (as part of a fix
for
the
following issue/feature http://bit.ly/n6ojs ) and the context
defined
routes
do not get added. I was wondering what the reason was for dropping
this?
Was
it considered harmful?
You can use the routeBuilder ref=simpleHttpRoute/ in
camelContext.
Yes it was considered to magical. What if you have 2 camel contextes
then they would both
load up all the route builders they could find as spring beans.
And for users coming in to maintain the code would not be able to
figure
out
how the routes are kick started.
Yet alone the package could be a bit difficult to understand.
That reminds me, maybe if it was named package-scan it would be easier
to hint that.
I know the package scan can be used to initialise RouteBuilders it
finds
in
packages, but it can be annoying to exclude routes from this
mechanism,
for
instance where you have test RouteBuilders that happen to live in the
same
package in the test src tree, or where there are routes that
complicate
testing with setup and noise. Also in situations where you configure
the
RouteBean explicitly e.g. to inject values from properties files, it
is
much
cleaner to define the routes as beans.
I have been wondering if we should add ANT files matcher here as well,
so you can
specify includes/excludes as well.
Short of adding my own CamelContextAwareBean to do the same, Is there
a
different mechanism to do setup Routes this way?
Yes the routeBuilder ref tag.
Thanks in advance
Stephen.
--
View this message in context:
http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p23970613.html
Sent from the Camel - Users 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
--
View this message in context:
http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p24062126.html
Sent from the Camel - Users 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
