Re: Problem from Camelcontext close after poolingconnection,transactionmanager and datasource
Ok I saw a new post by greenstar http://old.nabble.com/Camel%2C-Spring-and-Initialization-to28113566.html http://old.nabble.com/Camel%2C-Spring-and-Initialization-to28113566.html And now he open new issue here https://issues.apache.org/activemq/browse/CAMEL-2610 https://issues.apache.org/activemq/browse/CAMEL-2610 I not sure in my case ( http://old.nabble.com/Problem-from-Camelcontext-close-after-poolingconnection%2Ctransactionmanager-and-datasource-to28095558.html http://old.nabble.com/Problem-from-Camelcontext-close-after-poolingconnection%2Ctransactionmanager-and-datasource-to28095558.html ) will match with this case or its come from camel-ibatis polling consumer. Maybe next upgrade will come out with "" and woke fine with innit and destroy sequence. I looking forward to next release :-). If you have any information about my case please tell me. Thank you so much. -- View this message in context: http://old.nabble.com/Problem-from-Camelcontext-close-after-poolingconnection%2Ctransactionmanager-and-datasource-tp28095558p28124718.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message blocks route until all redelivery attempts are exhausted
Hi,
Can you try to add this option "concurrentConsumers=5" into the seda
endpoint's URI?
By default there is only one thread to consumer the message in the queue.
Willem
Dragisa Krsmanovic wrote:
I have a route that is configured to re-deliver messages on exception.
If there are messages in that queue and one of them fails, all other
messages are blocked until all re-delivery attempts are exhausted.
I would like other messages to go through while the ones that failed are
waiting for their re-delivery. Message order is not important. What is a
good way to do this ?
The route I tested with looks like this:
from("seda:start")
.onException(Exception.class)
.handled(true)
.redeliverDelay(100)
.maximumRedeliveries(1)
.to("mock:error")
.end()
.process(new TestProcessor())
.to("mock:end");
--
This email is confidential to the intended recipient. If you have received it
in error, please notify the sender and delete it from your
system. Any unauthorized use, disclosure or copying is not permitted. The views
or opinions presented are solely those of the sender and do
not necessarily represent those of Public Library of Science unless otherwise
specifically stated. Please note that neither Public Library
of Science nor any of its agents accept any responsibility for any viruses that
may be contained in this e-mail or its attachments and it
is your responsibility to scan the e-mail and attachments (if any).
Re: What is difference between redeliverDelay() and redeliveryDelay() ?
Hi, The redeliverDelay should be deprecated as it's a typo, if you take a look at the code, they are doing the same thing. So you just need to use redeliveryDelay(long delay). Willem Dragisa Krsmanovic wrote: In OnExceptionDefinition there are two methods with very similar name: redeliverDelay and redeliveryDelay. This is what javadoc says: redeliverDelay(long delay) : Sets the delay redeliveryDelay(long delay) : Sets the fixed delay between redeliveries Which one should I use ? -- This email is confidential to the intended recipient. If you have received it in error, please notify the sender and delete it from your system. Any unauthorized use, disclosure or copying is not permitted. The views or opinions presented are solely those of the sender and do not necessarily represent those of Public Library of Science unless otherwise specifically stated. Please note that neither Public Library of Science nor any of its agents accept any responsibility for any viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any).
Message blocks route until all redelivery attempts are exhausted
I have a route that is configured to re-deliver messages on exception.
If there are messages in that queue and one of them fails, all other
messages are blocked until all re-delivery attempts are exhausted.
I would like other messages to go through while the ones that failed are
waiting for their re-delivery. Message order is not important. What is a
good way to do this ?
The route I tested with looks like this:
from("seda:start")
.onException(Exception.class)
.handled(true)
.redeliverDelay(100)
.maximumRedeliveries(1)
.to("mock:error")
.end()
.process(new TestProcessor())
.to("mock:end");
--
This email is confidential to the intended recipient. If you have received it
in error, please notify the sender and delete it from your
system. Any unauthorized use, disclosure or copying is not permitted. The views
or opinions presented are solely those of the sender and do
not necessarily represent those of Public Library of Science unless otherwise
specifically stated. Please note that neither Public Library
of Science nor any of its agents accept any responsibility for any viruses that
may be contained in this e-mail or its attachments and it
is your responsibility to scan the e-mail and attachments (if any).
What is difference between redeliverDelay() and redeliveryDelay() ?
In OnExceptionDefinition there are two methods with very similar name: redeliverDelay and redeliveryDelay. This is what javadoc says: redeliverDelay(long delay) : Sets the delay redeliveryDelay(long delay) : Sets the fixed delay between redeliveries Which one should I use ? -- This email is confidential to the intended recipient. If you have received it in error, please notify the sender and delete it from your system. Any unauthorized use, disclosure or copying is not permitted. The views or opinions presented are solely those of the sender and do not necessarily represent those of Public Library of Science unless otherwise specifically stated. Please note that neither Public Library of Science nor any of its agents accept any responsibility for any viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any).
ActiveMQ component and StreamMessage / BlobMessage
Hi all, from the Camel in Action book and online docs I see how objects get mapped to the corresponding JMS Message type. I saw that InputStream get mapped to ByteMessage. I wonder why its not using StreamMessage. Anyone knows why ? I thought use StreamMessages would give a real benifit when using big messages. The other thing I would like to see is be able to use BlobMessage when using ActiveMQ component. Is there any plan to support this ? Thx, Norman
Re: Camel, Spring and Initialization
Claus Ibsen-2 wrote: > > Could you create a ticket in JIRA to add depends-on attribute to > tag. > Done: https://issues.apache.org/activemq/browse/CAMEL-2610 Thanks. -- View this message in context: http://old.nabble.com/Camel%2C-Spring-and-Initialization-tp28113566p28120946.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
On Fri, Apr 2, 2010 at 3:55 PM, Christian Schneider
wrote:
> Could camel simply use spring el for properties?
>
No. Spring EL is an expression language and not a property placeholder
mechanism.
However there is a ticket in JIRA to add Spring EL as a Language to Camel.
Then you can use Spring EL in Camel predicates/expressions etc.
> Greetings
>
> Christian
>
>
> Am 02.04.2010 11:07, schrieb Claus Ibsen:
>>
>> Hi
>>
>> See ticket
>> https://issues.apache.org/activemq/browse/CAMEL-2599
>>
>> The problem is that Spring 3.0 includes a EL by default which is
>> automatic in use in the Spring XML files.
>> It uses the same tokens as we do with Camel Properties component and
>> therefore Spring EL fails with an exception.
>>
>> The easiest and also least problematic resolution is to use a
>> different tokens in Camel to avoid the clash.
>> It will also be least surprise by Camel end users if they mix and
>> match between Spring EL and Camel Properties.
>>
>> So what tokens do you want to use? Currently we did use
>> - prefix = #{
>> - suffix = }
>>
>> For example:
>> from("#{cool.start}")
>>
>> .to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
>> .to("mock:#{cool.result}");
>>
>>
>> A)
>> ===
>> I am thinking of changing to:
>> - prefix = #[
>> - suffix = ]
>>
>> For example:
>> from("#[cool.start]")
>>
>> .to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
>> .to("mock:#[cool.result]");
>>
>> B)
>> ===
>> Or maybe?
>> - prefix = #p{
>> - suffix = }
>>
>> For example:
>> from("#p{cool.start}")
>>
>>
>> .to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
>> .to("mock:#p{cool.result}");
>>
>>
>> C)
>>
>> We cannot do this one
>> - prefix = ${
>> - suffix = }
>>
>> As it will clash with Camel Simple language (would take more work to
>> let them co-exist in peace :)
>> However we could most likely use a longer preifx such as
>>
>> - prefix = ${p:
>> - suffix = }
>>
>> For example:
>> from("${p:cool.start}")
>>
>>
>> .to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
>> .to("mock:${p:cool.result}");
>>
>>
>> Do you have any thoughts and preference what tokens to use?
>>
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel, Spring and Initialization
On Fri, Apr 2, 2010 at 4:48 PM, greenstar wrote: > > > Claus Ibsen-2 wrote: >> >> The code to run before is that in the RouteBuilder class? Or is it >> defined as a spring bean etc.? >> > > It's defined as a spring bean. It can't practically go in the RouteBuilder > because there are several routes which require this initialization. Hi Could you create a ticket in JIRA to add depends-on attribute to tag. > -- > View this message in context: > http://old.nabble.com/Camel%2C-Spring-and-Initialization-tp28113566p28119764.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Update Camel Content Filter Page?
Hi Feel free to add this variation to the wiki page. On Fri, Apr 2, 2010 at 5:17 PM, ychawla wrote: > > Hi Gang, > Currently the WIKI has a content filter example like this: > > > > > > > For the work we are doing, we want to select an xpath and set that as the > body. We are doing something like this: > > > > resultType="org.w3c.dom.Document">//foo:bar > > > > I think this example would be helpful to include. End users don't have to > bother creating a bean that does a transform or write in some cases a > relatively simple XSLT. Any objections to me updating? > > Thanks, > Yogesh > -- > View this message in context: > http://old.nabble.com/Update-Camel-Content-Filter-Page--tp28120008p28120008.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Update Camel Content Filter Page?
Hi Gang, Currently the WIKI has a content filter example like this: For the work we are doing, we want to select an xpath and set that as the body. We are doing something like this: //foo:bar I think this example would be helpful to include. End users don't have to bother creating a bean that does a transform or write in some cases a relatively simple XSLT. Any objections to me updating? Thanks, Yogesh -- View this message in context: http://old.nabble.com/Update-Camel-Content-Filter-Page--tp28120008p28120008.html Sent from the Camel - Users mailing list archive at Nabble.com.
Problem with OSGI Tutorial
Hello, I' m workig on OSGI ReportIncident tutorial second part. The application atrt well but when i try to make an insert i receive the ava.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:162) at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:66) at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:183) at org.hibernate.tuple.entity.AbstractEntityTuplizer.(AbstractEntityTuplizer.java:158) at org.hibernate.tuple.entity.PojoEntityTuplizer.(PojoEntityTuplizer.java:76) at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:80) at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:325) at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:457) at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:131) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:84) at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:261) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327) at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:814) at org.springframework.orm.hibernate3.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:732) at org.springframework.orm.hibernate3.AbstractSessionFactoryBean.afterPropertiesSet(AbstractSessionFactoryBean.java:211) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1369) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) javassiste is load an run. i try to make some googling and i found the http://opensource.atlassian.com/projects/hibernate/browse/HHH-3826 but the solution that their proposed i my case dosen't wrok. Could you help, please to know waht i can i do for running the example Cheers
Re: Camel, Spring and Initialization
Claus Ibsen-2 wrote: > > The code to run before is that in the RouteBuilder class? Or is it > defined as a spring bean etc.? > It's defined as a spring bean. It can't practically go in the RouteBuilder because there are several routes which require this initialization. -- View this message in context: http://old.nabble.com/Camel%2C-Spring-and-Initialization-tp28113566p28119764.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: JPA consumer starts up, but is not polling
Claus, I was using Camel 2.1.0. Switched to 2.2.0 now and I can confirm that the error is now logged correctly. Thanks again and have a nice weekend! Jan - 10:21:58 ERROR [aComponent] JpaConsumer - Consumer Consumer[jpa://com.infinity.bpm.jpa.beans.TransactionTracker?consumer.initialDelay=5000] could not poll endpoint: jpa://com.infinity.bpm.jpa.beans.TransactionTracker?consumer.initialDelay=5000 caused by: antlr/ANTLRException java.lang.NoClassDefFoundError: antlr/ANTLRException at org.hibernate.hql.ast.ASTQueryTranslatorFactory.createQueryTranslator(ASTQueryTranslatorFactory.java:58) at org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:98) at org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:80) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1650) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.orm.jpa.JpaTemplate$CloseSuppressingInvocationHandler.invoke(JpaTemplate.java:404) at $Proxy105.createQuery(Unknown Source) at org.apache.camel.component.jpa.QueryBuilder$1.makeQueryObject(QueryBuilder.java:44) at org.apache.camel.component.jpa.QueryBuilder.createQuery(QueryBuilder.java:152) at org.apache.camel.component.jpa.JpaConsumer$1.doInJpa(JpaConsumer.java:83) ... -- View this message in context: http://old.nabble.com/JPA-consumer-starts-up%2C-but-is-not-polling-tp27951000p28119549.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
Could camel simply use spring el for properties?
Greetings
Christian
Am 02.04.2010 11:07, schrieb Claus Ibsen:
Hi
See ticket
https://issues.apache.org/activemq/browse/CAMEL-2599
The problem is that Spring 3.0 includes a EL by default which is
automatic in use in the Spring XML files.
It uses the same tokens as we do with Camel Properties component and
therefore Spring EL fails with an exception.
The easiest and also least problematic resolution is to use a
different tokens in Camel to avoid the clash.
It will also be least surprise by Camel end users if they mix and
match between Spring EL and Camel Properties.
So what tokens do you want to use? Currently we did use
- prefix = #{
- suffix = }
For example:
from("#{cool.start}")
.to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
.to("mock:#{cool.result}");
A)
===
I am thinking of changing to:
- prefix = #[
- suffix = ]
For example:
from("#[cool.start]")
.to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
.to("mock:#[cool.result]");
B)
===
Or maybe?
- prefix = #p{
- suffix = }
For example:
from("#p{cool.start}")
.to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
.to("mock:#p{cool.result}");
C)
We cannot do this one
- prefix = ${
- suffix = }
As it will clash with Camel Simple language (would take more work to
let them co-exist in peace :)
However we could most likely use a longer preifx such as
- prefix = ${p:
- suffix = }
For example:
from("${p:cool.start}")
.to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
.to("mock:${p:cool.result}");
Do you have any thoughts and preference what tokens to use?
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
On Fri, Apr 2, 2010 at 1:36 PM, Guillaume Nodet wrote:
> Could those be parameters on the camel context ?
>
Its possible but there is a resolver in DefaultCamelContext which
depends on knowing the tokens beforehand.
It would be more correct to let the tokens be customizable on
PropertiesComponent.
But for now they are fixed.
I have implemented the suggestion by Martin Krasser to use {{key}}
The camel source code now works with both Spring 2.5 and 3.0.
> On Fri, Apr 2, 2010 at 13:30, Willem Jiang wrote:
>
>> +1 for #[], or #p{}.
>> The other options still make the Spring EL confused.
>>
>> Willem
>>
>>
>> Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> See ticket
>>> https://issues.apache.org/activemq/browse/CAMEL-2599
>>>
>>> The problem is that Spring 3.0 includes a EL by default which is
>>> automatic in use in the Spring XML files.
>>> It uses the same tokens as we do with Camel Properties component and
>>> therefore Spring EL fails with an exception.
>>>
>>> The easiest and also least problematic resolution is to use a
>>> different tokens in Camel to avoid the clash.
>>> It will also be least surprise by Camel end users if they mix and
>>> match between Spring EL and Camel Properties.
>>>
>>> So what tokens do you want to use? Currently we did use
>>> - prefix = #{
>>> - suffix = }
>>>
>>> For example:
>>> from("#{cool.start}")
>>>
>>> .to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
>>> .to("mock:#{cool.result}");
>>>
>>>
>>> A)
>>> ===
>>> I am thinking of changing to:
>>> - prefix = #[
>>> - suffix = ]
>>>
>>> For example:
>>> from("#[cool.start]")
>>>
>>> .to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
>>> .to("mock:#[cool.result]");
>>>
>>> B)
>>> ===
>>> Or maybe?
>>> - prefix = #p{
>>> - suffix = }
>>>
>>> For example:
>>> from("#p{cool.start}")
>>>
>>>
>>> .to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
>>> .to("mock:#p{cool.result}");
>>>
>>>
>>> C)
>>>
>>> We cannot do this one
>>> - prefix = ${
>>> - suffix = }
>>>
>>> As it will clash with Camel Simple language (would take more work to
>>> let them co-exist in peace :)
>>> However we could most likely use a longer preifx such as
>>>
>>> - prefix = ${p:
>>> - suffix = }
>>>
>>> For example:
>>> from("${p:cool.start}")
>>>
>>>
>>> .to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
>>> .to("mock:${p:cool.result}");
>>>
>>>
>>> Do you have any thoughts and preference what tokens to use?
>>>
>>>
>>>
>>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Unmarshalling CSV files and send many messages
Thank you so much. All the best Rob Claus Ibsen-2 wrote: > > On Fri, Apr 2, 2010 at 12:06 PM, justme2 wrote: >> >> Hi, >> I'm evaluating Camel in order to find out if it could be integrated in a >> system. >> What I'm trying to do is to set a file endpoint that reads csv files. >> Those csv files contain about 100 lines each that should be sent as 100 >> messages to different endpoints (jms queues) regarding the content of >> every >> line. >> At first glance seems that Camel file component manages files as a whole >> object allowing to check for specific content (i.e. for routing) but not >> considering single lines as in my use-case. >> Any suggestion ? >> Thanks >> > > You use the EIP patterns for such kind of work. They provide great > building blocks for your routing and integration needs. > http://camel.apache.org/enterprise-integration-patterns.html > > See the splitter EIP which can split the file into a line by line basis > http://camel.apache.org/splitter.html > > The Camel in Action book contains such a CSV file -> split -> X lines > example in chapter 13. > http://www.manning.com/ibsen/ > > The source code is here, so you can find the example in > chapter13/startup directory. > http://code.google.com/p/camelinaction/ > > > >> Rob >> -- >> View this message in context: >> http://old.nabble.com/Unmarshalling-CSV-files-and-send-many-messages-tp28117514p28117514.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > > -- View this message in context: http://old.nabble.com/Unmarshalling-CSV-files-and-send-many-messages-tp28117514p28118384.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
Could those be parameters on the camel context ?
On Fri, Apr 2, 2010 at 13:30, Willem Jiang wrote:
> +1 for #[], or #p{}.
> The other options still make the Spring EL confused.
>
> Willem
>
>
> Claus Ibsen wrote:
>
>> Hi
>>
>> See ticket
>> https://issues.apache.org/activemq/browse/CAMEL-2599
>>
>> The problem is that Spring 3.0 includes a EL by default which is
>> automatic in use in the Spring XML files.
>> It uses the same tokens as we do with Camel Properties component and
>> therefore Spring EL fails with an exception.
>>
>> The easiest and also least problematic resolution is to use a
>> different tokens in Camel to avoid the clash.
>> It will also be least surprise by Camel end users if they mix and
>> match between Spring EL and Camel Properties.
>>
>> So what tokens do you want to use? Currently we did use
>> - prefix = #{
>> - suffix = }
>>
>> For example:
>>from("#{cool.start}")
>>
>> .to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
>>.to("mock:#{cool.result}");
>>
>>
>> A)
>> ===
>> I am thinking of changing to:
>> - prefix = #[
>> - suffix = ]
>>
>> For example:
>>from("#[cool.start]")
>>
>> .to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
>>.to("mock:#[cool.result]");
>>
>> B)
>> ===
>> Or maybe?
>> - prefix = #p{
>> - suffix = }
>>
>> For example:
>>from("#p{cool.start}")
>>
>>
>> .to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
>>.to("mock:#p{cool.result}");
>>
>>
>> C)
>>
>> We cannot do this one
>> - prefix = ${
>> - suffix = }
>>
>> As it will clash with Camel Simple language (would take more work to
>> let them co-exist in peace :)
>> However we could most likely use a longer preifx such as
>>
>> - prefix = ${p:
>> - suffix = }
>>
>> For example:
>>from("${p:cool.start}")
>>
>>
>> .to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
>>.to("mock:${p:cool.result}");
>>
>>
>> Do you have any thoughts and preference what tokens to use?
>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
+1 for #[], or #p{}.
The other options still make the Spring EL confused.
Willem
Claus Ibsen wrote:
Hi
See ticket
https://issues.apache.org/activemq/browse/CAMEL-2599
The problem is that Spring 3.0 includes a EL by default which is
automatic in use in the Spring XML files.
It uses the same tokens as we do with Camel Properties component and
therefore Spring EL fails with an exception.
The easiest and also least problematic resolution is to use a
different tokens in Camel to avoid the clash.
It will also be least surprise by Camel end users if they mix and
match between Spring EL and Camel Properties.
So what tokens do you want to use? Currently we did use
- prefix = #{
- suffix = }
For example:
from("#{cool.start}")
.to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
.to("mock:#{cool.result}");
A)
===
I am thinking of changing to:
- prefix = #[
- suffix = ]
For example:
from("#[cool.start]")
.to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
.to("mock:#[cool.result]");
B)
===
Or maybe?
- prefix = #p{
- suffix = }
For example:
from("#p{cool.start}")
.to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
.to("mock:#p{cool.result}");
C)
We cannot do this one
- prefix = ${
- suffix = }
As it will clash with Camel Simple language (would take more work to
let them co-exist in peace :)
However we could most likely use a longer preifx such as
- prefix = ${p:
- suffix = }
For example:
from("${p:cool.start}")
.to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
.to("mock:${p:cool.result}");
Do you have any thoughts and preference what tokens to use?
Re: issue with HTTP response content length being set to CXF request length - causing truncated responses.
The url is OK, I can see the latest Camel 2.3.0-SNAPSHOT was published yesterday, maybe you can try to run the test again. Willem zigo wrote: Willem, I am not sure I got your question right, anyway I have downloaded version 2.3-SNAPSHOT from the Apache Snapshots repository at https://repository.apache.org/content/repositories/snapshots Alberto willem.jiang wrote: Hi, I'm doing the daily development of camel on the MacOSX. Can you tell me how do get the Camel 2.3.0-SNAPSHOT ? It will be helpful for use to trace the issue. Willem zigo wrote: What platform are you testing on? I have seen that this problem manifests only on MacOS, tests done on Windows work without removing the Content-Length. Anyway, I will try compiling the trunk. Alberto willem.jiang wrote: Hi, Can you build the trunk code yourself ? My test is working[1], I'm doubt there are something wrong with SNAPSHOT publish. [1] http://svn.apache.org/viewvc?rev=929475&view=rev Willem zigo wrote: Willem, I have tried with the latest 2.3-SNAPSHOT, but unfortunately the problem is still there. Alberto willem.jiang wrote: FYI, I create a JIRA[1] for this issue and committed a quick fix for it. Please feel free to check out the latest Camel 2.3.0-SNAPSHOT to verify it. Willem zigo wrote: Willem, my route is this: http://camel.apache.org/schema/spring";> http://foo.com}gt_connector&dataFormat=MESSAGE"/> I think this issue should be considered a bug, or at least pointed out in Camel documentation. Alberto willem.jiang wrote: We filter the message header of "Content-Length" from camel to cxf. If you just pass the message to the other camel endpoint, I'm afraid you need to remove it you self. Willem zigo wrote: I am still having the same problem using: - Camel 2.2.0 - CXF 2.2.6 - Mac OS 10.6.2 Workaround (removing http header) works for me. Alberto wkeenan wrote: On Tue, Mar 2, 2010 at 3:35 AM, Willem Jiang wrote: Hi Can you check out the latest released Camel 2.2.0 ? working on camel 2.2.0, CXF 2.2.6 on Mac10.6 Thanks, Wayne
Re: Camel, Spring and Initialization
On Thu, Apr 1, 2010 at 11:00 PM, greenstar wrote: > > I am using Camel with Spring like follows: > > http://camel.apache.org/schema/spring";> > > ... > > > I'm looking for a way to run some code before the route builders are run. > This seems like it should be straightforward. I've tried the @PostConstruct > (with CommonAnnotationBeanPostProcessor). I've also tried > ApplicationContextEvent. These initialization hooks all work, but they are > all executed *after* the RouteBuilder.configure() methods are called. > The code to run before is that in the RouteBuilder class? Or is it defined as a spring bean etc.? > How does the tag integrate into Spring and how can I specify > the initialization order of my own beans relative to it? > In Spring XML you can use the depends-on attribute in the tag. I wonder if we need to add it to as well so you can have Camel depend upon other beans. > Thanks. > -- > View this message in context: > http://old.nabble.com/Camel%2C-Spring-and-Initialization-tp28113566p28113566.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Unmarshalling CSV files and send many messages
On Fri, Apr 2, 2010 at 12:06 PM, justme2 wrote: > > Hi, > I'm evaluating Camel in order to find out if it could be integrated in a > system. > What I'm trying to do is to set a file endpoint that reads csv files. > Those csv files contain about 100 lines each that should be sent as 100 > messages to different endpoints (jms queues) regarding the content of every > line. > At first glance seems that Camel file component manages files as a whole > object allowing to check for specific content (i.e. for routing) but not > considering single lines as in my use-case. > Any suggestion ? > Thanks > You use the EIP patterns for such kind of work. They provide great building blocks for your routing and integration needs. http://camel.apache.org/enterprise-integration-patterns.html See the splitter EIP which can split the file into a line by line basis http://camel.apache.org/splitter.html The Camel in Action book contains such a CSV file -> split -> X lines example in chapter 13. http://www.manning.com/ibsen/ The source code is here, so you can find the example in chapter13/startup directory. http://code.google.com/p/camelinaction/ > Rob > -- > View this message in context: > http://old.nabble.com/Unmarshalling-CSV-files-and-send-many-messages-tp28117514p28117514.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: issue with HTTP response content length being set to CXF request length - causing truncated responses.
Willem,
I am not sure I got your question right, anyway I have downloaded version
2.3-SNAPSHOT from the Apache Snapshots repository at
https://repository.apache.org/content/repositories/snapshots
Alberto
willem.jiang wrote:
>
> Hi,
>
> I'm doing the daily development of camel on the MacOSX.
> Can you tell me how do get the Camel 2.3.0-SNAPSHOT ?
> It will be helpful for use to trace the issue.
>
> Willem
>
> zigo wrote:
>> What platform are you testing on?
>>
>> I have seen that this problem manifests only on MacOS, tests done on
>> Windows
>> work without removing the Content-Length.
>>
>> Anyway, I will try compiling the trunk.
>>
>> Alberto
>>
>>
>>
>> willem.jiang wrote:
>>> Hi,
>>>
>>> Can you build the trunk code yourself ?
>>> My test is working[1], I'm doubt there are something wrong with SNAPSHOT
>>> publish.
>>>
>>> [1] http://svn.apache.org/viewvc?rev=929475&view=rev
>>>
>>> Willem
>>>
>>> zigo wrote:
Willem,
I have tried with the latest 2.3-SNAPSHOT, but unfortunately the
problem
is
still there.
Alberto
willem.jiang wrote:
> FYI, I create a JIRA[1] for this issue and committed a quick fix for
> it.
> Please feel free to check out the latest Camel 2.3.0-SNAPSHOT to
> verify
> it.
>
> Willem
>
> zigo wrote:
>> Willem,
>>
>> my route is this:
>>
>> > xmlns="http://camel.apache.org/schema/spring";>
>>
>> > uri="cxf:bean:gtEndpoint?serviceName={http://foo.com}gt_connector&dataFormat=MESSAGE"/>
>>
>>
>>
>>
>> > uri="jms:GT.IN?replyTo=GT.OUT&deliveryPersistent=false&useMessageIDAsCorrelationID=true"
>> />
>>
>>
>>
>> I think this issue should be considered a bug, or at least pointed
>> out
>> in
>> Camel documentation.
>>
>> Alberto
>>
>>
>> willem.jiang wrote:
>>> We filter the message header of "Content-Length" from camel to cxf.
>>> If you just pass the message to the other camel endpoint, I'm afraid
>>> you
>>> need to remove it you self.
>>>
>>> Willem
>>>
>>> zigo wrote:
I am still having the same problem using:
- Camel 2.2.0
- CXF 2.2.6
- Mac OS 10.6.2
Workaround (removing http header) works for me.
Alberto
wkeenan wrote:
> On Tue, Mar 2, 2010 at 3:35 AM, Willem Jiang
>
> wrote:
>
>> Hi
>> Can you check out the latest released Camel 2.2.0 ?
>>
> working on camel 2.2.0, CXF 2.2.6 on Mac10.6
>
> Thanks,
> Wayne
>
>
>
>>>
>>>
>>
>
>
>
--
View this message in context:
http://old.nabble.com/issue-with-HTTP-response-content-length-being-set-to-CXF-request--length---causing-truncated-responses.-tp27747908p28117551.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Unmarshalling CSV files and send many messages
Hi, I'm evaluating Camel in order to find out if it could be integrated in a system. What I'm trying to do is to set a file endpoint that reads csv files. Those csv files contain about 100 lines each that should be sent as 100 messages to different endpoints (jms queues) regarding the content of every line. At first glance seems that Camel file component manages files as a whole object allowing to check for specific content (i.e. for routing) but not considering single lines as in my use-case. Any suggestion ? Thanks Rob -- View this message in context: http://old.nabble.com/Unmarshalling-CSV-files-and-send-many-messages-tp28117514p28117514.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
On Fri, Apr 2, 2010 at 11:31 AM, Martin Krasser wrote:
> What about
>
> - prefix = {{
> - suffix = }}
>
> Then we'd avoid reserved URI characters such as $, #, ... etc.
>
Yeah that sounds like a good idea. Let me try it out and see what the
computer say :)
> Am 02.04.2010 11:07, schrieb Claus Ibsen:
>>
>> Hi
>>
>> See ticket
>> https://issues.apache.org/activemq/browse/CAMEL-2599
>>
>> The problem is that Spring 3.0 includes a EL by default which is
>> automatic in use in the Spring XML files.
>> It uses the same tokens as we do with Camel Properties component and
>> therefore Spring EL fails with an exception.
>>
>> The easiest and also least problematic resolution is to use a
>> different tokens in Camel to avoid the clash.
>> It will also be least surprise by Camel end users if they mix and
>> match between Spring EL and Camel Properties.
>>
>> So what tokens do you want to use? Currently we did use
>> - prefix = #{
>> - suffix = }
>>
>> For example:
>> from("#{cool.start}")
>>
>> .to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
>> .to("mock:#{cool.result}");
>>
>>
>> A)
>> ===
>> I am thinking of changing to:
>> - prefix = #[
>> - suffix = ]
>>
>> For example:
>> from("#[cool.start]")
>>
>> .to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
>> .to("mock:#[cool.result]");
>>
>> B)
>> ===
>> Or maybe?
>> - prefix = #p{
>> - suffix = }
>>
>> For example:
>> from("#p{cool.start}")
>>
>>
>> .to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
>> .to("mock:#p{cool.result}");
>>
>>
>> C)
>>
>> We cannot do this one
>> - prefix = ${
>> - suffix = }
>>
>> As it will clash with Camel Simple language (would take more work to
>> let them co-exist in peace :)
>> However we could most likely use a longer preifx such as
>>
>> - prefix = ${p:
>> - suffix = }
>>
>> For example:
>> from("${p:cool.start}")
>>
>>
>> .to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
>> .to("mock:${p:cool.result}");
>>
>>
>> Do you have any thoughts and preference what tokens to use?
>>
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
What about
- prefix = {{
- suffix = }}
Then we'd avoid reserved URI characters such as $, #, ... etc.
Am 02.04.2010 11:07, schrieb Claus Ibsen:
Hi
See ticket
https://issues.apache.org/activemq/browse/CAMEL-2599
The problem is that Spring 3.0 includes a EL by default which is
automatic in use in the Spring XML files.
It uses the same tokens as we do with Camel Properties component and
therefore Spring EL fails with an exception.
The easiest and also least problematic resolution is to use a
different tokens in Camel to avoid the clash.
It will also be least surprise by Camel end users if they mix and
match between Spring EL and Camel Properties.
So what tokens do you want to use? Currently we did use
- prefix = #{
- suffix = }
For example:
from("#{cool.start}")
.to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
.to("mock:#{cool.result}");
A)
===
I am thinking of changing to:
- prefix = #[
- suffix = ]
For example:
from("#[cool.start]")
.to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
.to("mock:#[cool.result]");
B)
===
Or maybe?
- prefix = #p{
- suffix = }
For example:
from("#p{cool.start}")
.to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
.to("mock:#p{cool.result}");
C)
We cannot do this one
- prefix = ${
- suffix = }
As it will clash with Camel Simple language (would take more work to
let them co-exist in peace :)
However we could most likely use a longer preifx such as
- prefix = ${p:
- suffix = }
For example:
from("${p:cool.start}")
.to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
.to("mock:${p:cool.result}");
Do you have any thoughts and preference what tokens to use?
[Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
Hi
See ticket
https://issues.apache.org/activemq/browse/CAMEL-2599
The problem is that Spring 3.0 includes a EL by default which is
automatic in use in the Spring XML files.
It uses the same tokens as we do with Camel Properties component and
therefore Spring EL fails with an exception.
The easiest and also least problematic resolution is to use a
different tokens in Camel to avoid the clash.
It will also be least surprise by Camel end users if they mix and
match between Spring EL and Camel Properties.
So what tokens do you want to use? Currently we did use
- prefix = #{
- suffix = }
For example:
from("#{cool.start}")
.to("log:#{cool.start}?showBodyType=false&showExchangeId=#{cool.showid}")
.to("mock:#{cool.result}");
A)
===
I am thinking of changing to:
- prefix = #[
- suffix = ]
For example:
from("#[cool.start]")
.to("log:#[cool.start]?showBodyType=false&showExchangeId=#[cool.showid]")
.to("mock:#[cool.result]");
B)
===
Or maybe?
- prefix = #p{
- suffix = }
For example:
from("#p{cool.start}")
.to("log:#p{cool.start}?showBodyType=false&showExchangeId=#p{cool.showid}")
.to("mock:#p{cool.result}");
C)
We cannot do this one
- prefix = ${
- suffix = }
As it will clash with Camel Simple language (would take more work to
let them co-exist in peace :)
However we could most likely use a longer preifx such as
- prefix = ${p:
- suffix = }
For example:
from("${p:cool.start}")
.to("log:${p:cool.start}?showBodyType=false&showExchangeId=$p{p:cool.showid}")
.to("mock:${p:cool.result}");
Do you have any thoughts and preference what tokens to use?
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel security
Claus Ibsen wrote: On Thu, Apr 1, 2010 at 4:20 PM, Willem Jiang wrote: Hi Jervis I'm planing to work on Spring security and Camel integration[1] in the coming up few week. If everything goes well, I think you can try out the basic security implementation with Role based authorization then we can try to integrate the Drools part. [1] https://issues.apache.org/activemq/browse/CAMEL-2579 Willem please hold with making major changes into the 2.3 codebase. We have the features we need for 2.3 and want to use the next 2-3 weeks to get the last pieces done so we can get a 2.3 release out the door. And I believe we need to discuss and design the security framework to be added into Camel in the public. I think you can start with creating a wiki page at the developer section at Camel wiki and then we can all take a look and help design it. Sure, I will work on the design document first. Its important that we do this in a manner so the security framework of choice can easily be plugged in, as many have different needs. And some are forced to use JAAS etc. So it should NOT be a Spring Security that master how we do this in Camel. Willem Claus Ibsen wrote: Hi Sounds great with Drools integration with Camel. No there is not a general security module in Camel. Its something that we will work on and provide in the future. At present time its not on the roadmap short term. Each individual camel component often have their own security settings which you leverage, such as Jetty etc. On Thu, Apr 1, 2010 at 11:04 AM, jliu wrote: Hi, I am currently working on Drools (http://www.jboss.org/drools) Camel integration. One requirement popped up is to provide a secured access to Drools KnowledgeSession . For those who is not familiar with Drools, Drools KnowledgeSession is defined as a Camel process or endpoint. Basically this means an authentication framework and an authorization framework that can be used to provide service level and method level security. The authorization part needs to support both role-based authorization and rule-based authorization. So for example, with this security in place, I can say "only admin type user can access Drools KnowledgeSession " or "only admin type user can call insertFact on Drools KnowledgeSession ". I can also say "If the current user has called fireAllRules on Drools KnowledgeSession more than an average of 5 times in the last minute, then reject the next invocation, as its possible fraud". An example of camle route with authorization may look like below (Please note, this is not a valid configuration, just used to illustrate the idea): Service level security: a camel route without authorization: a camel route with simple role based authorization using role mappings stored in property files: a camel route with rule based authorization using Drools: Method level security: TBD Does such feature exist in Camel or will be supported in the future? Thanks, Jervis Liu -- View this message in context: http://old.nabble.com/Camel-security-tp28106100p28106100.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel security
jliu wrote: Claus Ibsen-2 wrote: Its important that we do this in a manner so the security framework of choice can easily be plugged in, as many have different needs. And some are forced to use JAAS etc. So it should NOT be a Spring Security that master how we do this in Camel. +1. Ideally the Camel security will be pluggable, so that ppl can plug different security implementations into Camel. For example, for Drools project, I may want to use Picketlink (http://www.jboss.org/picketlink) as the underlying authentication and authorization implementation. Other people may prefer Spring security or their own implementations. If we dig into technical details a little bit, I believe the authentication part should be straightforward. As long as JAAS is used, different authentication implementations can always be plugged in easily. The headache part is the authorization. There is no standard we can use in this area, and I am not sure how easy it is to write a framework that can plug in different authorization implementations. For example, it may not be possible to write an authorization framework that is flexible enough to switch its underlying impl among Picketlink Authz (http://www.jboss.org/picketlink/AuthZ.html) and the authorization part in Seam3 Security (http://www.seamframework.org/Seam3/SecurityModuleOverview) and the authorization part in Spring security. Mostly likely Camel will have to come out with its own specific authorization implementation or just choose an existing one. The reason that I choice Spring Security to implement the authorization mechanism supports different kinds of AccessDecisionVoter, and they are spring friendly. In Spring Security, the authorization will be delegate to the AccessDecisionManager and you can setup different AccessDecisionVoter on it, maybe we can add a layer in Camel to plug the different authorization implementation. Willem
