Hi Gary,
Your CDI producers for the ActiveMQ component and the transaction manager look
OK (aside that you would have to destroy the connection factory in a dispose
method).
However The way you produce the UserTransaction may be problematic. With Weld
SE, you would typically implement
org.jbo
;> yourself, or
>> 4. set localTransactionMode to true so connection-level commit/rollback
>> are enabled.
>>
>>
>> Cheers,
>> Gary
>>
>>
>> On 6 November 2017 at 18:16, Gary Hodgson
>> wrote:
>>
>>> Hi Antoni
Hi Julien,
> On 12 Jun 2018, at 16:40, Julien Rivière
> wrote:
>
> Hello,
>
> First, thanks for the great framework.
>
> Second, I am kind of new to Apache Camel and I have a question regarding
> bean integration.
>
> Is it possible to use request scoped beans with Camel CDI ?
The Camel CDI
Hi Gary,
Your understanding is correct. Transaction support in Camel CDI depends on JTA.
That being said, it is possible to use it in a Java SE environment by adding
JTA API
and a transaction manager, as Narayana or Atomikos, in the classpath.
Then, you can produce Spring PlatformTransactionMan
sufficiently good example going then
> I'll post a link here in case it's useful for others.
That’d be awesome. I think having an example for Camel CDI / JMS (using Spring
PlatformTransactionManager) / JTA / Java SE would be very valuable.
> Cheers,
> Gary
>
> From:
> On 19 Feb 2019, at 18:26, Andrea Cosentino
> wrote:
>
> I'm fine with that tagline, but maybe we need to maintain something from the
> old one too? What do you think?
However I’m all in a world of containers, I tend to agree. One a the key value
of Camel, besides the awesome DSL and conne
Hi Rick,
You can find an example on how to use AdviceWith along with Arquillian and CDI
here:
https://github.com/apache/camel/blob/camel-2.24.1/components/camel-cdi/src/test/java/org/apache/camel/cdi/test/AdvisedRouteTest.java#L84-L92
The trick is to used a context that is not auto started:
h
Hi Luca, all,
+1 for Binding.
Users in the Kubernetes ecosystem may already be familiar with the term,
as it seems it's the choice made by projects like Knative and Service Binding,
to convey the general concept of "integrating" in their respective domain.
I find projecting that concept into the
Hi Gerald,
There are currently no options, but this is something we plan to provide.
Antonin
> On 16 Sep 2021, at 18:06, Gerald Kallas wrote:
>
> Hi all,
>
> we're experiencing that the Camel-K builders remain in the cluster after a
> successful build. Does there exist an option that the bui
When run an Integration with `kamel run -t prometheus.enabled=true`, a
PodMonitor resource is created for the Prometheus operator to reconcile and
configure Prometheus to scrape the Integration metrics endpoint.
The PodMonitor metadata must match that of the Prometheus operator, like the
namesp
ed PodMonitors" podmonitors=
> namespace=cattle-prometheus prometheus=cluster-monitoring
>
> My camel-k route is running at namespace "platform" and has no label
> like "prometheus=cluster-monitoring".
>
> Do you know how can I fix this? Adding additional
ster/spec/src/main/asciidoc/required-metrics.adoc#required-metrics).
>
> Is this correct? Why am I not getting that "org_apache_camel_" metrics?
>
> On Fri, Nov 26, 2021 at 9:13 AM Antonin Stefanutti
> wrote:
>>
>> It's likely that you need to configure
It seems you are mixing MicroProfile Metrics and Micrometer.
For using MicroProfile Metrics, you can find an example at:
https://github.com/astefanutti/camel-k-example-metrics/blob/master/Metrics.java#L44
Note that the extra //camel-k: dependency are probably not required, so I'd
suggest you re
uot;phase":"12","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2763238,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apac
- rancher-monitoring
> rules:
>alert: {}
> scrapeInterval: 60s
> secrets:
> - exporter-etcd-cert
> securityContext:
>fsGroup: 2000
>runAsNonRoot: true
>runAsUser: 1000
> serviceAccountName: cluster-monitoring
> serviceMonitorNamespaceSelector:
&
As you've pointed it, the problem is that the Prometheus operator does not
update the prometheus configuration.
That is consistent with why restarting fixes the issue, as it forces an update.
There may be some configuration parameters to update in the Prometheus
resource. It's strictly related
On 1 Dec 2021, at 18:08, Roberto Camelk
mailto:betonetotbo.cam...@gmail.com>> wrote:
I found a prometheus yaml config, who's using some scrape definitions
and I need to find the correlated metrics in camel-k.
Here are the scrape patterns:
https://github.com/alainpham/app-archetypes/blob/1f559e
rait.
> On Wed, Dec 1, 2021 at 2:39 PM Antonin Stefanutti
> wrote:
>>
>>
>>
>> On 1 Dec 2021, at 18:08, Roberto Camelk
>> mailto:betonetotbo.cam...@gmail.com>> wrote:
>>
>> I found a prometheus yaml config, who's using some scrape d
Generally, the tenancy unit in a Kubernetes cluster is the namespace.
For the operator, an instance can be deployed per tenant, or a single instance
can be deployed for the cluster.
Whatever options, the Camel K unit is the integration, whose Pod(s) host a
single Camel context.
For monitoring
rect
> approach, the namespace is the correct one.
>
> But, 1 Camel-K operator can switch between multiple contexts or for
> this I need 1 operator to each new context I want?
>
> On Tue, Dec 7, 2021 at 11:27 AM Antonin Stefanutti
> wrote:
>>
>> Generally, the
ot;, so to run my integration in that namespace I
> just run:
>
> kamel run MyIntegration.java -n poc
>
> Is this correct?
Yes, that's correct.
> On Tue, Dec 7, 2021 at 11:59 AM Antonin Stefanutti
> wrote:
>>
>> One possible multi-tenancy setup with C
using namespaces?
There is any official documentation about this?
On Tue, Dec 7, 2021 at 3:19 PM Antonin Stefanutti
mailto:anto...@stefanutti.fr.invalid>> wrote:
On 7 Dec 2021, at 18:31, Roberto Camelk
mailto:betonetotbo.cam...@gmail.com>> wrote:
Thanks again!
But, to run a new int
The build fails because it cannot find the specified registry Secret.
It seems you created the Secret in the `camel` namespace, while the operator
and the build run in the `default` namespace.
> On 9 Dec 2021, at 20:14, Roberto Camelk wrote:
>
> I installed camel-k in my "default" namespace in
It's possible the build process is killed because it's deadline has exceeded /
timed out.
You can get some details in the Build resource. Also you can try increasing the
build timeout parameter in the IntegrationPlatform.
> On 10 Dec 2021, at 12:29, Roberto Camelk wrote:
>
> Why sometimes the
The Camel K operator is a standard Kubernetes Deployment, which is typically
"operated" using the kubectl CLI, but can also be operated using the Kubernetes
HTTP API:
https://kubernetes.io/docs/concepts/overview/kubernetes-api/
On 14 Dec 2021, at 19:36, Roberto Camelk
mailto:betonetotbo.cam...
s resources.
That is what GUI clients typically use.
Ultimately, the kamel CLI is just a wrapper, that creates an Integration
resource using the Kubernetes API.
You can see what the Integration looks like by running:
$ kamel run your_integration_file -o yaml
> On Tue, Dec 14, 2021 at 3:56 PM An
Hi,
I had a look and the CLI indeeds return 0 when trait properties validation
fails, whether the property is passed with the -t option or with modeline.
It should be fixed with https://github.com/apache/camel-k/pull/2964
Thanks a lot for reporting the issue.
Antonin
On 28 Jan 2022, at 13:27,
Hi,
If you use the Pod build strategy, more context can be found:
https://github.com/apache/camel-k/issues/1031
If you use the routine build strategy, this has to be tested, but it probably
requires a bit of work.
On 8 Feb 2022, at 14:13, Roberto Camelk
mailto:betonetotbo.cam...@gmail.com>> w
Hi,
Generally, whether a new build is performed or not, a rollout deployment is
triggered, so the Pod(s) for the previous version won't be terminated until the
Pod(s) for the new version get ready. So there is no downtime, even if a new
build is performed.
> On 10 Mar 2022, at 15:50, Roberto C
Hi,
As Claus mentioned, there is nothing specific in Camel K to handle network
isolation.
What users do generally is to rely on network policies to isolate network
tenants:
https://kubernetes.io/docs/concepts/services-networking/network-policies/
And "manually" reflect the tenants in Camel K
Hi,
A webhook is generally implemented to hook into the k8s admission control.
To react to changes, watch requests are usually enough:
https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
On 23 Mar 2022, at 14:47, Roberto Camelk
mailto:betonetotbo.cam...@
Hi Christoph,
This is currently not supported. I agree this would be useful for a number of
use cases.
Ideally, this should be implemented consistently for all build strategies (s2i,
buildah, kaniko, spectrum).
Could you please create an issue?
Cheers,
Antonin
> On 12 Sep 2022, at 16:24, Chr
Hi Nicolas,
There is some sort of cyclic dependency in your code from the CDI standpoint.
You have an injection point for @Uri("jms:...") while your have the producer
method for the component in the same bean.
I would suggest you either move the producer method in a separate bean, like
JmsComp
> On 25 Apr 2016, at 15:20, Claus Ibsen wrote:
>
> On Mon, Apr 25, 2016 at 3:15 PM, Antonin Stefanutti
> wrote:
>> Hi Nicolas,
>>
>> There is some sort of cyclic dependency in your code from the CDI standpoint.
>>
>> You have an injection poi
Hi Nicolas,
This is a very good point. There exist a couple of options. CDI implementations
offer APIs to bootstrap the containers, like [1]. You may be interested by
DeltaSpike container control module [2] (which is actually being used by the
camel:run plugin). CDI 2.0 will bring a standard wa
Hi,
You can declare any kind of beans with @Produces. Whenever Camel looks up for a
named bean via the Camel registry, it will retrieve a reference to the
corresponding named bean declared with @Produces.
In your example below, what exactly does not work with the produceConfig
producer method?
> On 06 May 2016, at 10:21, kalber wrote:
>
> -- In your example below, what exactly does not work with the produceConfig
> producer method?
> Simply 'System.out.println("Not Properties")' not executed.
CDI beans are lazy-produced, that is the producer methods are only executed if
instances o
Hi Leon,
In order to get the NettySharedHttpServer service exposed as a named bean in
your Java DSL bundle, you could do:
@ContextName("sample")
public class SampleRoute extends RouteBuilder {
@Inject
@OsgiService
private NettySharedHttpServer server;
@Produces
@Named("sharedNettyH
Hi Nicolas,
> On 11 May 2016, at 17:02, nicolasduminil
> wrote:
>
> Hi Antonin,
>
> I have investigated the direction you've suggested and I think that the (1)
> is fine. Then I found a lot of example like this:
>
>CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
>cdi
Hi Nicolas,
In your unit tests, you should use Camel CDI test runner instead of extending
CamelTestSupport. This is used in the example that illustrates CDI and
DeltaSpike configuration properties so that you can have a look at the
accompanying test class. See [2] for more information.
[1]:
h
Hi Nicolas,
Have you tried with a non-static member:
@Inject
@ConfigProperty(name = "ftp.path")
private String myProp;
Injection of static field is not allowed.
It should work without duplicating your logic.
Antonin
> On 31 May 2016, at 14:37, nicolasduminil
> wrote:
>
> @Inject
> @Config
Hi Anton,
The Camel context beans managed by Camel CDI are automatically instantiated and
started when the container is bootstrapped. Hence all the routes bound to them
are started by default as well. And that’s the behaviour you get with the Camel
CDI test runner as well.
If your need is to h
It may be due to the use of DeltaSpike’s BeanManagerProvider in the Camel CDI
extension which can cause such an issue. It’s been fixed in Camel version
2.17.0. Would that be possible for you to upgrade your Camel dependencies and
check if that fixes your issue?
> On 14 Jun 2016, at 22:51, saysv
> On 15 Jun 2016, at 17:19, saysvishal wrote:
>
> Thanks astefanutti, appreciate you help!
>
> We are not using BeanManagerProvider but
> javax.enterprise.inject.spi.BeanManager.
Sorry I haven’t been clear. I meant that Camel CDI, prior to Camel 2.17.0,
relies on DeltaSpike’s BeanManagerProvi
Hi Dimitri,
Camel JMS depends on Spring transaction. So as you want to coordinate your JMS
broker and your DB within the same XA transaction, you have to rely on the
Spring platform transaction manager. As you already figured out, you can
produce it as a CDI producer method:
@Produces
@Named("
Note that Camel CDI does not change the semantic of
context.setAutoStartup(false), that is the routes within the context are not
started, though the context itself is started so that validation can occur when
the application initialise.
> On 05 Aug 2016, at 20:08, Romain Manni-Bucau wrote:
>
Hi Brad,
The examples (camel-example-cdi.*) that are available in
https://github.com/apache/camel/tree/master/examples should work to some great
extent in Camel versions prior to 2.17.0.
As these examples concentrate on the non-advanced features and the new version
of Camel CDI introduced in 2
camel - can be done automatically and switch
> back to either cdi or something else if in standalone.
>>
>> Le 5 août 2016 21:58, "Shultz, Dmitry" a
> écrit :
>>
>> It looks like
> org.apache.camel.cdi.CdiCamelExtension.afterDeploymentValidation(
Hi,
Camel CDI is capable of managing multiple Camel contexts within the same JVM /
same CDI container. You can find more information in
http://camel.apache.org/cdi.html#CDI-MultipleCamelcontexts. It documents how to
declare these contexts and how to bind RouteBuilder to them. Generally, you
wo
and, in a way, it is more portable.
>
> But the ease of wiring that CDI provides is compelling and I'm very excited
> about that future.
>
> On Mon, Aug 8, 2016 at 4:21 AM, Antonin Stefanutti
> wrote:
>
>> Hi Brad,
>>
>> The examples (camel-example-cdi.*
One alternative is to observe for the CamelContextStartingEvent that’s fired
before the corresponding Camel contexts get started, e.g.:
void initMyBeansBeforeContextStart(@Observes CamelContextStartingEvent event,
MyBean bean) {
bean.init();
}
Either method argument or class field injection
Wed, Aug 10, 2016 at 2:33 PM, Antonin Stefanutti
> wrote:
>
>> One alternative is to observe for the CamelContextStartingEvent that’s
>> fired before the corresponding Camel contexts get started, e.g.:
>>
>> void initMyBeansBeforeContextStart(@Observes CamelCon
n Wed, Aug 10, 2016 at 9:13 AM, Rajith Muditha Attapattu <
>> rajit...@gmail.com> wrote:
>>
>>> Thanks guys for the information.
>>> I'm using 2.15 ...as thats the version bundled with the Fuse 6.2.1
>> release.
>>>
>>> On Tue, Aug 9, 20
Hi Brad,
I’ve been working on Camel CDI in OSGi for a while and have ported my original
samples to be tested in Karaf, which can be found in [1]. These samples
exercise the portability of Camel CDI examples on OSGi, thus do not leverage
the SCR equivalent annotations that PAX CDI provides. So t
Hi Brad,
> On 21 Aug 2016, at 07:07, Brad Johnson wrote:
>
> When I look at the example provided I'm not entirely sure if I'm
> understanding how the CDI OSGi service mechanics work.
>
>@Produces
>@Named("sjms")
>@ApplicationScoped
> SjmsComponent sjms()
>
> I gather because it is
Hi Brad,
Camel CDI only works at the level of CDI beans, that is it won’t manage
RouteBuilder instances that are declared as SCR component.
Then you can imagine having Camel CDI and SCR components collaborating through
the OSGi registry, using PAX CDI in the mix.
That being said, Camel CDI / S
ded
>
>
> When I look at straight DS it gets even more of head scratcher with the
> OSGi alliance seeming to push the Bnd Tools.
>
> I had noticed Guillaume's pax.cdi as well but wasn't really sure how that
> was going to fit in. Is that something would be added a
Hi Brad,
Thanks for the feedback.
I’m not sure I understand the issue that you face.
For example, when mvn test is executed in the example module
camel-example-cdi-test [1], test classes annotated with
@RunWith(CamelCdiRunner.class) get executed.
Is my understanding correct?
[1]: https://git
Hi,
What version of Weld are you using? Until recently nested / fat JAR wasn’t
working with Weld until it’s been fixed in Weld 2.3.4 with WELD-1930 [1]. I
haven’t tried it myself so that should enable fat JAR support, produced for
example with onejar-maven-plugin. An alternative may be to use s
Hi Dennis,
> On 13 Oct 2016, at 14:22, Dennis Bohnstedt Hansen wrote:
>
> Hi
>
> I'm having soms problems with camel-test-cdi in 2.17 (tested in 2.17.0,
> 2.17.1 and 2.17.2).
>
> I have two projects containing similar routes and test cases, but the
> behaviour is very different, and i'm unsure
Hi Oli,
CamelCdiRunner bootstraps a Weld SE container so that you can easily test your
Camel CDI code with a bare minimal CDI container. If you want to test your
Camel CDI code with WildFly Swarm, you may need to rely on Arquillian or what
WildFly Swarm provides as testing framework. You may fi
Hi Oli,
Indeed, your test class should work. However, it seems the WildFly Swarm plugin
generates some other classes, like org.wildfly.swarm.cdi.StageConfigBean, that
are deployed as bean classes and that seems to require some execution context.
The CamelCdiRunner starts a Weld SE container wit
I would expect your testing logic to work fine in an Arquillian test. What
error do you face?
> On 04 Nov 2016, at 09:37, Oli wrote:
>
> I see... I've tried the approach recommended by wildfly swarm, but it didn't
> work for me either. The examples are very basic and don't involve any
> injecti
It is likely related to https://issues.apache.org/jira/browse/CAMEL-10562.
Antonin
> On 30 Nov 2016, at 15:07, Claus Ibsen wrote:
>
> Hi
>
> Make sure you use Java 8 and that you do not have mixed versions of
> Camel on the classpath.
>
> On Wed, Nov 30, 2016 at 2:58 PM, imben1109 wrote:
>>
It looks like an exception is thrown by Weld during the execution of the
extractor. As this is a Weld internal, I would suggest you contact the Weld
user list, they may help you troubleshooting and identify the root cause.
Antonin
> On 7 Dec 2016, at 15:46, kalber wrote:
>
> I set up a route
Hi,
I think this is already possible. We may dig into why this is not working for
you, though you can find a working example here:
The data source configuration:
https://github.com/fabric8-quickstarts/spring-boot-camel-rest-sql/blob/3fdcb17ce52d3f42f63dc38e6d73cf97deafefb2/src/main/resources/ap
Hi Tim,
DeltaSpike is only used by this Main class to bootstrap Camel CDI in Java SE.
So the dependency is optional to avoid polluting the classpath for other target
runtimes.
In the Camel examples, we add it to the Camel Maven plugin dependency, see:
https://github.com/apache/camel/blob/6e95a
Hi Bernard,
One straightforward solution would be to implement a small CDI extension
deployed within your WAR that would do the white (or black) listing of the
RouteBuilder, depending on whatever condition (a properties file), e.g.:
public class CustomerRoutesExtension implements Extension {
Hi Bernard,
Specifying the context attribute for @PropertyInject is currently necessary
when dealing with multiple Camel contexts so that the bean post processing can
resolve the Camel context to use. If it is not specified, then the default
(following CDI semantic, that is with the @Default qu
Thanks for the detailed report. That makes sense to contextualize the default
context based on @ContextName.
Antonin
> On 30 Mar 2017, at 18:27, Bernard Ligny wrote:
>
> Improvement issue created:
> https://issues.apache.org/jira/browse/CAMEL-11097
>
>
>
> --
> View this message in context:
Hi,
> On 12 Apr 2017, at 18:28, Bernard Ligny wrote:
>
> I am currently refactoring a monolithic webapp using a more
> modular/micro-services approach.
> I'm busy with splitting the numerous existing Camel RouteBuilders into
> separate module.
>
> The target situation is explained here:
>
>
>
Hi Bernard,
> On 14 Apr 2017, at 09:33, Bernard Ligny wrote:
>
> Hi Antonin
>
>
> astefanutti wrote
>> as long as they have a beans.xml file in module
>>
>> .jar/META-INF directory. Is this the case?
>
> No it was not the case - shame on me !
> I naively thought that putting a *single* "bea
Hi Drazen,
It looks like the org.apache.deltaspike.data.impl.handler.QueryHandler class is
not visible from the Camel module you’ve deployed. So it’s rather an issue of
using Deltaspike data module within the WildFly module system. So you may need
to add the deltaspike-data-module JARs to your
>
>
> Best regards
>
> Drazen Kozic
>
>
> On Fri, May 5, 2017 at 10:34 AM, Antonin Stefanutti
> wrote:
>> Hi Drazen,
>>
>> It looks like the org.apache.deltaspike.data.impl.handler.QueryHandler class
>> is not visible from the Camel modul
Hi Aaron,
Great. I’ll test your patch and comment on the JIRA ticket then.
Antonin
> On 08 Oct 2015, at 07:13, Aaron Birkland wrote:
>
> I've opened up an issue and attached a pach to it:
> https://issues.apache.org/jira/browse/CAMEL-9200
>
> I'm not entirely familiar with the Camel code, but
You can do:
from("...").setHeader("CamelFileName",
simple("${bean:java.lang.System?method=currentTimeMillis}”)).to(“hdfs://...”);
See: http://camel.apache.org/hdfs#HDFS-Produceronly
Antonin
> On 08 Oct 2015, at 15:08, ram kumar wrote:
>
> thanks, i am new to camel. can you point me how to gi
Hi Claudius,
Using the ProducerTemplate.sendBody [1] method to send a message to the direct
endpoint actually creates a UnitOfWorkProducer instance that blocks the caller
thread until the unit of work has completed [2]. So even if your route contains
some asynchronous processing through the thr
Hi Ryan,
The following Camel DSL:
to("bean:beanClass?method=methodToCall(${body})")
or
bean(BeanClass.class, "methodToCall(${body})")
Does not convert the body to String when the type of body corresponds to that
of the first method parameter.
Is there any step upfront in your route that may
Bean visibility in EAR is a difficult topic as this depends on EAR classloader
hierarchy which is not standardised. This is well explained in
https://struberg.wordpress.com/2015/02/18/cdi-in-ears/.
DeltaSpike BeanProvider API tries to work-around this by dealing with the
classloaders used at bo
Expressions are not evaluated where you’ve used them:
> to("quartz://timerName" + "${in.header.cid}" + "?${in.header.cornExpression}")
> .routeId("Cron Scheduler Route "+"${in.header.cid}")
As documented in http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html
Since Camel 2.16, you can u
The component would generally do the logging for you while trying to recover
from the error.
As for the JMS component specifically, it exposes a couple of options to
configure error handling that you can use, namely:
exceptionListener, errorHandler, errorHandlerLoggingLevel,
errorHandlerLogSta
You could use BatchMessageListenerContainer [1] instead of
DefaultMessageListenerContainer.
An option to provide a specific MessageListenerContainer is to used the
'consumerType' parameter from the JMS component and set it to 'Custom' and
provide the option 'messageListenerContainerFactoryRef'
I don't know of any public / shareable example of setting a custom
MessageListenerContainer unfortunately.
That being said, from the Camel route standpoint, you should write something
like:
from://jms?consumerType=Custom&messageListenerContainerFactoryRef=…
This is documented in http://camel.a
It should be in spring-batch-integration.
> On 18 Nov 2015, at 18:52, deepak_a wrote:
>
> Hi,
>
> I have made a thorough search but unable to find
> docs.spring.io/spring-batch/apidocs/org/springframework/batch/container/jms/BatchMessageListenerContainer.html
>
> in the spring-batch/spring-ba
You need the following piece of code to be executed so that your Camel contexts
get published as OSGi services:
context.getManagementStrategy().addEventNotifier(new
OsgiCamelContextPublisher(BundleContextUtils.getBundleContext(getClass(;
Then your Camel contexts will be visible from Camel K
Hi Tim,
We are actively working on improving the Camel CDI integration for the upcoming
2.17.0 release. This is followed-up in
https://issues.apache.org/jira/browse/CAMEL-9201.
That will be essentially the merging of the work being done in
https://github.com/astefanutti/camel-cdi.
This will b
Hi Yogesh,
As JMS 2 API is backward compatible I think that make sense.
Antonin
> On 12 Jan 2016, at 09:28, yogu13 wrote:
>
> Hello,
>
> I looked into the manifest of the camel-sjms component and found that for
> now it is based on jms 1.1. Considering nothing much has changed in JMS 2,
> can
Hi Tim,
You’ll find an example of using REST DSL with the Servlet component and CDI
here:
https://github.com/apache/camel/tree/674b8cd2eb1f2c937121a62fc0ce8cb0df9a4c9f/examples/camel-example-cdi-rest-servlet
That uses the work done at https://github.com/astefanutti/camel-cdi that has
recently
You cannot produce to a direct endpoint that has no consumer:
No consumers available on endpoint: Endpoint[direct://serviceClass]
> On 18 Feb 2016, at 17:47, hoboy wrote:
>
> My goodness this forum is really tough on camel new bee.
> No answer to any question at all.
>
>
>
>
> --
> View thi
> On 19 Feb 2016, at 19:37, Agusti Tomas wrote:
>
> I am new to Camel and relatively new to mailing lists so apologies in
> advance if I don't stick to the rules. Constructive feedback is always
> welcome and I'm a fast learner!
We’re here to help :)
> So I am moving from JBoss EAP 6.1 to 6.4
Hi John,
Good to hear from you here! Thanks for the thorough testing, that’s a good
catch.
So I’ve looked into it and apparently the problem is two folds:
- The implementations do not assume the @Any qualifier by default for
programmatic lookup as they do for static injection.
- OpenWebBeans do
i Antonin!
>
> For #2, that's weird. What do you see in the output?
>
> John
> On Feb 22, 2016 11:24, "Antonin Stefanutti" wrote:
>
>> Hi John,
>>
>> Good to hear from you here! Thanks for the thorough testing, that’s a good
>> catch.
>
n 22 Feb 2016, at 17:44, Antonin Stefanutti wrote:
>
> It returns the qualifiers for the Instance injection point declaration, not
> the ones added with select programmatically! I’ve tested it with OWB version
> 1.6.2.
>
> Weld returns the complete set of qualifiers as oppos
L-9630
> I'll move that over to you.
>
> Thanks!
>
> John
>
> On Tue, Feb 23, 2016 at 9:00 AM Antonin Stefanutti
> wrote:
>
>> Hi John,
>>
>> For #1, I’ve just pushed [1] to improve the support for programmatic
>> lookup of Camel res
Hi Raphaël,
CDI requires a default constructor so that it can creates proxies for beans. So
the obvious solution may be to add a default constructor to the
ScalaRouteBuilder class, as the RouteBuilder class does.
For your information, the Camel CDI component has been rewritten for the
upcoming
Hi Charlee,
There is actually no constraint on the scope to declare for the RouteBuilder
beans that are discovered by Camel CDI.
Camel CDI just gets one instance for each of them at start time and adds this
to the Camel context. So that will equally work whether a RouteBuilder is
@Dependent or
.
>>>
>>> Please correct me if I'm wrong. Since it is a @Dependent, I can register
>>> the new instance (with different route-id and parameters) to the context
>> as
>>> much as possible. Cloud you please help to advise further?
>>>
Hi Murt,
> On 30 Mar 2016, at 17:00, murt_ryan wrote:
>
> Hi,
> Apologies if my question is not clear but here goes:
Your question is very clear ;)
> I am currently experiencing problems with camel-cdi injection after moving
> from Camel 2.16 to 2.17. I realise alot of work has gone on in thi
Hi Tim,
> On 06 Apr 2016, at 16:19, Tim Dudgeon wrote:
>
> I've found a couple of things I don't understand when using the camel-cdi
> component.
>
> 1. The @ContextName("customname") annotation can be used to specify a custom
> name for the camel context. But I'm finding that this annotation
t; the HelloRoute class.
> To reproduce the second one uncomment line 25 from the same class.
>
> Tim
>
>
> On 06/04/2016 16:09, Antonin Stefanutti wrote:
>> Hi Tim,
>>
>>> On 06 Apr 2016, at 16:19, Tim Dudgeon wrote:
>>>
>>> I
1 - 100 of 106 matches
Mail list logo
