Re: CxfEndpoint and configure interceptor on bus
Hi Aki, Thanks for your reply. The problem was that the interceptor that was defined on the bus was not invoked and even not added to the interceptor chain but this was a stupid configuration error on my side :-( With CXF-2.4.4 it was working if cxfcore:bus id=somebus ... was defined (wrong usage of the id attribute instead of bus) and with CXF-2.4.6 (or newer) this does no longer work. Switching to CXF-2.5.2 threw an exception that no bus with this id/name was configured and this lead me to find the wrong configuration. Sorry for the noise on the camel list because it's a CXF related issue caused by my wrong configuration. Regards, Andi -- View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-and-configure-interceptor-on-bus-tp5541585p5543569.html Sent from the Camel - Users mailing list archive at Nabble.com.
CxfEndpoint and configure interceptor on bus
Hi, I've a question regarding camel-cxf in combination with interceptors configured on the CXF-bus. It seems that the behaviour has changed from CXF-version 2.4.4 to 2.4.6 but I'm not sure if it's a camel problem. I've modified a unit-test that shows the problem. I expected an interceptor that is configured on the cxf-bus to be added to any cxf-endpoint that uses this bus but it's not added. Please see the attached patch that has the modified test. http://camel.465427.n5.nabble.com/file/n5541585/camel-cxf-question.patch camel-cxf-question.patch Is my assumption wrong? Best regards Andi -- View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-and-configure-interceptor-on-bus-tp5541585p5541585.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Classpath problem with camel-cxf and OSGi
Hi, See here: http://old.nabble.com/-VOTE--Release-Apache-Camel-2.1.0-to26587866s22882.html http://old.nabble.com/-VOTE--Release-Apache-Camel-2.1.0-to26587866s22882.html for download link of version 2.1.0 -- View this message in context: http://old.nabble.com/Classpath-problem-with-camel-cxf-and-OSGi-tp26612544p26621727.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Does Jaxb With Spring Remoting (proxy) work ?
Hi, If I get you right the problem is that the classes generated by jaxb do not implement Serializable?! This can be changed by adding custom binding for jaxb. I haven't tried out how to use this with Camel but I guess this should be a starting point. You can also google for jaxb java class serializable. Should be something like this: lt;?xml version=1.0 encoding=UTF-8?gt; lt;jxb:bindings version=2.0 xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:xs=http://www.w3.org/2001/XMLSchemagt; lt;jxb:bindings gt; lt;jxb:globalBindingsgt; lt;jxb:serializable uid=1 /gt; lt;/jxb:globalBindingsgt; lt;/jxb:bindingsgt; lt;/jxb:bindingsgt; Hope this helps. -- View this message in context: http://www.nabble.com/Does-Jaxb-With-Spring-Remoting-%28proxy%29-work---tp24956379p24982316.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Problem with FileConsumer and pollEnrich
Hi Claus, FileUtil.stripExt(...) does not exist on trunk ... -- View this message in context: http://www.nabble.com/Problem-with-FileConsumer-and-pollEnrich-tp24795192p24895089.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Problem with FileConsumer and pollEnrich
Yes, but trunk doesn't build currently ;-) ... If you commit it later, no problem. -- View this message in context: http://www.nabble.com/Problem-with-FileConsumer-and-pollEnrich-tp24795192p24895196.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Spring Remoting throwing RuntimeException question
Hi Claus I've created the JIRA issue 1888 with a patch and a test case for the problem with the Exception. For the problem with the camel-example-pojo-messaging where the camelLock files remain in the src/data dirctory on my machine. The steps as stated in readme.txt: call mvn compile camel:run -- files are delivered and *.camelLock are created in src/data -- Ctrl+C to terminate the camel:run -- I see shutdown messages for the camel context. delete the messages folder in target .. just to see if the messages are processed call mvn camel:run again -- the files are not processed. But in the output I can see that the FileConsumer prints Total 3 files to consume on DEBUG level, but nothing happens. My machine is running XP and I have tested with jre 1.5.0_16 and 1.6.0_14. -- View this message in context: http://www.nabble.com/Camel-Spring-Remoting-throwing-RuntimeException-question-tp24825646p24861894.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Spring Remoting throwing RuntimeException question
Hi
Thanks for the reply. I think the test-case is slightly different than what
my request was. If you change the EchoPojo to inject a dynamic proxy you
will see the problem that I have (see code below).
public class EchoPojo {
@Produce(uri = direct:echo)
//private ProducerTemplate service;
private Echo service;
@Consume(uri = direct:start)
public String onEcho(String name) {
//return (String) service.requestBody(name);
return (String) service.echo(name);
}
}
--
View this message in context:
http://www.nabble.com/Camel-Spring-Remoting-throwing-RuntimeException-question-tp24825646p24841441.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Redelivery in Loadbalancer
Hi Claus, Works fine now =) Thanks for the fix. -- View this message in context: http://www.nabble.com/Redelivery-in-Loadbalancer-tp24161904p24184289.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to prevent routes from started twice?
Hi, I've tested it yesterday and it works fine. Thanks a lot for that. Maybe you can check my comments after your last commit to enable manual start if the shouldStartContext flag is set to false. -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p24087986.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to prevent routes from started twice?
Hi Claus, I does honor but the problem is that you can't start the camel context (from another bean) if shouldStartContext is set to false, and this is the only way to prevent the execution of code that is triggered by refresh event. I'll create a JIRA ticket with a problem description. -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997172.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to prevent routes from started twice?
I see it twice! Once for the root application context (which is correct, because its the context where the camel context is defined in) and a second time for the web application context (which I think is incorrect because it's the child context of the root). I don't know if it would work in all cases if the applicationContext instance of the refresh event would be evaulated and only refresh events for the applicationContext of the camel context is processed ... -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997647.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Are durable topic subscriptions destroyed?
Spring Issue created: http://jira.springframework.org/browse/SPR-5552 Claus Ibsen-2 wrote: On Thu, Mar 5, 2009 at 12:33 PM, akuhtz andreas.ku...@siemens.com wrote: There is currently no code to unsubscribe a durable subscriber as Camel uses the XXMessageListenerContainer classes from the spring framework and inside the spring code there is no unsubscribe code. I solved this yesterday by making a copy of the (in my case) SimpleMessageListenerContainer and added the unsubscribe code to the doShutdown() method (I couldn't just extend from SimpleMessageListenerContainer and overwrite doShutdown() because the consumers are private and no protected access method exists, and between close the consumers and close the session there is (unfortunately) no callback where the unsubcribe could be executed. If you find another solution without copying the class please let me know :-) You could consider creating a ticket at Spring about this issue to allow easier subclassing of the SimpleMessageListenerContainer, or callbacks so we can do the unsubscribe there. Would be good to get in Spring 3.0. Claus Ibsen-2 wrote: On Thu, Mar 5, 2009 at 3:38 AM, ariekenb aaron.j.riekenb...@lmco.com wrote: If I create a durable topic subscription using the jms or activemq components (for example activemq:topic:myTopic?clientId=client1durableSubscriptionName=subscription1), does camel ever cause the durable subscription to be destroyed? In other words will camel ever cause session.unsubscribe to be called? I'm working in a situation where I'm implementing failover of a durable subscription on different machines using camel and I want to be sure the durable subscription does not get destroyed when the camel context is destroyed. Just out of curiosity, I'm also wondering how/if one can indicate he wants the durable subscription to be destroyed when the camel context is destroyed. Not to my knowledge. But I would advice you to double check the source code of camel-jms to see if there is any code that would call unsubscribe. Usually such code would be in doStop or stop methods. James Strachan who wrote the camel-jms component would be in a better position to clarify this. With your findings we should update the wiki, so please report back. As an aside there is a small bug on this web page describing durable subscriptions (http://camel.apache.org/jms.html). The first paragraph under Notes states If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. durableSubscriberName does not work. The table below has the correct property: durableSubscriptionName. Thanks for spotting this. Fixed the typo. -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22344211.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/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22349650.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/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22409437.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Are durable topic subscriptions destroyed?
I know that this is the case with ActiveMQ (you posted about it some time ago in this forum) but we're using Oracle AQ (Streams replication) and their samples show how they think it should work and in their case the unsubscribe stops the delivery of messages. James.Strachan wrote: 2009/3/5 akuhtz andreas.ku...@siemens.com: There is currently no code to unsubscribe a durable subscriber as Camel uses the XXMessageListenerContainer classes from the spring framework and inside the spring code there is no unsubscribe code. I solved this yesterday by making a copy of the (in my case) SimpleMessageListenerContainer and added the unsubscribe code to the doShutdown() method (I couldn't just extend from SimpleMessageListenerContainer and overwrite doShutdown() because the consumers are private and no protected access method exists, and between close the consumers and close the session there is (unfortunately) no callback where the unsubcribe could be executed. If you find another solution without copying the class please let me know :-) BTW whether the subscription is closed using an unsubscribe or if the process hosting the consumer just dies - its the same thing from a JMS provider's perspective. i.e. closing a durable topic subscriber does not terminate the durable subscription. The whole point of a durable topic subscription is to keep going while the consumer is not running any more. There's no JMS API to terminate a durable subscription - unfortunately thats JMS provider specific and usually achieved using MBeans or some provider specific console -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22411405.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
