Re: Order of logName evaluation for log EIP
Hi Clause, Thx for clarifying. Would this be backported to 3.22.x as well once finished? Regards, Benjamin Am 14. Februar 2024 06:54:25 MEZ schrieb Claus Ibsen : >Hi > >Yeah the doc is a bit outdated, and we should also only use source >name:line if explicit enabled >https://issues.apache.org/jira/browse/CAMEL-20418 > >On Tue, Feb 13, 2024 at 8:03 PM Benjamin Graf >wrote: > >> Hi together, >> >> I'm struggling what would be the expected order for logName evaluation. >> The docs ( >> https://camel.apache.org/components/4.0.x/eips/log-eip.html#_configuring_logging_name) >> says if not defined, it'll use the routeId set or a generated one. Looking >> into code of LogReifier ( >> https://github.com/apache/camel/blob/3793981daa32567a25a2aa1628a986658f863171/core/camel-core-reifier/src/main/java/org/apache/camel/reifier/LogReifier.java#L70) >> it would use getLineNumberLoggerName() before any kind of routeId first. >> >> What is the wanted order code or doc? Seems to be a bug, anyway :) >> >> Regards, >> >> Benjamin >> > > -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. signature.asc Description: PGP signature
Order of logName evaluation for log EIP
Hi together, I'm struggling what would be the expected order for logName evaluation. The docs (https://camel.apache.org/components/4.0.x/eips/log-eip.html#_configuring_logging_name) says if not defined, it'll use the routeId set or a generated one. Looking into code of LogReifier (https://github.com/apache/camel/blob/3793981daa32567a25a2aa1628a986658f863171/core/camel-core-reifier/src/main/java/org/apache/camel/reifier/LogReifier.java#L70) it would use getLineNumberLoggerName() before any kind of routeId first. What is the wanted order code or doc? Seems to be a bug, anyway :) Regards, Benjamin OpenPGP_signature.asc Description: OpenPGP digital signature
Aw: Re: Manage health checks at runtime
Hi Clause, thx for the answer. I just recognized that Camel 3.16.0 got a "new" health check API. Will take a deep look into this, soon. Is the next LTS release planed, yet? Maybe 3.17.0? Regards, Benjamin Gesendet: Dienstag, 29. März 2022 um 21:56 Uhr Von: "Claus Ibsen" An: users@camel.apache.org Betreff: Re: Manage health checks at runtime Hi Health checks can be excluded via patterns https://camel.apache.org/manual/health-check.html#_excluding_health_checks The remainder active health checks can be enabled/disabled individually with the setEnabled setter, but that requires to get hold of the health check via its ID etc. There is a HealthCheckHelper method with some lookup methods. Also health checks can/are enlisted as JMX MBeans so you can find them there too to disable On Mon, Mar 28, 2022 at 7:15 PM Benjamin Graf wrote: > > Hi, > > does anybody know a way to enable/disable route/consumer checks for > specific items at runtime. As I can see it's only possible to > enable/disable the complete repository itself and the HealthCheck once > computed seems not reconfigurable any more. > > Maybe worth for an enhancement? > > Regards > > Benjamin > -- Claus Ibsen - http://davsclaus.com[http://davsclaus.com] @davsclaus Camel in Action 2: https://www.manning.com/ibsen2[https://www.manning.com/ibsen2]
Manage health checks at runtime
Hi, does anybody know a way to enable/disable route/consumer checks for specific items at runtime. As I can see it's only possible to enable/disable the complete repository itself and the HealthCheck once computed seems not reconfigurable any more. Maybe worth for an enhancement? Regards Benjamin OpenPGP_signature Description: OpenPGP digital signature
bundleReplacements with karaf-maven-plugin
Hi, does anybody know how if possible I can replace a bundle from a feature if a bit "more complex". For example replace "wrap:mvn:com.oracle.database.jdbc/ojdbc8/..." with "wrap:mvn:com.oracle.database.jdbc/ojdbc11" Regards, Benjamin OpenPGP_signature Description: OpenPGP digital signature
Re: Copy over state for multicast eip
Hi, no, the problem is not the optimization into a simple boolean. It is the fact that the rollback flags a are copied at all. Before 3.1 those flags were not copied from child to parent when multicast done is processed. After 3.1 the flag is copied and does overwrite a possible still set to true flag on parent with definitely false if child exchange has been processed by errorhandler. This way there is no possible pattern I know, how to do a rollbackonlylast even through a multicast eip where I have to handle parent and child exchanges. Regards, Benjamin On 08.04.2021 17:22, Claus Ibsen wrote: Hi Ah okay so it's not the "too much" is copied over. But the fact before the rollback_last was stored as property, which had 3 states: null, true, false And now its optimized into a simple boolean that has: true, false On Wed, Apr 7, 2021 at 7:15 PM Benjamin Graf wrote: Hi Clause, well, the code is quite to complex to put it into an easy test case. But I can share the idea. We're using nested transaction to separate incoming MQ system from several transactional systems. In case of error we do disqualify message to kind of deadletter queue and rollback all actions already done. That's why we use rollbackonlylast feature to let initial jms transaction being committed successfully, while all other operations are rollbacked. But with multicast the rollbackonlylast of parent exchange is set to false again after child exchange has been handled by transactional errorhandler and copy of state in MulticastProcessor has been done. Since this change has been introduced with Camel 3.1 the question is whether too much information is copied from child to parent or not. Best regards Benjamin On 07.04.2021 15:42, Claus Ibsen wrote: Hi I suggest if you can put together a small example / unit test or something that demonstrates what you are doing and why you need to do custom error handling. And put it on github or in a JIRA ticket. On Tue, Apr 6, 2021 at 10:13 AM Benjamin Graf wrote: Hi together, https://issues.apache.org/jira/browse/CAMEL-14354 introduces a change to ExchangeHelper to copy internal state of child exchanges to parent exchanges. Especially the code addition from https://github.com/apache/camel/blob/a9fd03f1d022a48553207ab59e42f35b8cd6c325/core/camel-support/src/main/java/org/apache/camel/support/ExchangeHelper.java#L417-L418 is causing troubles for my custom error handling policy because rollback states are set to false on parent after errorhandler has set it back to false on child exchange and multicast does the copy over. This makes my transaction separation actually impossible for multicast use cases causing rollbacks to AMQ and DLQ the latter one. Is this really intended or maybe a bug/race condition of the patch after 3.1 ongoing? Best regards Benjamin OpenPGP_signature Description: OpenPGP digital signature
Re: Copy over state for multicast eip
Hi Clause, well, the code is quite to complex to put it into an easy test case. But I can share the idea. We're using nested transaction to separate incoming MQ system from several transactional systems. In case of error we do disqualify message to kind of deadletter queue and rollback all actions already done. That's why we use rollbackonlylast feature to let initial jms transaction being committed successfully, while all other operations are rollbacked. But with multicast the rollbackonlylast of parent exchange is set to false again after child exchange has been handled by transactional errorhandler and copy of state in MulticastProcessor has been done. Since this change has been introduced with Camel 3.1 the question is whether too much information is copied from child to parent or not. Best regards Benjamin On 07.04.2021 15:42, Claus Ibsen wrote: Hi I suggest if you can put together a small example / unit test or something that demonstrates what you are doing and why you need to do custom error handling. And put it on github or in a JIRA ticket. On Tue, Apr 6, 2021 at 10:13 AM Benjamin Graf wrote: Hi together, https://issues.apache.org/jira/browse/CAMEL-14354 introduces a change to ExchangeHelper to copy internal state of child exchanges to parent exchanges. Especially the code addition from https://github.com/apache/camel/blob/a9fd03f1d022a48553207ab59e42f35b8cd6c325/core/camel-support/src/main/java/org/apache/camel/support/ExchangeHelper.java#L417-L418 is causing troubles for my custom error handling policy because rollback states are set to false on parent after errorhandler has set it back to false on child exchange and multicast does the copy over. This makes my transaction separation actually impossible for multicast use cases causing rollbacks to AMQ and DLQ the latter one. Is this really intended or maybe a bug/race condition of the patch after 3.1 ongoing? Best regards Benjamin OpenPGP_signature Description: OpenPGP digital signature
Copy over state for multicast eip
Hi together, https://issues.apache.org/jira/browse/CAMEL-14354 introduces a change to ExchangeHelper to copy internal state of child exchanges to parent exchanges. Especially the code addition from https://github.com/apache/camel/blob/a9fd03f1d022a48553207ab59e42f35b8cd6c325/core/camel-support/src/main/java/org/apache/camel/support/ExchangeHelper.java#L417-L418 is causing troubles for my custom error handling policy because rollback states are set to false on parent after errorhandler has set it back to false on child exchange and multicast does the copy over. This makes my transaction separation actually impossible for multicast use cases causing rollbacks to AMQ and DLQ the latter one. Is this really intended or maybe a bug/race condition of the patch after 3.1 ongoing? Best regards Benjamin
Re: Definition of subscriptionname in Camel JMS-Endpoint does not work as expected
Hi all together,
just to keep the list informed. Issue is documented and fixed with
https://issues.apache.org/jira/browse/CAMEL-13864.
Regards
Benjamin
Am 13.08.2019 um 16:37 schrieb Benjamin Graf:
> Hi Claus,
>
> Sure ;-)
>
> Will have a look on it. I might create a patch on actual master. I think a
> backport to 2.x branch shouldn't be that hard.
>
> Regards
> Benjamin
>
> Gesendet: Dienstag, 13. August 2019 um 15:57 Uhr
> Von: "Claus Ibsen"
> An: users@camel.apache.org
> Betreff: Re: Re: Definition of subscriptionname in Camel JMS-Endpoint does
> not work as expected
> On Tue, Aug 13, 2019 at 2:50 PM Benjamin Graf wrote:
>> Hi,
>>
>> yes it seems non-durable shared subscription are not implemented correctly.
>> Subscription name should be set for non-durable as well.
>>
> Okay you are welcome to create a JIRA ticket and also PRs is welcome to fix
> this
>
>> Regards
>> Benjamin
>>
>>
>> Gesendet: Dienstag, 13. August 2019 um 11:57 Uhr
>> Von: "Claus Ibsen"
>> An: users@camel.apache.org
>> Betreff: Re: Definition of subscriptionname in Camel JMS-Endpoint does not
>> work as expected
>> Hi
>>
>> Shared subscription is something new in JMS 2.0.
>> So it may be a bug or not, I can't recall on top of my head. I suggest
>> you spend a bit time research and come back and tell us.
>>
>> On Tue, Aug 13, 2019 at 11:46 AM wrote:
>>> Dear Camel guys and girls,
>>>
>>>
>>> I have a question regarding the property "subscriptionName" which can be
>>> specified for a JMS-Consumer.
>>>
>>> First, here is my project setup:
>>>
>>> * Camel 2.24.1
>>> * Spring-Boot: 2.1.0.RELEASE
>>>
>>> I create a simple standalone JAR which just should consume from defined
>>> JMS-Queues and/or JMS-Topics.
>>> Therefore I wrote a simple Route and configured my JMS-Endpoint like this:
>>>
>>> jms:topic:mytopicstring?connectionFactory=#connectionFactory&defaultTaskExecutorType=SimpleAsync&bridgeErrorHandler=true&subscriptionShared=true&subscriptionName=jmsc_lokal
>>>
>>> As you can see I use a shared subscription in combination with a
>>> subscriptionName as I want to be able to identify my subscription as long
>>> as it lasts.
>>> The problem is now that this subscriptionName is never used. Instead my
>>> subscription on the topic uses the default subscription name which is the
>>> class name: org.apache.camel.component.jms.EndpointMessageListener.
>>>
>>> In the documentation on GitHub for Camel Version 2.24.1 it is written that
>>> the subscriptionName can be used for shared subscription too.:
>>>
>>>
>>> subscriptionName (consumer)
>>>
>>>
>>> Set the name of a subscription to create. To be applied in case of a topic
>>> (pub-sub domain) with a shared or durable subscription. The subscription
>>> name needs to be unique within this client’s JMS client id. Default is the
>>> class name of the specified message listener. Note: Only 1 concurrent
>>> consumer (which is the default of this message listener container) is
>>> allowed for each subscription, except for a shared subscription (which
>>> requires JMS 2.0).
>>>
>>>
>>> If I debug into the method
>>> org.apache.camel.component.jms.JmsEndpoint#configureListenerContainer
>>> I can see that the subscriptionName is in fact only used when the
>>> subscription is durable (which I don't want to have):
>>>
>>>
>>> // now configure the JMS 2.0 API
>>> if (configuration.getDurableSubscriptionName() != null) {
>>> listenerContainer.setDurableSubscriptionName(configuration.getDurableSubscriptionName());
>>> } else if (configuration.isSubscriptionDurable()) {
>>> listenerContainer.setSubscriptionDurable(true);
>>> if (configuration.getSubscriptionName() != null) {
>>> listenerContainer.setSubscriptionName(configuration.getSubscriptionName());
>>> }
>>> }
>>> listenerContainer.setSubscriptionShared(configuration.isSubscriptionShared());
>>>
>>> So I am wondering if I just misunderstood the documentation or if it is
>>> indeed a bug that the subscriptionName can only be used in combination with
>>> a durable subscription?
>>> Could you please tell me what you think?
>>>
>>> If it is a bug I can create a JIRA-Issue and provide a hotfix if you want.
>>> If I j
Aw: Re: Re: Definition of subscriptionname in Camel JMS-Endpoint does not work as expected
Hi Claus,
Sure ;-)
Will have a look on it. I might create a patch on actual master. I think a
backport to 2.x branch shouldn't be that hard.
Regards
Benjamin
Gesendet: Dienstag, 13. August 2019 um 15:57 Uhr
Von: "Claus Ibsen"
An: users@camel.apache.org
Betreff: Re: Re: Definition of subscriptionname in Camel JMS-Endpoint does not
work as expected
On Tue, Aug 13, 2019 at 2:50 PM Benjamin Graf wrote:
>
> Hi,
>
> yes it seems non-durable shared subscription are not implemented correctly.
> Subscription name should be set for non-durable as well.
>
Okay you are welcome to create a JIRA ticket and also PRs is welcome to fix this
> Regards
> Benjamin
>
>
> Gesendet: Dienstag, 13. August 2019 um 11:57 Uhr
> Von: "Claus Ibsen"
> An: users@camel.apache.org
> Betreff: Re: Definition of subscriptionname in Camel JMS-Endpoint does not
> work as expected
> Hi
>
> Shared subscription is something new in JMS 2.0.
> So it may be a bug or not, I can't recall on top of my head. I suggest
> you spend a bit time research and come back and tell us.
>
> On Tue, Aug 13, 2019 at 11:46 AM wrote:
> >
> > Dear Camel guys and girls,
> >
> >
> > I have a question regarding the property "subscriptionName" which can be
> > specified for a JMS-Consumer.
> >
> > First, here is my project setup:
> >
> > * Camel 2.24.1
> > * Spring-Boot: 2.1.0.RELEASE
> >
> > I create a simple standalone JAR which just should consume from defined
> > JMS-Queues and/or JMS-Topics.
> > Therefore I wrote a simple Route and configured my JMS-Endpoint like this:
> >
> > jms:topic:mytopicstring?connectionFactory=#connectionFactory&defaultTaskExecutorType=SimpleAsync&bridgeErrorHandler=true&subscriptionShared=true&subscriptionName=jmsc_lokal
> >
> > As you can see I use a shared subscription in combination with a
> > subscriptionName as I want to be able to identify my subscription as long
> > as it lasts.
> > The problem is now that this subscriptionName is never used. Instead my
> > subscription on the topic uses the default subscription name which is the
> > class name: org.apache.camel.component.jms.EndpointMessageListener.
> >
> > In the documentation on GitHub for Camel Version 2.24.1 it is written that
> > the subscriptionName can be used for shared subscription too.:
> >
> >
> > subscriptionName (consumer)
> >
> >
> > Set the name of a subscription to create. To be applied in case of a topic
> > (pub-sub domain) with a shared or durable subscription. The subscription
> > name needs to be unique within this client’s JMS client id. Default is the
> > class name of the specified message listener. Note: Only 1 concurrent
> > consumer (which is the default of this message listener container) is
> > allowed for each subscription, except for a shared subscription (which
> > requires JMS 2.0).
> >
> >
> > If I debug into the method
> > org.apache.camel.component.jms.JmsEndpoint#configureListenerContainer
> > I can see that the subscriptionName is in fact only used when the
> > subscription is durable (which I don't want to have):
> >
> >
> > // now configure the JMS 2.0 API
> > if (configuration.getDurableSubscriptionName() != null) {
> > listenerContainer.setDurableSubscriptionName(configuration.getDurableSubscriptionName());
> > } else if (configuration.isSubscriptionDurable()) {
> > listenerContainer.setSubscriptionDurable(true);
> > if (configuration.getSubscriptionName() != null) {
> > listenerContainer.setSubscriptionName(configuration.getSubscriptionName());
> > }
> > }
> > listenerContainer.setSubscriptionShared(configuration.isSubscriptionShared());
> >
> > So I am wondering if I just misunderstood the documentation or if it is
> > indeed a bug that the subscriptionName can only be used in combination with
> > a durable subscription?
> > Could you please tell me what you think?
> >
> > If it is a bug I can create a JIRA-Issue and provide a hotfix if you want.
> > If I just misunderstood something it would be great if you could help me
> > out with this one.
> >
> >
> > Best regards and thanks a lot in advance,
> > Daniel Novak
> >
> >
> > **
> > This message and any attachment are confidential and may be privileged or
> > otherwise protected from disclosure. If you are not the intended recipient,
> > please call or e-mail the sender and delete the message and any attachment
> &
Aw: Re: Definition of subscriptionname in Camel JMS-Endpoint does not work as expected
Hi,
yes it seems non-durable shared subscription are not implemented correctly.
Subscription name should be set for non-durable as well.
Regards
Benjamin
Gesendet: Dienstag, 13. August 2019 um 11:57 Uhr
Von: "Claus Ibsen"
An: users@camel.apache.org
Betreff: Re: Definition of subscriptionname in Camel JMS-Endpoint does not work
as expected
Hi
Shared subscription is something new in JMS 2.0.
So it may be a bug or not, I can't recall on top of my head. I suggest
you spend a bit time research and come back and tell us.
On Tue, Aug 13, 2019 at 11:46 AM wrote:
>
> Dear Camel guys and girls,
>
>
> I have a question regarding the property "subscriptionName" which can be
> specified for a JMS-Consumer.
>
> First, here is my project setup:
>
> * Camel 2.24.1
> * Spring-Boot: 2.1.0.RELEASE
>
> I create a simple standalone JAR which just should consume from defined
> JMS-Queues and/or JMS-Topics.
> Therefore I wrote a simple Route and configured my JMS-Endpoint like this:
>
> jms:topic:mytopicstring?connectionFactory=#connectionFactory&defaultTaskExecutorType=SimpleAsync&bridgeErrorHandler=true&subscriptionShared=true&subscriptionName=jmsc_lokal
>
> As you can see I use a shared subscription in combination with a
> subscriptionName as I want to be able to identify my subscription as long as
> it lasts.
> The problem is now that this subscriptionName is never used. Instead my
> subscription on the topic uses the default subscription name which is the
> class name: org.apache.camel.component.jms.EndpointMessageListener.
>
> In the documentation on GitHub for Camel Version 2.24.1 it is written that
> the subscriptionName can be used for shared subscription too.:
>
>
> subscriptionName (consumer)
>
>
> Set the name of a subscription to create. To be applied in case of a topic
> (pub-sub domain) with a shared or durable subscription. The subscription name
> needs to be unique within this client’s JMS client id. Default is the class
> name of the specified message listener. Note: Only 1 concurrent consumer
> (which is the default of this message listener container) is allowed for each
> subscription, except for a shared subscription (which requires JMS 2.0).
>
>
> If I debug into the method
> org.apache.camel.component.jms.JmsEndpoint#configureListenerContainer
> I can see that the subscriptionName is in fact only used when the
> subscription is durable (which I don't want to have):
>
>
> // now configure the JMS 2.0 API
> if (configuration.getDurableSubscriptionName() != null) {
> listenerContainer.setDurableSubscriptionName(configuration.getDurableSubscriptionName());
> } else if (configuration.isSubscriptionDurable()) {
> listenerContainer.setSubscriptionDurable(true);
> if (configuration.getSubscriptionName() != null) {
> listenerContainer.setSubscriptionName(configuration.getSubscriptionName());
> }
> }
> listenerContainer.setSubscriptionShared(configuration.isSubscriptionShared());
>
> So I am wondering if I just misunderstood the documentation or if it is
> indeed a bug that the subscriptionName can only be used in combination with a
> durable subscription?
> Could you please tell me what you think?
>
> If it is a bug I can create a JIRA-Issue and provide a hotfix if you want.
> If I just misunderstood something it would be great if you could help me out
> with this one.
>
>
> Best regards and thanks a lot in advance,
> Daniel Novak
>
>
> **
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> please call or e-mail the sender and delete the message and any attachment
> from your system. If you are not the intended recipient, you must not copy
> this message or attachment or disclose the contents to any other person.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive later or
> incomplete, or contain viruses. DZ PRIVATBANK therefore does not accept
> liability for any errors or omissions in the contents of this message which
> arises as a result of e-mail transmission. If verification is required please
> request a hard-copy version. This message is provided for informational
> purposes only and should not be construed as a solicitation or offer to buy
> or sell any securities or related financial instruments. DZ PRIVATBANK does
> not warrant that incoming e-mails will be processed within a certain period
> of time. For security reasons, DZ PRIVATBANK does not accept any instructions
> that must be in writing (financial transactions, changes of address, etc.)
> sent by e-mail. If a message is urgent, please contact us by telephone.
> **
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2:
https://www.manning.com/
Overload CamelContextFactoryBean
Hi, does anybody knows a way to overload/extend the spring osgi implementation of CamelContextFactoryBean? I actually wants to extend the basic implementation to do some further magic. :-) There seems to be some tricky ways to do it with an own SpringNamespaceHandler and extending the camel-spring.xsd but I failed so far. :-( Thx for any help Benjamin
Re: Issue with Camel annotations not being processed [OSGi, Blueprint, Javaconfig]
Hi Chris,
I recommend looking for Gemini blueprint not Aries since Gemini is much more
spring aware. But I'm no blueprint expert. So Aries might work either.
Benjamin
Christopher Love schrieb:
>So the recommendation is to move to Aries Blueprint? Is there support
>for
>the context component scan or will I need to setup a different wiring
>pattern?
>
>Thanks
>
>Chris
>
>On Mon, Nov 5, 2012 at 12:45 PM, Benjamin Graf
>wrote:
>
>> Hi Chris,
>>
>> I think you won't be successful with a spring-dm support issue since
>> spring-dm
>> development has been stopped in 2009.
>> Have a look on gemini-blueprint (spring-dm 2.0+) and discussion on
>> camel-dev
>> about introducing s new component to support gemini-blueprint in a
>future
>> camel
>> version.
>>
>> Regards,
>> Benjamin
>>
>> On 05.11.2012 20:32, Christopher Love wrote:
>> > Claus
>> >
>> > @Value was added in spring 3.1 - so this is a spring dm support
>issue?
>> Let
>> > me see if camel is using the latest flavor of the month
>> >
>> > Chris
>> >
>> > On Mon, Nov 5, 2012 at 8:09 AM, Claus Ibsen
>> wrote:
>> >
>> >> On Fri, Nov 2, 2012 at 10:17 PM, Christopher Love
>> >> wrote:
>> >>> Claus and other
>> >>>
>> >>> I am just coming up to speed on blueprint / osgi, and I think I
>may be
>> >>> running into the same form of issue. @Value with property place
>holder
>> >>> does not seem to be populating when the route is deployed inside
>of
>> >> Karaf.
>> >>> In unit test it populates the string correctly running inside of
>Karaf
>> >> it
>> >>> does not.
>> >>>
>> >> I assume @Value is from Spring Framework? And when was this added
>to
>> >> Spring? Anyone knows?
>> >> Maybe Spring-DM 1.2.1 don't support it
>> >>
>> >>
>> >>> Here is some pertinent code:
>> >>>
>> >>> @Component
>> >>> public class EdiTmpClaimRoute extends SpringRouteBuilder {
>> >>>
>> >>> private @Value("${file.path}")
>> >>> String filePath;
>> >>>
>> >>> @Override
>> >>> public void configure() throws Exception {
>> >>>
>> >>
>from("activemq:claim-queue?concurrentConsumers=50&asyncConsumer=true")
>> >>> .routeId("edi-qsi-tmp-file-route")
>> >>>
>> >>>
>> >>
>>
>.to("file:"+filePath+"/?fileName=${date:now:MMdd}-qsi-${exchangeId}.txt");
>> >>> }
>> >>>
>> >>> }
>> >>>
>> >>> @Configuration
>> >>> @PropertySource("classpath:smilebrands-edi.properties")
>> >>> @ComponentScan(basePackages = { "com.smilebrands.edi.camel",
>> >>> "com.smilebrands.edi.core.qsi" })
>> >>> public class CamelServerConfig implements InitializingBean,
>> >>> BundleContextAware, ApplicationContextAware {
>> >>>
>> >>> private BundleContext bundleContext;
>> >>>
>> >>> public BundleContext getBundleContext() {
>> >>> return bundleContext;
>> >>> }
>> >>>
>> >>> public void setBundleContext(BundleContext bundleContext) {
>> >>> this.bundleContext = bundleContext;
>> >>> }
>> >>>
>> >>> private ApplicationContext applicationContext;
>> >>>
>> >>> public void setApplicationContext(ApplicationContext ac) {
>> >>> this.applicationContext = ac;
>> >>> }
>> >>>
>> >>> protected ApplicationContext getApplicationContext() {
>> >>> return this.applicationContext;
>> >>> }
>> >>>
>> >>> @Bean
>> >>> public ActiveMQComponent amq(@Value("${broker.url}") String
>> brokerURL)
>> >> {
>> >>> ActiveMQComponent activeMQComponent = new
>ActiveMQComponent();
>> >>> activeMQComponent.setBrokerURL(brokerURL);
>> >>> return activeMQComponent;
>> >>> }
>> >>>
>> >>> @Override
>> >>> public void afterPropertiesSet() throws Exception {
>> &g
Re: Issue with Camel annotations not being processed [OSGi, Blueprint, Javaconfig]
Hi Chris,
I think you won't be successful with a spring-dm support issue since spring-dm
development has been stopped in 2009.
Have a look on gemini-blueprint (spring-dm 2.0+) and discussion on camel-dev
about introducing s new component to support gemini-blueprint in a future camel
version.
Regards,
Benjamin
On 05.11.2012 20:32, Christopher Love wrote:
> Claus
>
> @Value was added in spring 3.1 - so this is a spring dm support issue? Let
> me see if camel is using the latest flavor of the month
>
> Chris
>
> On Mon, Nov 5, 2012 at 8:09 AM, Claus Ibsen wrote:
>
>> On Fri, Nov 2, 2012 at 10:17 PM, Christopher Love
>> wrote:
>>> Claus and other
>>>
>>> I am just coming up to speed on blueprint / osgi, and I think I may be
>>> running into the same form of issue. @Value with property place holder
>>> does not seem to be populating when the route is deployed inside of
>> Karaf.
>>> In unit test it populates the string correctly running inside of Karaf
>> it
>>> does not.
>>>
>> I assume @Value is from Spring Framework? And when was this added to
>> Spring? Anyone knows?
>> Maybe Spring-DM 1.2.1 don't support it
>>
>>
>>> Here is some pertinent code:
>>>
>>> @Component
>>> public class EdiTmpClaimRoute extends SpringRouteBuilder {
>>>
>>> private @Value("${file.path}")
>>> String filePath;
>>>
>>> @Override
>>> public void configure() throws Exception {
>>>
>> from("activemq:claim-queue?concurrentConsumers=50&asyncConsumer=true")
>>> .routeId("edi-qsi-tmp-file-route")
>>>
>>>
>> .to("file:"+filePath+"/?fileName=${date:now:MMdd}-qsi-${exchangeId}.txt");
>>> }
>>>
>>> }
>>>
>>> @Configuration
>>> @PropertySource("classpath:smilebrands-edi.properties")
>>> @ComponentScan(basePackages = { "com.smilebrands.edi.camel",
>>> "com.smilebrands.edi.core.qsi" })
>>> public class CamelServerConfig implements InitializingBean,
>>> BundleContextAware, ApplicationContextAware {
>>>
>>> private BundleContext bundleContext;
>>>
>>> public BundleContext getBundleContext() {
>>> return bundleContext;
>>> }
>>>
>>> public void setBundleContext(BundleContext bundleContext) {
>>> this.bundleContext = bundleContext;
>>> }
>>>
>>> private ApplicationContext applicationContext;
>>>
>>> public void setApplicationContext(ApplicationContext ac) {
>>> this.applicationContext = ac;
>>> }
>>>
>>> protected ApplicationContext getApplicationContext() {
>>> return this.applicationContext;
>>> }
>>>
>>> @Bean
>>> public ActiveMQComponent amq(@Value("${broker.url}") String brokerURL)
>> {
>>> ActiveMQComponent activeMQComponent = new ActiveMQComponent();
>>> activeMQComponent.setBrokerURL(brokerURL);
>>> return activeMQComponent;
>>> }
>>>
>>> @Override
>>> public void afterPropertiesSet() throws Exception {
>>> // TODO Auto-generated method stub
>>>
>>> }
>>>
>>> @Bean
>>> public static PropertySourcesPlaceholderConfigurer
>>> propertySourcesPlaceholderConfigurer() {
>>> return new PropertySourcesPlaceholderConfigurer();
>>> }
>>>
>>> }
>>>
>>> camel-context.xml
>>>
>>>
>>> http://www.springframework.org/schema/beans";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xmlns:context="http://www.springframework.org/schema/context";
>>> xmlns:camel="http://camel.apache.org/schema/spring";
>>> xsi:schemaLocation="
>>> http://www.springframework.org/schema/beans
>>> http://www.springframework.org/schema/beans/spring-beans.xsd
>>> http://www.springframework.org/schema/context
>>> http://www.springframework.org/schema/context/spring-context.xsd
>>>http://camel.apache.org/schema/spring
>>> http://camel.apache.org/schema/spring/camel-spring.xsd";
>>> >
>>>
>>> http://camel.apache.org/schema/spring";>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> What are your recommendations? You are stating to use blueprint, but
>> does
>>> blueprint have the same type of capabilities?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>> On Wed, Sep 5, 2012 at 7:42 AM, Claus Ibsen
>> wrote:
Hi
Using Aries Blueprint should work fine.
There is possible a need for a Gemini integration with Camel to make
this work out of the box.
Fell free to help out, and take a look at camel-blueprint, which is
the component that integrates with Aries Blueprint.
Yeah that should maybe have been named camel-blueprint-aries, to leave
room for camel-blueprint-gemini,
On Tue, Sep 4, 2012 at 3:24 PM, ladoe00 wrote:
> Hi,
>
> I used to have a working system using Spring-OSGi, XML configs and
Camel
> 2.5 and I thought it would be great to upgrade to the latest version
>> for
all
> those components. So I am now using Gemini Blueprint (replacement for
> Spring-OSGi), Spring Java config to get rid of XML and Camel 2.10.1.
>> I
have
> converted every XML file to be @Configuration classes with
>> RouteBuilders,
> which I think is great, but now I am having problems injec
Re: Camel context autostartup
That is exactly the way I have already tried. But the spring-dm extender thread was a different one than the one the camel context was later starting from. NO_START is a ThreadLocal variable. :-( I hope there is way to get this invoked before start but in between the same thread. Benjamin Claus Ibsen schrieb: >On Tue, Oct 30, 2012 at 3:38 PM, Benjamin Graf >wrote: >> Hi Claus, >> >> Thanks so far. But did you find a workaround for setting the NO_START >flag? >> > >Maybe you can set it using a in Spring? Its a static method. >Somehow configure in Spring XML to invoke this NO_START method and set >its value to false. > > > > > >> Regards, >> Benjamin >> >> Original-Nachricht >>> Datum: Tue, 30 Oct 2012 15:23:49 +0100 >>> Von: Claus Ibsen >>> An: users@camel.apache.org >>> Betreff: Re: Camel context autostartup >> >>> Hi >>> >>> The documentation for autoStartup did indicate the current behavior >>> >http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/RuntimeConfiguration.html#setAutoStartup(java.lang.Boolean) >>> >>> I have logged a ticket >>> https://issues.apache.org/jira/browse/CAMEL-5759 >>> >>> >>> On Mon, Oct 29, 2012 at 2:37 PM, Benjamin Graf > >>> wrote: >>> > >>> > Original-Nachricht >>> >> Datum: Mon, 29 Oct 2012 13:20:09 +0100 >>> >> Von: Claus Ibsen >>> >> An: users@camel.apache.org >>> >> Betreff: Re: Camel context autostartup >>> > >>> >> On Mon, Oct 29, 2012 at 1:09 PM, Benjamin Graf > >>> >> wrote: >>> >> > The "poor" OSGi runtime is JBoss OSGi which is still a >technology >>> >> preview but is a feature of JBoss AS7. >>> >> > >>> >> > I know Karaf but it is no alternative for me. Might change >sometime >>> if >>> >> karaf has been integrated into JBoss. >>> >> > >>> >> > May be the Fuse (RedHat) guys out there can tell something >about >>> that! >>> >> ;-) >>> >> >>> >> I could tell you, but then I would have to kill you :) Okay just >>> >> kidding of course. >>> > >>> > :-) >>> > >>> >> >>> >> I know the autoStartup name is a poor name on the >but >>> >> it was as said inheirted from the routes. >>> >> Are you using spring-dm or OSGi Blueprint? I think in the latter >we >>> >> have a sort of a "hack" to disable starting CamelContext, which >is >>> >> used for some special tests. There is a static method on >>> >> SpringCamelContext which can be set to true to not start. >>> > >>> > Yes I'm using spring-dm and tried to set NO_START to false, but I >always >>> got the wrong thread. Maybe you know a good way to solve that? >>> > >>> >> >>> >> As we need to preserve backwards compatibility I wonder if we >should >>> >> introduce a new option on CamelContext to instruct it to skip >>> >> starting. But if so, what should it do? >>> >> >>> >> How would you start it? As it would possible need some logic to >at >>> >> least bootstrap a piece so it can either >>> >> - enlist a CamelContextMBean in JMX so you can start it from JMX. >>> >> - register a CamelContext in OSGi service registry so you can >start it >>> >> from OSGi >>> >> - or as now, but just have its state listed as started=false, >>> >> stopped=true. But do all its boostrap logic to enlist routes im >JMX, >>> >> osgi stuff and whatnot. >>> > >>> > Well, I would prefer something like: >>> > - enlist a CamelContextMBean in JMX so you can start/stop it from >JMX. >>> > Yes I know in OSGi it is quite another managed lifecycle, but so >you can >>> autostart stuff around the camel context to be preinitialized. >>> > - state listed as started=false (just do not invoke the stuff >start() or >>> as less as possible) >>> > >>> >> >>> >> >>> >> >>> >> >>> >> > >>> >> > Original-Nachricht >>> >> >> Datum: Mon, 29 Oct 2012 12:21:24 +0100 >>&g
Re: Camel context autostartup
Hi Claus, Thanks so far. But did you find a workaround for setting the NO_START flag? Regards, Benjamin Original-Nachricht > Datum: Tue, 30 Oct 2012 15:23:49 +0100 > Von: Claus Ibsen > An: users@camel.apache.org > Betreff: Re: Camel context autostartup > Hi > > The documentation for autoStartup did indicate the current behavior > http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/RuntimeConfiguration.html#setAutoStartup(java.lang.Boolean) > > I have logged a ticket > https://issues.apache.org/jira/browse/CAMEL-5759 > > > On Mon, Oct 29, 2012 at 2:37 PM, Benjamin Graf > wrote: > > > > Original-Nachricht > >> Datum: Mon, 29 Oct 2012 13:20:09 +0100 > >> Von: Claus Ibsen > >> An: users@camel.apache.org > >> Betreff: Re: Camel context autostartup > > > >> On Mon, Oct 29, 2012 at 1:09 PM, Benjamin Graf > >> wrote: > >> > The "poor" OSGi runtime is JBoss OSGi which is still a technology > >> preview but is a feature of JBoss AS7. > >> > > >> > I know Karaf but it is no alternative for me. Might change sometime > if > >> karaf has been integrated into JBoss. > >> > > >> > May be the Fuse (RedHat) guys out there can tell something about > that! > >> ;-) > >> > >> I could tell you, but then I would have to kill you :) Okay just > >> kidding of course. > > > > :-) > > > >> > >> I know the autoStartup name is a poor name on the but > >> it was as said inheirted from the routes. > >> Are you using spring-dm or OSGi Blueprint? I think in the latter we > >> have a sort of a "hack" to disable starting CamelContext, which is > >> used for some special tests. There is a static method on > >> SpringCamelContext which can be set to true to not start. > > > > Yes I'm using spring-dm and tried to set NO_START to false, but I always > got the wrong thread. Maybe you know a good way to solve that? > > > >> > >> As we need to preserve backwards compatibility I wonder if we should > >> introduce a new option on CamelContext to instruct it to skip > >> starting. But if so, what should it do? > >> > >> How would you start it? As it would possible need some logic to at > >> least bootstrap a piece so it can either > >> - enlist a CamelContextMBean in JMX so you can start it from JMX. > >> - register a CamelContext in OSGi service registry so you can start it > >> from OSGi > >> - or as now, but just have its state listed as started=false, > >> stopped=true. But do all its boostrap logic to enlist routes im JMX, > >> osgi stuff and whatnot. > > > > Well, I would prefer something like: > > - enlist a CamelContextMBean in JMX so you can start/stop it from JMX. > > Yes I know in OSGi it is quite another managed lifecycle, but so you can > autostart stuff around the camel context to be preinitialized. > > - state listed as started=false (just do not invoke the stuff start() or > as less as possible) > > > >> > >> > >> > >> > >> > > >> > Original-Nachricht > >> >> Datum: Mon, 29 Oct 2012 12:21:24 +0100 > >> >> Von: Claus Ibsen > >> >> An: users@camel.apache.org > >> >> Betreff: Re: Camel context autostartup > >> > > >> >> On Mon, Oct 29, 2012 at 11:36 AM, Benjamin Graf > > >> >> wrote: > >> >> > > >> >> > Original-Nachricht > >> >> >> Datum: Mon, 29 Oct 2012 10:30:36 +0100 > >> >> >> Von: Claus Ibsen > >> >> >> An: users@camel.apache.org > >> >> >> Betreff: Re: Camel context autostartup > >> >> > > >> >> >> On Mon, Oct 29, 2012 at 10:25 AM, Benjamin Graf > >> > >> >> >> wrote: > >> >> >> > Hi Claus, > >> >> >> > > >> >> >> > thanks so far. But does any method exists to avoid auto > starting > >> >> context > >> >> >> using Spring OSGi with bundles activated? > >> >> >> > > >> >> >> > >> >> >> No, but you can if possible just dont start the bundle itself. > And > >> >> >> then start the bundle to start Camel. > >> >> > > >> >> > Well, th
Re: Camel context autostartup
Original-Nachricht > Datum: Mon, 29 Oct 2012 13:20:09 +0100 > Von: Claus Ibsen > An: users@camel.apache.org > Betreff: Re: Camel context autostartup > On Mon, Oct 29, 2012 at 1:09 PM, Benjamin Graf > wrote: > > The "poor" OSGi runtime is JBoss OSGi which is still a technology > preview but is a feature of JBoss AS7. > > > > I know Karaf but it is no alternative for me. Might change sometime if > karaf has been integrated into JBoss. > > > > May be the Fuse (RedHat) guys out there can tell something about that! > ;-) > > I could tell you, but then I would have to kill you :) Okay just > kidding of course. :-) > > I know the autoStartup name is a poor name on the but > it was as said inheirted from the routes. > Are you using spring-dm or OSGi Blueprint? I think in the latter we > have a sort of a "hack" to disable starting CamelContext, which is > used for some special tests. There is a static method on > SpringCamelContext which can be set to true to not start. Yes I'm using spring-dm and tried to set NO_START to false, but I always got the wrong thread. Maybe you know a good way to solve that? > > As we need to preserve backwards compatibility I wonder if we should > introduce a new option on CamelContext to instruct it to skip > starting. But if so, what should it do? > > How would you start it? As it would possible need some logic to at > least bootstrap a piece so it can either > - enlist a CamelContextMBean in JMX so you can start it from JMX. > - register a CamelContext in OSGi service registry so you can start it > from OSGi > - or as now, but just have its state listed as started=false, > stopped=true. But do all its boostrap logic to enlist routes im JMX, > osgi stuff and whatnot. Well, I would prefer something like: - enlist a CamelContextMBean in JMX so you can start/stop it from JMX. Yes I know in OSGi it is quite another managed lifecycle, but so you can autostart stuff around the camel context to be preinitialized. - state listed as started=false (just do not invoke the stuff start() or as less as possible) > > > > > > > > Original-Nachricht > >> Datum: Mon, 29 Oct 2012 12:21:24 +0100 > >> Von: Claus Ibsen > >> An: users@camel.apache.org > >> Betreff: Re: Camel context autostartup > > > >> On Mon, Oct 29, 2012 at 11:36 AM, Benjamin Graf > >> wrote: > >> > > >> > Original-Nachricht > >> >> Datum: Mon, 29 Oct 2012 10:30:36 +0100 > >> >> Von: Claus Ibsen > >> >> An: users@camel.apache.org > >> >> Betreff: Re: Camel context autostartup > >> > > >> >> On Mon, Oct 29, 2012 at 10:25 AM, Benjamin Graf > > >> >> wrote: > >> >> > Hi Claus, > >> >> > > >> >> > thanks so far. But does any method exists to avoid auto starting > >> context > >> >> using Spring OSGi with bundles activated? > >> >> > > >> >> > >> >> No, but you can if possible just dont start the bundle itself. And > >> >> then start the bundle to start Camel. > >> > > >> > Well, that's a problem. My OSGi runtime does not support this feature > >> yet. :-( I was hoping camel autostartup is a good workaround. > >> > > >> > >> This must be a poor OSGi runtime, which can't manage lifecycle of the > >> bundles. > >> What do you use? > >> > >> And I am sure you are aware of Apache Karaf which is a great OSGi > runtime. > >> http://karaf.apache.org/ > >> > >> > >> >> > >> >> The problem is that there is a chicken-egg situation. CamelContext > >> >> need to be started so people can start it, using eg JMX etc. > >> >> And for that the context needs to be started to enlist in JMX etc. > >> > > >> > That's why I actually have written my own JMX Service for > >> starting/stopping context via JMX which is not dependant if context has > been started yet. > >> > > >> > Maybe worth changing that behaviour at all? > >> > > >> >> > >> >> > >> >> > >> >> > Benjamin > >> >> > > >> >> > Original-Nachricht > >> >> >> Datum: Mon, 29 Oct 2012 09:33:49 +0100 > >> >> >> Von: Claus Ibsen > >> >> >> An: users@camel.apache.org > >
Re: Camel context autostartup
The "poor" OSGi runtime is JBoss OSGi which is still a technology preview but is a feature of JBoss AS7. I know Karaf but it is no alternative for me. Might change sometime if karaf has been integrated into JBoss. May be the Fuse (RedHat) guys out there can tell something about that! ;-) Original-Nachricht > Datum: Mon, 29 Oct 2012 12:21:24 +0100 > Von: Claus Ibsen > An: users@camel.apache.org > Betreff: Re: Camel context autostartup > On Mon, Oct 29, 2012 at 11:36 AM, Benjamin Graf > wrote: > > > > Original-Nachricht > >> Datum: Mon, 29 Oct 2012 10:30:36 +0100 > >> Von: Claus Ibsen > >> An: users@camel.apache.org > >> Betreff: Re: Camel context autostartup > > > >> On Mon, Oct 29, 2012 at 10:25 AM, Benjamin Graf > >> wrote: > >> > Hi Claus, > >> > > >> > thanks so far. But does any method exists to avoid auto starting > context > >> using Spring OSGi with bundles activated? > >> > > >> > >> No, but you can if possible just dont start the bundle itself. And > >> then start the bundle to start Camel. > > > > Well, that's a problem. My OSGi runtime does not support this feature > yet. :-( I was hoping camel autostartup is a good workaround. > > > > This must be a poor OSGi runtime, which can't manage lifecycle of the > bundles. > What do you use? > > And I am sure you are aware of Apache Karaf which is a great OSGi runtime. > http://karaf.apache.org/ > > > >> > >> The problem is that there is a chicken-egg situation. CamelContext > >> need to be started so people can start it, using eg JMX etc. > >> And for that the context needs to be started to enlist in JMX etc. > > > > That's why I actually have written my own JMX Service for > starting/stopping context via JMX which is not dependant if context has been > started yet. > > > > Maybe worth changing that behaviour at all? > > > >> > >> > >> > >> > Benjamin > >> > > >> > Original-Nachricht > >> >> Datum: Mon, 29 Oct 2012 09:33:49 +0100 > >> >> Von: Claus Ibsen > >> >> An: users@camel.apache.org > >> >> Betreff: Re: Camel context autostartup > >> > > >> >> The autostartup options is for controlling if *routes* should be > auto > >> >> started or not. > >> >> Not the actual CamelContext itself. > >> >> > >> >> The naming could have been better, but the option was first on > > >> >> and then later inherited on to make a single switch. > >> >> > >> >> > >> >> On Sat, Oct 27, 2012 at 4:57 PM, Benjamin Graf > > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > can anybody explain me why camel context state is set to started > if > >> >> autostartup > >> >> > is set to false? This sound a bit odd to me. > >> >> > > >> >> > Best, > >> >> > Benjamin > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Claus Ibsen > >> >> - > >> >> Red Hat, Inc. > >> >> FuseSource is now part of Red Hat > >> >> Email: cib...@redhat.com > >> >> Web: http://fusesource.com > >> >> Twitter: davsclaus > >> >> Blog: http://davsclaus.com > >> >> Author of Camel in Action: http://www.manning.com/ibsen > >> > >> > >> > >> -- > >> Claus Ibsen > >> - > >> Red Hat, Inc. > >> FuseSource is now part of Red Hat > >> Email: cib...@redhat.com > >> Web: http://fusesource.com > >> Twitter: davsclaus > >> Blog: http://davsclaus.com > >> Author of Camel in Action: http://www.manning.com/ibsen > > > > -- > Claus Ibsen > - > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel context autostartup
Original-Nachricht > Datum: Mon, 29 Oct 2012 10:30:36 +0100 > Von: Claus Ibsen > An: users@camel.apache.org > Betreff: Re: Camel context autostartup > On Mon, Oct 29, 2012 at 10:25 AM, Benjamin Graf > wrote: > > Hi Claus, > > > > thanks so far. But does any method exists to avoid auto starting context > using Spring OSGi with bundles activated? > > > > No, but you can if possible just dont start the bundle itself. And > then start the bundle to start Camel. Well, that's a problem. My OSGi runtime does not support this feature yet. :-( I was hoping camel autostartup is a good workaround. > > The problem is that there is a chicken-egg situation. CamelContext > need to be started so people can start it, using eg JMX etc. > And for that the context needs to be started to enlist in JMX etc. That's why I actually have written my own JMX Service for starting/stopping context via JMX which is not dependant if context has been started yet. Maybe worth changing that behaviour at all? > > > > > Benjamin > > > > Original-Nachricht > >> Datum: Mon, 29 Oct 2012 09:33:49 +0100 > >> Von: Claus Ibsen > >> An: users@camel.apache.org > >> Betreff: Re: Camel context autostartup > > > >> The autostartup options is for controlling if *routes* should be auto > >> started or not. > >> Not the actual CamelContext itself. > >> > >> The naming could have been better, but the option was first on > >> and then later inherited on to make a single switch. > >> > >> > >> On Sat, Oct 27, 2012 at 4:57 PM, Benjamin Graf > >> wrote: > >> > Hi, > >> > > >> > can anybody explain me why camel context state is set to started if > >> autostartup > >> > is set to false? This sound a bit odd to me. > >> > > >> > Best, > >> > Benjamin > >> > > >> > >> > >> > >> -- > >> Claus Ibsen > >> - > >> Red Hat, Inc. > >> FuseSource is now part of Red Hat > >> Email: cib...@redhat.com > >> Web: http://fusesource.com > >> Twitter: davsclaus > >> Blog: http://davsclaus.com > >> Author of Camel in Action: http://www.manning.com/ibsen > > > > -- > Claus Ibsen > - > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel context autostartup
Hi Claus, thanks so far. But does any method exists to avoid auto starting context using Spring OSGi with bundles activated? Benjamin Original-Nachricht > Datum: Mon, 29 Oct 2012 09:33:49 +0100 > Von: Claus Ibsen > An: users@camel.apache.org > Betreff: Re: Camel context autostartup > The autostartup options is for controlling if *routes* should be auto > started or not. > Not the actual CamelContext itself. > > The naming could have been better, but the option was first on > and then later inherited on to make a single switch. > > > On Sat, Oct 27, 2012 at 4:57 PM, Benjamin Graf > wrote: > > Hi, > > > > can anybody explain me why camel context state is set to started if > autostartup > > is set to false? This sound a bit odd to me. > > > > Best, > > Benjamin > > > > > > -- > Claus Ibsen > - > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel context autostartup
Hi Christian, I'm using camel 2.10.0 but this is a "feature" also in trunk. have a look on start() in DefaultCamelContext super.start() get's called which is responsible for setting state to started. Well the context itself seems not started completely at all, all routes still inactive but it's quite silly if you are doing something like state monitoring and you are would assume the context is started. :-) Best, Benjamin On 28.10.2012 00:20, Christian Müller wrote: > Which version do you use? > Can you share your code? > > Best, > Christian > > On Sat, Oct 27, 2012 at 4:57 PM, Benjamin Graf wrote: > >> Hi, >> >> can anybody explain me why camel context state is set to started if >> autostartup >> is set to false? This sound a bit odd to me. >> >> Best, >> Benjamin >> >> > > -- > signature.asc Description: OpenPGP digital signature
Camel context autostartup
Hi, can anybody explain me why camel context state is set to started if autostartup is set to false? This sound a bit odd to me. Best, Benjamin signature.asc Description: OpenPGP digital signature
Re: Interceptable Producer
Hi, maybe there was a misunderstanding. I always wanted interception of dynamic routes created by a producer template but it is not working at all. While reading through the camel core code I recognized that camel routes builds static processor chains for endpoints handling and interception. Therefore I was asking for a possible workaround I actually can not see or if this is a missing feature worth adding into core. I hope everything is clear now. ;-) Best, Benjamin Raul Kripalani schrieb: >Ben, > >I'm re-reading the thread and there seems to be some contradiction. > >At first you stated that you want to avoid the interception, but now >you >want it and it's not happening at all? > >Could you check, please? > >Thanks. > >Sent from a mobile device >On 24 Oct 2012 20:01, "Benjamin Graf" wrote: > >> Hi folks, >> >> it seems that nobody has an answer to this question/problem? Is there >a >> proposal >> for dynamic creation of processor chains on the camel roadmap, yet? >Might >> be a >> topic worth thinking about! >> >> Best, >> Benjamin >> >> On 06.10.2012 08:28, Benjamin Graf wrote: >> > Hi Raúl, >> > >> > I tried to set explizit interception as mentioned, but it doesn't >work >> either. >> > If I read code right then interception is defined as a chain of >> processors when >> > route is initialized. I actually have not found any line of code in >> camel-core >> > where dynamic initialized ProducerTemplates are connected in that >> chains, maybe >> > not yet! :-) >> > >> > I already sent an example as requested by Christian. You might have >a >> look on it >> > to reproduce. It's build as spring osgi bundle so you have to use >> camel-springs >> > Main.class for standalone use. >> > >> > Thx so far. ;-) >> > >> > Best, >> > Benjamin >> > >> > On 04.10.2012 22:14, Raul Kripalani wrote: >> >> Interceptors live inside the Camel Context, and if the >ProducerTemplate >> is >> >> bound to the same context and the interception pattern matches, it >will >> >> also kick in for exchanges sent from the PT. >> >> >> >> Maybe you can set a condition using .when() so that only Exchanges >*not >> >> carrying a specific header* (e.g. 'FromProducerTemplate') are >ultimately >> >> intercepted. >> >> >> >> Then you set this header on all Exchanges sent via the >ProducerTemplate >> and >> >> you're interceptor should ignore them. >> >> >> >> Check out the second code example in the InterceptSendToEndpoint >doc >> >> section [1]. It shows how to use .when(). >> >> >> >> [1] >> >http://camel.apache.org/intercept.html#Intercept-InterceptSendToEndpoint >> >> >> >> Hope that helps, >> >> >> >> *Raúl Kripalani* >> >> Apache Camel Committer >> >> Enterprise Architect, Program Manager, Open Source Integration >> specialist >> >> http://about.me/raulkripalani | >> http://www.linkedin.com/in/raulkripalani >> >> http://blog.raulkr.net | twitter: @raulvk ><http://twitter.com/raulvk> >> >> >> >> On Thu, Oct 4, 2012 at 8:07 PM, Benjamin Graf > >> wrote: >> >> >> >>> Hi everybody, >> >>> >> >>> I actually have a problem with a route using a producertemplate >as a >> >>> splitter to >> >>> send several exchanges. Unfortunately the ProducerTemplate seems >to to >> be >> >>> interceptable by my written Interceptor. Does anybody know how I >might >> >>> workaround this? >> >>> >> >>> Thx >> >>> Benjamin >> >>> >> >>> >> >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: Interceptable Producer
Hi folks, it seems that nobody has an answer to this question/problem? Is there a proposal for dynamic creation of processor chains on the camel roadmap, yet? Might be a topic worth thinking about! Best, Benjamin On 06.10.2012 08:28, Benjamin Graf wrote: > Hi Raúl, > > I tried to set explizit interception as mentioned, but it doesn't work either. > If I read code right then interception is defined as a chain of processors > when > route is initialized. I actually have not found any line of code in camel-core > where dynamic initialized ProducerTemplates are connected in that chains, > maybe > not yet! :-) > > I already sent an example as requested by Christian. You might have a look on > it > to reproduce. It's build as spring osgi bundle so you have to use > camel-springs > Main.class for standalone use. > > Thx so far. ;-) > > Best, > Benjamin > > On 04.10.2012 22:14, Raul Kripalani wrote: >> Interceptors live inside the Camel Context, and if the ProducerTemplate is >> bound to the same context and the interception pattern matches, it will >> also kick in for exchanges sent from the PT. >> >> Maybe you can set a condition using .when() so that only Exchanges *not >> carrying a specific header* (e.g. 'FromProducerTemplate') are ultimately >> intercepted. >> >> Then you set this header on all Exchanges sent via the ProducerTemplate and >> you're interceptor should ignore them. >> >> Check out the second code example in the InterceptSendToEndpoint doc >> section [1]. It shows how to use .when(). >> >> [1] http://camel.apache.org/intercept.html#Intercept-InterceptSendToEndpoint >> >> Hope that helps, >> >> *Raúl Kripalani* >> Apache Camel Committer >> Enterprise Architect, Program Manager, Open Source Integration specialist >> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >> http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> >> >> On Thu, Oct 4, 2012 at 8:07 PM, Benjamin Graf wrote: >> >>> Hi everybody, >>> >>> I actually have a problem with a route using a producertemplate as a >>> splitter to >>> send several exchanges. Unfortunately the ProducerTemplate seems to to be >>> interceptable by my written Interceptor. Does anybody know how I might >>> workaround this? >>> >>> Thx >>> Benjamin >>> >>> signature.asc Description: OpenPGP digital signature
Re: Interceptable Producer
Hi Raúl, I tried to set explizit interception as mentioned, but it doesn't work either. If I read code right then interception is defined as a chain of processors when route is initialized. I actually have not found any line of code in camel-core where dynamic initialized ProducerTemplates are connected in that chains, maybe not yet! :-) I already sent an example as requested by Christian. You might have a look on it to reproduce. It's build as spring osgi bundle so you have to use camel-springs Main.class for standalone use. Thx so far. ;-) Best, Benjamin On 04.10.2012 22:14, Raul Kripalani wrote: > Interceptors live inside the Camel Context, and if the ProducerTemplate is > bound to the same context and the interception pattern matches, it will > also kick in for exchanges sent from the PT. > > Maybe you can set a condition using .when() so that only Exchanges *not > carrying a specific header* (e.g. 'FromProducerTemplate') are ultimately > intercepted. > > Then you set this header on all Exchanges sent via the ProducerTemplate and > you're interceptor should ignore them. > > Check out the second code example in the InterceptSendToEndpoint doc > section [1]. It shows how to use .when(). > > [1] http://camel.apache.org/intercept.html#Intercept-InterceptSendToEndpoint > > Hope that helps, > > *Raúl Kripalani* > Apache Camel Committer > Enterprise Architect, Program Manager, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> > > On Thu, Oct 4, 2012 at 8:07 PM, Benjamin Graf wrote: > >> Hi everybody, >> >> I actually have a problem with a route using a producertemplate as a >> splitter to >> send several exchanges. Unfortunately the ProducerTemplate seems to to be >> interceptable by my written Interceptor. Does anybody know how I might >> workaround this? >> >> Thx >> Benjamin >> >> signature.asc Description: OpenPGP digital signature
Interceptable Producer
Hi everybody, I actually have a problem with a route using a producertemplate as a splitter to send several exchanges. Unfortunately the ProducerTemplate seems to to be interceptable by my written Interceptor. Does anybody know how I might workaround this? Thx Benjamin signature.asc Description: OpenPGP digital signature
