Re: Camel-K Operator: can I add additional labels to the image build?

[Antonin Stefanutti]

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, Christoph Weiss  wrote:
> 
> Dear User Group,
> 
> Short question:
> 
> We have the requirement to add additional labels to the image that is build 
> by the Camel-K Operator  (via the IntegrationKit and Build CR).
> Is this possible?
> If yes: how could this be achieved?
> 
> Any hints are more than welcome.
> 
> Thanks Christoph

Re: Webhook for listening Integration CRD changes

[Antonin Stefanutti]

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...@gmail.com>> wrote:

There is a way to create a webhook to listen for Integration CRD changes?

I was looking this
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

But I do know if this is possible I want to be notified when an
Integration phase changes to "Running" or "Error" without implementing
a "pulling strategy" (loop getting the integration).

Re: Isolate integrations network

[Antonin Stefanutti]

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 by using the affinity trait.

On 16 Mar 2022, at 09:46, Claus Ibsen 
mailto:claus.ib...@gmail.com>> wrote:

Hi

That is a kubernetes question, and not as much of a Camel question.
You can run them in different namespaces to have isolation.


On Tue, Mar 15, 2022 at 2:13 PM Roberto Camelk
mailto:betonetotbo.cam...@gmail.com>> wrote:

How can I isolate integrations network, for example, to prevent an
integration A to request a rest route in the integration B ?



--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Camel-K integration hot deploy and down time

[Antonin Stefanutti]

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 Camelk  wrote:
> 
> When an integration is running in my k8s cluster via Camel-K operator,
> what happens if I re-run it and it will rebuild?
> 
> There will be downtime? This downtime will be from the beginning of
> the build phase, or just when it switches the POD to the new image?

Re: Using AWS ECR with Camel-K, is it possible?

[Antonin Stefanutti]

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>> wrote:

Is it possible to use AWS ECR with Camel-K to push the images ?

Re: Kamel CLI exit code

[Antonin Stefanutti]

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, Roberto Camelk 
mailto:betonetotbo.cam...@gmail.com>> wrote:

I'm using kamel CLI to launch my integrations programmatically.

I was testing the kamel exit code, assuming that 0 (zero) is "everything ok".

But recently I have launched an integration containing a invalid Modeline:
//camel-k: trait=prometeus.enabled=true

The correct is ("h" was missing):
//camel-k: trait=prometheus.enabled=true

But the kamel exited with code "0", and the integration was not launched.

So, this behavior is a BUG or is it expected?

How can I guarantee that my integration was launched?

Re: Operating Camel-K by rest instead of via CLI kamel

[Antonin Stefanutti]

> On 14 Dec 2021, at 20:29, Roberto Camelk  wrote:
> 
> Sorry, maybe I wasn't clear enough in my question, or I simple didn't
> understud your answer.

No problem, that's me that did not understand your use case :)

> What I'm thinking about is how can I create a web-ui to launch my
> integrations by just submitting a source file of it?
> 
> I want to publish a backend to be able to send requests containing the
> integration source, and this backend orchestrates the "kamel run" for
> me. So as to orchestrate the "kamel get" and "kamel delete" for
> example...
> 
> I was thinking if it is possible that the Camel-K has an REST API to
> do that for me, or if I need to create this.

It's possible to create Integration resources directly, using the Kubernetes 
API, as any other Kubernetes 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 Antonin Stefanutti
>  wrote:
>> 
>> 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...@gmail.com>> wrote:
>> 
>> Can I operate the Camel-K Operator via http instead of via kamel CLI ?
>> 

Re: Operating Camel-K by rest instead of via CLI kamel

[Antonin Stefanutti]

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...@gmail.com>> wrote:

Can I operate the Camel-K Operator via http instead of via kamel CLI ?

Re: Camel-K build process getting killed

[Antonin Stefanutti]

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 camel-k build is killed printing this log:
> 
> {"level":"error","ts":1639135593.228176,"logger":"camel-k.controller.build","msg":"Build
> kit-c6pjgfbh6q8s73fjjqs0 failed: failure while building project:
> signal: 
> killed","request-namespace":"default","request-name":"kit-c6pjgfbh6q8s73fjjqs0","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-c6pjgfbh6q8s73fjjqs0"}

Re: Camel-k operator fails on building

[Antonin Stefanutti]

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 minikube. This is my scripts:
> 
> read -p 'Dockerhub organization: ' dockerorganization
> read -p 'Dockerhub user name: ' dockeruser
> read -sp 'Dockerhub user password: ' dockerpassword
> 
> kubectl \
>  -n camel \
>  create secret docker-registry camel-k-registry-secret \
>  --docker-username $dockeruser \
>  --docker-password "$dockerpassword"
> 
> kamel install \
>  --force \
>  --build-publish-strategy=Spectrum \
>  --olm=false \
>  -n default \
>  --operator-resources requests.cpu=100m \
>  --operator-resources limits.cpu=200m \
>  --operator-resources requests.memory=256Mi \
>  --operator-resources limits.memory=1024Mi \
>  --registry docker.io \
>  --organization $dockerorganization \
>  --registry-secret camel-k-registry-secret \
>  --wait
> 
> Bu when I try to run my integration, the build fails with:
> 
> {"level":"info","ts":1639077040.119277,"logger":"camel-k.builder","msg":"base
> image: adoptopenjdk/openjdk11:slim"}
> {"level":"info","ts":1639077040.1192799,"logger":"camel-k.builder","msg":"resolved
> base image: adoptopenjdk/openjdk11:slim"}
> {"level":"error","ts":1639077040.1429865,"logger":"camel-k.controller.build","msg":"Build
> kit-c6p503epuevc73829220 failed: secrets \"camel-k-registry-secret\"
> not 
> found","request-namespace":"default","request-name":"kit-c6p503epuevc73829220","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-c6p503epuevc73829220"}
> {"level":"info","ts":1639077040.2197232,"logger":"camel-k.controller.build","msg":"state
> transition","request-namespace":"default","request-name":"kit-c6p503epuevc73829220","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-c6p503epuevc73829220","phase-from":"Running","phase-to":"Failed"}
> {"level":"info","ts":1639077040.2216291,"logger":"camel-k.controller.build","msg":"Reconciling
> Build","request-namespace":"default","request-name":"kit-c6p503epuevc73829220"}
> {"level":"info","ts":1639077040.2217255,"logger":"camel-k.controller.build","msg":"Invoking
> action 
> error-recovery","request-namespace":"default","request-name":"kit-c6p503epuevc73829220","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-c6p503epuevc73829220"}
> {"level":"info","ts":1639077040.2217386,"logger":"camel-k.controller.build","msg":"Recovery
> attempt 
> (5/5)","request-namespace":"default","request-name":"kit-c6p503epuevc73829220","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-c6p503epuevc73829220"}

Re: Multiple CamelContexts using Camel-K

[Antonin Stefanutti]

I don't think there is a single "correct" model, as it depends on the 
definition and use cases / requirements. A working group has been created to 
address the multi-tenancy space:

https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/

https://github.com/kubernetes-sigs/multi-tenancy

It appears one model is the "Namespaces as a Service", where namespaces are 
used as the tenant unit. This model emerges from the mechanisms already in 
place to isolate tenants, like RBAC, NetworkPolicies, Quotas, whose definitions 
are tightly bound to that of namespaces:

https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/#namespaces-as-a-service

On 8 Dec 2021, at 12:25, Roberto Camelk 
mailto:betonetotbo.cam...@gmail.com>> wrote:

Antonin, is it correct assuming that the correct mode to deal with
multi-tenancy in k8s is by 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 integration on another namespace, how can I do this
using the CLI ?

My camel-k operator is running at the default namespace. I have second
namespace named "poc", 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
mailto:anto...@stefanutti.fr.invalid>> wrote:

One possible multi-tenancy setup with Camel K is:

- A single Camel K operator instance, managing the entire cluster
- One namespace per tenant / user, that can contain one or more integration 
(think one integration = one Camel context)

If you really want strict multi-tenancy, it's also possible to have an operator 
instance per tenant (= namespace), but that comes with extra overheads, 
resources wise and operationally wise.

On 7 Dec 2021, at 15:39, Roberto Camelk 
mailto:betonetotbo.cam...@gmail.com>> wrote:

Thanks, Antonin.

So, granularizing by tenancy by Camel Context is not the correct
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
mailto:anto...@stefanutti.fr.invalid>> wrote:

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, the metrics exposed are tagged with the context info.

On 7 Dec 2021, at 15:15, Roberto Camelk 
mailto:betonetotbo.cam...@gmail.com>> wrote:

We are thinking about organizing our infra loading one CamelContext
per tenant in our cloud.

So the idea is one CamelContext per tenant, so each tenant has its own
environment and it can not be impacted by other tenant environments
(contexts).

This makes sence? What are the issues about this abordation? This can
help or complicate the monitoring of this environments?

Is it possible to have multiple CamelContexts using 1 Camel-K operator?

Re: Multiple CamelContexts using Camel-K

[Antonin Stefanutti]

> On 7 Dec 2021, at 18:31, Roberto Camelk  wrote:
> 
> Thanks again!
> 
> But, to run a new integration on another namespace, how can I do this
> using the CLI ?
> 
> My camel-k operator is running at the default namespace. I have second
> namespace named "poc", 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 Camel K is:
>> 
>> - A single Camel K operator instance, managing the entire cluster
>> - One namespace per tenant / user, that can contain one or more integration 
>> (think one integration = one Camel context)
>> 
>> If you really want strict multi-tenancy, it's also possible to have an 
>> operator instance per tenant (= namespace), but that comes with extra 
>> overheads, resources wise and operationally wise.
>> 
>>> On 7 Dec 2021, at 15:39, Roberto Camelk  
>>> wrote:
>>> 
>>> Thanks, Antonin.
>>> 
>>> So, granularizing by tenancy by Camel Context is not the correct
>>> 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 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, the metrics exposed are tagged with the context info.
>>>> 
>>>>> On 7 Dec 2021, at 15:15, Roberto Camelk  
>>>>> wrote:
>>>>> 
>>>>> We are thinking about organizing our infra loading one CamelContext
>>>>> per tenant in our cloud.
>>>>> 
>>>>> So the idea is one CamelContext per tenant, so each tenant has its own
>>>>> environment and it can not be impacted by other tenant environments
>>>>> (contexts).
>>>>> 
>>>>> This makes sence? What are the issues about this abordation? This can
>>>>> help or complicate the monitoring of this environments?
>>>>> 
>>>>> Is it possible to have multiple CamelContexts using 1 Camel-K operator?
>>>> 
>> 

Re: Multiple CamelContexts using Camel-K

[Antonin Stefanutti]

One possible multi-tenancy setup with Camel K is:

- A single Camel K operator instance, managing the entire cluster
- One namespace per tenant / user, that can contain one or more integration 
(think one integration = one Camel context)

If you really want strict multi-tenancy, it's also possible to have an operator 
instance per tenant (= namespace), but that comes with extra overheads, 
resources wise and operationally wise. 

> On 7 Dec 2021, at 15:39, Roberto Camelk  wrote:
> 
> Thanks, Antonin.
> 
> So, granularizing by tenancy by Camel Context is not the correct
> 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 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, the metrics exposed are tagged with the context info.
>> 
>>> On 7 Dec 2021, at 15:15, Roberto Camelk  
>>> wrote:
>>> 
>>> We are thinking about organizing our infra loading one CamelContext
>>> per tenant in our cloud.
>>> 
>>> So the idea is one CamelContext per tenant, so each tenant has its own
>>> environment and it can not be impacted by other tenant environments
>>> (contexts).
>>> 
>>> This makes sence? What are the issues about this abordation? This can
>>> help or complicate the monitoring of this environments?
>>> 
>>> Is it possible to have multiple CamelContexts using 1 Camel-K operator?
>> 

Re: Multiple CamelContexts using Camel-K

[Antonin Stefanutti]

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, the metrics exposed are tagged with the context info.

> On 7 Dec 2021, at 15:15, Roberto Camelk  wrote:
> 
> We are thinking about organizing our infra loading one CamelContext
> per tenant in our cloud.
> 
> So the idea is one CamelContext per tenant, so each tenant has its own
> environment and it can not be impacted by other tenant environments
> (contexts).
> 
> This makes sence? What are the issues about this abordation? This can
> help or complicate the monitoring of this environments?
> 
> Is it possible to have multiple CamelContexts using 1 Camel-K operator?

Re: Question about camel metrics IDs

[Antonin Stefanutti]

> On 1 Dec 2021, at 18:58, Roberto Camelk  wrote:
> 
> OK, thanks.
> 
> But, can I setup the JMX exported in a Camel-K integration?

It's a bit tricky but not impossible. You would need to replicate what we did 
before we moved to Quarkus as the runtime, that is:

Add the dependencies on camel-management and jmx_prometheus_javaagent:

https://github.com/apache/camel-k/blob/75cdfa0c4d71fe3022fdaff7d39585875509beb7/pkg/trait/prometheus.go#L93-L96

Mount the ConfigMap containing the Prometheus JMX exporter configuration:

https://github.com/apache/camel-k/blob/75cdfa0c4d71fe3022fdaff7d39585875509beb7/pkg/trait/prometheus.go#L99-L108

And finally add the Prometheus JMX exporter agent:

https://github.com/apache/camel-k/blob/75cdfa0c4d71fe3022fdaff7d39585875509beb7/pkg/trait/prometheus.go#L138

The later can possibly be done by using the options parameter of the jvm trait.

> 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 definitions
>> and I need to find the correlated metrics in camel-k.
>> 
>> Here are the scrape patterns:
>> https://github.com/alainpham/app-archetypes/blob/1f559e84753525b087a503ecb2d97c26e108dee7/spring-boot-camel/src/main/resources/archetype-resources/src/main/fabric8-includes/prometheus-config.yml
>> 
>> They have some expressions like:
>> - pattern: 'org.apache.camel> name=([^,]+)><>ExchangesCompleted'
>> 
>> I think this one is about the
>> "camel.context.exchanges.completed.total" listed here
>> https://camel.apache.org/camel-quarkus/2.5.x/reference/extensions/microprofile-metrics.html#_camel_route_metrics.
>> 
>> That file is used for the Prometheus JMX exporter and does not apply to the 
>> Camel Quarkus MicroProfile Metrics extension.
>> 
>> Can someone help me with this? How can I correlate this
>> "org.apache.camel..." to this default exposed metrics ids in
>> camel-quarkus-microprofile-metrics ?
>> 
>> The list of metrics registered is defined by the Camel Quarkus MicroProfile 
>> Metrics extension, and is documented here:
>> 
>> https://camel.apache.org/camel-quarkus/2.5.x/reference/extensions/microprofile-metrics.html
>> 
>> Then the names are mapped according to the MP Metrics specification:
>> 
>> https://download.eclipse.org/microprofile/microprofile-metrics-4.0/microprofile-metrics-spec-4.0.html
>> 
>> That is, a the "application" prefix, and the snake cased metric name.
>> 

Re: Question about camel metrics IDs

[Antonin Stefanutti]

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/1f559e84753525b087a503ecb2d97c26e108dee7/spring-boot-camel/src/main/resources/archetype-resources/src/main/fabric8-includes/prometheus-config.yml

They have some expressions like:
- pattern: 'org.apache.camel<>ExchangesCompleted'

I think this one is about the
"camel.context.exchanges.completed.total" listed here
https://camel.apache.org/camel-quarkus/2.5.x/reference/extensions/microprofile-metrics.html#_camel_route_metrics.

That file is used for the Prometheus JMX exporter and does not apply to the 
Camel Quarkus MicroProfile Metrics extension.

Can someone help me with this? How can I correlate this
"org.apache.camel..." to this default exposed metrics ids in
camel-quarkus-microprofile-metrics ?

The list of metrics registered is defined by the Camel Quarkus MicroProfile 
Metrics extension, and is documented here:

https://camel.apache.org/camel-quarkus/2.5.x/reference/extensions/microprofile-metrics.html

Then the names are mapped according to the MP Metrics specification:

https://download.eclipse.org/microprofile/microprofile-metrics-4.0/microprofile-metrics-spec-4.0.html

That is, a the "application" prefix, and the snake cased metric name.

Re: Why my prometheus operator not discovering new camel-k pods

[Antonin Stefanutti]

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 to the Prometheus operator, so you'll have 
better answer if you ask the Prometheus operator team directly.

On 30 Nov 2021, at 14:34, Roberto Camelk 
mailto:betonetotbo.cam...@gmail.com>> wrote:

I created a simples integration and enabled the prometheus
integration, as explained here:
https://camel.apache.org/camel-k/1.4.x/observability/integration.html#_discovery

Before that, I also configured my Prometheus operator resource, as
explained here:
https://camel.apache.org/camel-k/1.7.x/observability/monitoring.html#kubernetes

The problem is...

When I start my integration (platform/micro-profile-metrics2), and
RESTART my prometheus operator it discovers my integration PodMonitor,
and regenerate the prometheus config and sync it. This the the
prometheus operator log:

level=debug ts=2021-11-30T13:11:50.399141448Z caller=operator.go:1853
component=prometheusoperator msg="selected PodMonitors"
podmonitors=platform/micro-profile-metrics2,platform/create-role-route
namespace=cattle-prometheus prometheus=cluster-monitoring
level=debug ts=2021-11-30T13:11:50.42285181Z caller=operator.go:1677
component=prometheusoperator msg="updating Prometheus configuration
secret skipped, no configuration change"

But, when I don't restart the prometheus operator and run a new
integration in camel-k, the only thing in prometheus operator log is:

level=debug ts=2021-11-30T13:16:08.094103259Z caller=operator.go:748
component=prometheusoperator msg="PodMonitor updated"

And even after a while, the prometheus operator never fire the
prometheus config regeneration, and the prometheus never start to
scrape the metrics of this new pod. Only if I restart the prometheus
operator it starts to scrape the pod.

Re: Apache Camel-k metrics in rancher embedded prometheus

[Antonin Stefanutti]

s:
>prometheus_from: arquitetura
>  listenLocal: true
>  logFormat: logfmt
>  logLevel: info
>  nodeSelector:
>kubernetes.io/os: linux
>  podMetadata:
>labels:
>labels:
>  app: prometheus
>  chart: prometheus-0.0.1
>  release: cluster-monitoring
>  podMonitorNamespaceSelector: {}
>  podMonitorSelector:
>matchLabels:
>  app: camel-k
>  replicas: 1
>  resources:
>limits:
>  cpu: "1"
>  memory: 1000Mi
>requests:
>  cpu: 750m
>  memory: 750Mi
>  retention: 12h
>  ruleNamespaceSelector:
>matchExpressions:
>- key: field.cattle.io/projectId
>  operator: In
>  values:
>  - p-gzj4v
>- key: field.cattle.io/projectId
>  operator: In
>  values:
>  - p-gzj4v
>  ruleSelector:
>matchExpressions:
>- key: source
>  operator: In
>  values:
>  - rancher-alert
>  - rancher-monitoring
>  rules:
>alert: {}
>  scrapeInterval: 60s
>  secrets:
>  - exporter-etcd-cert
> securityContext:
>fsGroup: 2000
>runAsNonRoot: true
>runAsUser: 1000
>  serviceAccountName: cluster-monitoring
>  serviceMonitorNamespaceSelector:
>matchExpressions:
>- key: field.cattle.io/projectId
>  operator: In
>  values:
>  - p-gzj4v
>- key: field.cattle.io/projectId
>  operator: In
>  values:
>  - p-gzj4v
>  serviceMonitorSelector: {}
>  tolerations:
>  - effect: NoSchedule
>key: cattle.io/os
>   operator: Equal
>value: linux
>  version: v2.17.2
>  volumes:
>  - emptyDir: {}
>name: nginx-home
> 
> On Fri, Nov 26, 2021 at 11:41 AM Roberto Camelk
>  wrote:
>> 
>> Thanks again Antonin.
>> 
>> You save my black-friday!
>> 
>> On Fri, Nov 26, 2021 at 11:02 AM Antonin Stefanutti
>>  wrote:
>>> 
>>> Great!
>>> 
>>> For the metrics, there should be the following registered by the 
>>> MicroProfile Metrics Camel extension:
>>> 
>>> https://camel.apache.org/camel-quarkus/2.4.x/reference/extensions/microprofile-metrics.html#_usage
>>> 
>>> However, the final name is determined by the MicroProfile Metrics 
>>> specification, so for example the following metric:
>>> 
>>> camel.context.exchanges.completed.total
>>> 
>>> Have its name translated to:
>>> 
>>> application_camel_context_exchanges_completed_total
>>> 
>>> To check also if the metrics endpoint do have the metrics registered, you 
>>> can run:
>>> 
>>> $ kubectl exec deployment/ -- curl -s 
>>> http://localhost:8080/q/metrics | grep 
>>> application_camel_route_exchanges_completed_total
>>> 
>>> # HELP application_camel_route_exchanges_completed_total The total number 
>>> of completed exchanges for a route or Camel Context
>>> # TYPE application_camel_route_exchanges_completed_total counter
>>> application_camel_route_exchanges_completed_total{camelContext="camel-1",routeId="route1"}
>>>  33.0
>>> 
>>>> On 26 Nov 2021, at 14:34, Roberto Camelk  
>>>> wrote:
>>>> 
>>>> Thanks a lot again Antonin. I owe you a beer or coffee!!!
>>>> 
>>>> This worked 100%.
>>>> 
>>>> To end, another question after this, prometheus start scraping the
>>>> metrics from my running route pod, but...
>>>> 
>>>> Some metrics IDs are not there, some metrics starting with
>>>> "org_apache_camel_" as I have see in this grafana dashboard sample:
>>>> https://github.com/weimeilin79/camel-k-example-prometheus/blob/ca347f0b8b702b84b7129dfcfcb3b84eff4e2f73/grafana/SampleCamelDashboard.json#L145
>>>> 
>>>> The other metrics (camel_k_* -
>>>> https://camel.apache.org/camel-k/next/observability/monitoring/operator.html#metrics)
>>>> are there as so the jvm metrics
>>>> (https://github.com/eclipse/microprofile-metrics/blob/master/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 the Prometheus instance, by 
>>>>> editing the Prometheus resource, e.g.:
>>>>> 
>>>>> apiVersion: monitoring.coreos.com/v1
>>>>> kind: Prome

Re: Camel-k and microprofile metrics

[Antonin Stefanutti]

quot;level":"info","ts":1637952061.270358,"logger":"camel-k.builder","msg":"step
> done in 0.008005
> seconds","step":"github.com/apache/camel-k/pkg/builder/LoadCamelQuarkusCatalog","phase":"0","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2704937,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/CleanUpBuildDir","phase":"9","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.272306,"logger":"camel-k.builder","msg":"step
> done in 0.001771
> seconds","step":"github.com/apache/camel-k/pkg/builder/CleanUpBuildDir","phase":"9","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.272396,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/GenerateJavaKeystore","phase":"10","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2724276,"logger":"camel-k.builder","msg":"step
> done in 0.01
> seconds","step":"github.com/apache/camel-k/pkg/builder/GenerateJavaKeystore","phase":"10","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2724893,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/GenerateQuarkusProject","phase":"10","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2754686,"logger":"camel-k.builder","msg":"step
> done in 0.10
> seconds","step":"github.com/apache/camel-k/pkg/builder/GenerateQuarkusProject","phase":"10","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2756126,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/GenerateProjectSettings","phase":"11","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2757154,"logger":"camel-k.builder","msg":"step
> done in 0.67
> seconds","step":"github.com/apache/camel-k/pkg/builder/GenerateProjectSettings","phase":"11","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2759113,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/InjectDependencies","phase":"12","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2762337,"logger":"camel-k.builder","msg":"step
> done in 0.000225
> seconds","step":"github.com/apache/camel-k/pkg/builder/InjectDependencies","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/apache/camel-k/pkg/builder/SanitizeDependencies","phase":"13","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2764044,"logger":"camel-k.builder","msg":"step
> done in 0.01
> seconds","step":"github.com/apache/camel-k/pkg/builder/SanitizeDependencies","phase":"13","task":"builder"}
> 26/11/2021 15:41:01
> {"level":"info","ts":1637952061.2765944,"logger":"camel-k.builder","msg":"executing
> step","step":"github.com/apache/camel-k/pkg/builder/BuildQuarkusRunner","phase&qu

Re: Camel-k and microprofile metrics

[Antonin Stefanutti]

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 remove them.

Last but not least, in order to understand why the build fails, could you 
please provide the operator Pod logs?

> On 26 Nov 2021, at 19:27, Roberto Camelk  wrote:
> 
> Hi, I'm trying to create a sample um route using microprofile metrics.
> 
> So I created this java source file containing:
> 
> //camel-k: dependency=camel-cron
> //camel-k: dependency=camel-quarkus-microprofile-metrics
> 
> public class LoggedInRoute extends RouteBuilder {
> 
>@Override
>public void configure() throws Exception {
>var seconds =
> java.util.concurrent.ThreadLocalRandom.current().nextInt(1, 10);
>from("cron:tab?schedule=0/5+*+*+*+*+?")
>.to("micrometer:timer:simpleTimerMock?action=start")
>.delay(seconds * 1000)
>.setBody(simple("{\"msg\":\"Seconds: " + seconds + "\"}"))
>.log("${body}")
>.to("micrometer:timer:simpleTimerMock?action=stop");
>}
> 
> }
> 
> To run it, I used this command:
> 
> kamel run test/Micrometer.java --dev
> 
> But camel-k CLI fails with this log:
> 
> Modeline options have been loaded from source files
> Full command: kamel run test/Micrometer.java --dev
> --dependency=camel-cron
> --dependency=camel-quarkus-microprofile-metrics
> Integration "micrometer" created
> Progress: integration "micrometer" in phase Initialization
> Condition "IntegrationPlatformAvailable" is "True" for Integration
> micrometer: platform/camel-k
> Integration "micrometer" in phase "Initialization"
> Progress: integration "micrometer" in phase Building Kit
> Integration "micrometer" in phase "Building Kit"
> Condition "IntegrationKitAvailable" is "False" for Integration
> micrometer: creating a new integration kit
> Integration Kit "kit-c6gi8msurk73bvs3vdu0", created by Integration
> "micrometer", changed phase to "Build Submitted"
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Scheduling"
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Pending"
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Running"
> Integration Kit "kit-c6gi8msurk73bvs3vdu0", created by Integration
> "micrometer", changed phase to "Build Running"
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Failed"
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Initialization" (recovery 1 of 5)
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Scheduling" (recovery 1 of 5)
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Pending" (recovery 1 of 5)
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Running" (recovery 1 of 5)
> Build "kit-c6gi8msurk73bvs3vdu0", created by Integration "micrometer",
> changed phase to "Failed" (recovery 1 of 5)
> (combined from similar events): Build "kit-c6gi8msurk73bvs3vdu0",
> created by Integration "micrometer", changed phase to "Initialization"
> (recovery 2 of 5)
> (combined from similar events): Build "kit-c6gi8msurk73bvs3vdu0",
> created by Integration "micrometer", changed phase to "Scheduling"
> (recovery 2 of 5)
> (combined from similar events): Build "kit-c6gi8msurk73bvs3vdu0",
> created by Integration "micrometer", changed phase to "Pending"
> (recovery 2 of 5)
> (combined from similar events): Build "kit-c6gi8msurk73bvs3vdu0",
> created by Integration "micrometer", changed phase to "Running"
> (recovery 2 of 5)
> ...

Re: Apache Camel-k metrics in rancher embedded prometheus

[Antonin Stefanutti]

Great!

For the metrics, there should be the following registered by the MicroProfile 
Metrics Camel extension:

https://camel.apache.org/camel-quarkus/2.4.x/reference/extensions/microprofile-metrics.html#_usage

However, the final name is determined by the MicroProfile Metrics 
specification, so for example the following metric:

camel.context.exchanges.completed.total

Have its name translated to:

application_camel_context_exchanges_completed_total

To check also if the metrics endpoint do have the metrics registered, you can 
run:

$ kubectl exec deployment/ -- curl -s 
http://localhost:8080/q/metrics | grep 
application_camel_route_exchanges_completed_total

# HELP application_camel_route_exchanges_completed_total The total number of 
completed exchanges for a route or Camel Context
# TYPE application_camel_route_exchanges_completed_total counter
application_camel_route_exchanges_completed_total{camelContext="camel-1",routeId="route1"}
 33.0

> On 26 Nov 2021, at 14:34, Roberto Camelk  wrote:
> 
> Thanks a lot again Antonin. I owe you a beer or coffee!!!
> 
> This worked 100%.
> 
> To end, another question after this, prometheus start scraping the
> metrics from my running route pod, but...
> 
> Some metrics IDs are not there, some metrics starting with
> "org_apache_camel_" as I have see in this grafana dashboard sample:
> https://github.com/weimeilin79/camel-k-example-prometheus/blob/ca347f0b8b702b84b7129dfcfcb3b84eff4e2f73/grafana/SampleCamelDashboard.json#L145
> 
> The other metrics (camel_k_* -
> https://camel.apache.org/camel-k/next/observability/monitoring/operator.html#metrics)
> are there as so the jvm metrics
> (https://github.com/eclipse/microprofile-metrics/blob/master/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 the Prometheus instance, by editing 
>> the Prometheus resource, e.g.:
>> 
>> apiVersion: monitoring.coreos.com/v1
>> kind: Prometheus
>> metadata:
>>  name: prometheus
>> spec:
>>  serviceAccountName: prometheus
>>  podMonitorSelector:
>>matchLabels:
>>  app: camel-k
>>  podMonitorNamespaceSelector: {}
>> 
>> It's important to have podMonitorNamespaceSelector: {} to discover all the 
>> namespaces, otherwise it's only the resource's namespace.
>> 
>> Also you can use the Prometheus trait to set the labels on the Integration 
>> PodMonitor accordingly, e.g.:
>> 
>> $ kamel run -t prometheus.enabled=true -t 
>> prometheus.pod-monitor-labels="app=camel-k"
>> 
>> There are some examples in the Prometheus operator documentation:
>> 
>> https://github.com/prometheus-operator/prometheus-operator/tree/v0.52.1/example/user-guides/getting-started
>> 
>> And the troubleshooting guide at:
>> 
>> https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/troubleshooting.md
>> 
>> 
>>> On 26 Nov 2021, at 12:32, Roberto Camelk  
>>> wrote:
>>> 
>>> Antonin. Thanks !
>>> 
>>> But I continue stuck, please let me share some extra info about my
>>> prometheus operator log:
>>> 
>>> level=debug ts=2021-11-26T11:12:05.837624346Z caller=operator.go:1840
>>> component=prometheusoperator msg="filtering namespaces to select
>>> PodMonitors from" namespaces=cattle-prometheus
>>> namespace=cattle-prometheus prometheus=cluster-monitoring
>>> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.837687534Z
>>> caller=operator.go:1853 component=prometheusoperator msg="selected
>>> PodMonitors" podmonitors= namespace=cattle-prometheus
>>> prometheus=cluster-monitoring
>>> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.942216811Z
>>> caller=operator.go:1677 component=prometheusoperator msg="updating
>>> Prometheus configuration secret skipped, no configuration change"
>>> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.950980834Z
>>> caller=operator.go:1776 component=prometheusoperator msg="filtering
>>> namespaces to select ServiceMonitors from"
>>> namespaces=cattle-prometheus,cattle-system,kube-node-lease,kube-public,security-scan,kube-system
>>> namespace=cattle-prometheus prometheus=cluster-monitoring
>>> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.951162973Z
>>> caller=operator.go:1810 component=prometheusoperator msg="selected
>>&

Re: Apache Camel-k metrics in rancher embedded prometheus

[Antonin Stefanutti]

It's likely that you need to configure the Prometheus instance, by editing the 
Prometheus resource, e.g.:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  podMonitorSelector:
matchLabels:
  app: camel-k
  podMonitorNamespaceSelector: {}

It's important to have podMonitorNamespaceSelector: {} to discover all the 
namespaces, otherwise it's only the resource's namespace.

Also you can use the Prometheus trait to set the labels on the Integration 
PodMonitor accordingly, e.g.:

$ kamel run -t prometheus.enabled=true -t 
prometheus.pod-monitor-labels="app=camel-k"

There are some examples in the Prometheus operator documentation:

https://github.com/prometheus-operator/prometheus-operator/tree/v0.52.1/example/user-guides/getting-started

And the troubleshooting guide at:

https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/troubleshooting.md


> On 26 Nov 2021, at 12:32, Roberto Camelk  wrote:
> 
> Antonin. Thanks !
> 
> But I continue stuck, please let me share some extra info about my
> prometheus operator log:
> 
> level=debug ts=2021-11-26T11:12:05.837624346Z caller=operator.go:1840
> component=prometheusoperator msg="filtering namespaces to select
> PodMonitors from" namespaces=cattle-prometheus
> namespace=cattle-prometheus prometheus=cluster-monitoring
> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.837687534Z
> caller=operator.go:1853 component=prometheusoperator msg="selected
> PodMonitors" podmonitors= namespace=cattle-prometheus
> prometheus=cluster-monitoring
> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.942216811Z
> caller=operator.go:1677 component=prometheusoperator msg="updating
> Prometheus configuration secret skipped, no configuration change"
> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.950980834Z
> caller=operator.go:1776 component=prometheusoperator msg="filtering
> namespaces to select ServiceMonitors from"
> namespaces=cattle-prometheus,cattle-system,kube-node-lease,kube-public,security-scan,kube-system
> namespace=cattle-prometheus prometheus=cluster-monitoring
> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.951162973Z
> caller=operator.go:1810 component=prometheusoperator msg="selected
> ServiceMonitors"
> servicemonitors=cattle-prometheus/grafana-cluster-monitoring,cattle-prometheus/exporter-kube-etcd-cluster-monitoring,cattle-prometheus/exporter-node-cluster-monitoring,cattle-prometheus/exporter-kube-controller-manager-cluster-monitoring,cattle-prometheus/exporter-kube-state-cluster-monitoring,cattle-prometheus/prometheus-cluster-monitoring,cattle-prometheus/prometheus-operator-monitoring-operator,cattle-prometheus/exporter-fluentd-cluster-monitoring,cattle-prometheus/exporter-kubelets-cluster-monitoring,cattle-prometheus/exporter-kube-scheduler-cluster-monitoring,cattle-prometheus/exporter-kubernetes-cluster-monitoring
> namespace=cattle-prometheus prometheus=cluster-monitoring
> 26/11/2021 08:12:05 level=debug ts=2021-11-26T11:12:05.977550133Z
> caller=operator.go:1741 component=prometheusoperator msg="updated
> tlsAssetsSecret" secretname=prometheus-cluster-monitoring-tls-assets
> 26/11/2021 08:12:06 level=debug ts=2021-11-26T11:12:06.022196407Z
> caller=operator.go:1169 component=prometheusoperator msg="new
> statefulset generation inputs match current, skipping any actions"
> 26/11/2021 08:12:26 level=debug ts=2021-11-26T11:12:26.321817491Z
> caller=operator.go:734 component=prometheusoperator msg="PodMonitor
> added"
> 26/11/2021 08:12:27 level=debug ts=2021-11-26T11:12:27.755854021Z
> caller=operator.go:748 component=prometheusoperator msg="PodMonitor
> updated"
> 26/11/2021 08:12:46 level=debug ts=2021-11-26T11:12:46.453112794Z
> caller=operator.go:748 component=prometheusoperator msg="PodMonitor
> updated"
> 26/11/2021 08:17:35 level=debug ts=2021-11-26T11:17:35.194031009Z
> caller=operator.go:759 component=prometheusoperator msg="PodMonitor
> delete"
> 
> This last 4 lines is about my camel-k route, that I ran and stopped.
> 
> So, there are some problems, I think, about the logs above about the
> podmonitor selectors telling: "selected 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 scrape configs to
> prometheus can solve this? Can you provide a snipet code?
> 
> On Thu, Nov 25, 2021 at 9:56 AM Antonin Stefanutti
>  wrote:
>> 
>> When run an Integration w

Re: Apache Camel-k metrics in rancher embedded prometheus

[Antonin Stefanutti]

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 
namespace, the labels, ...

Some documentation is available at:

https://camel.apache.org/camel-k/1.7.x/observability/monitoring/integration.html#_discovery

That contains some links to the Prometheus operator documentation for 
troubleshooting why the metrics endpoint is not discovered.

> On 25 Nov 2021, at 12:25, Roberto Camelk  wrote:
> 
> I have a Kubernetes running Rancher 2.4.3. I have the cluster
> monitoring enabled in rancher, so that exists a Prometheus instance
> running, so as a Prometheus Operator.
> 
> Recently I deployed a Apache Camel-K operator, and now I want to
> enable the prometheus integration for collect metrics about my camel
> routes.
> 
> So, my Camel-K operator is running in namescape camel-k and the
> rancher embedded prometheus stack in cattle-prometheus namespace.
> 
> I just have launched my route with the trait --trait
> prometheus.enabled=true, but the camel metrics aren't listing at my
> prometheus.
> 
> Anyone knows why or what I need to configure to my camel-k route
> deploy it's metrics at the rancher embedded prometheus?

Re: Camel-K builders garbage collection

[Antonin Stefanutti]

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 builders are 
> automatically being removed after their job is done?
> 
> Many thanks in advance
> Gerald

Re: [discuss] find a better name for KameletBinding

[Antonin Stefanutti]

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 integration domain to be a good fit, 
which
Would materialises in Kubernetes as 
bindings.camel.apache.org resources.

On 16 Aug 2021, at 10:27, Luca Burgazzoli 
mailto:lburgazz...@gmail.com>> wrote:

Hello,

When the KameletBinding concept was introduced in camel-k, if was meant to
bind two Kamelets and nothing more, but over time we have added more
capabilities, like:

- support for processing steps to transform exchanges/messages
- support to address/source from different systems so the source/sink does
not need be a kamelet anymore

So I think the term KameletBinding is not more appropriate and to reduce
confusion, we should try to find a better name.

On top of my mind, I'd see the following names as a possible replacement:
- Binding so leave Kamelet out of the game as Kamelets are one of the
option but not the exclusive on
- Connector as in essence, a KameletBinding describe how to connect A to B

Any opinion ?

---
Luca Burgazzoli

Re: Clarify test recommendations when using Arquillian?

[Antonin Stefanutti]

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: 

https://github.com/apache/camel/blob/ffbe4efdc9e065b076a3952631facae46a1e25f3/components/camel-cdi/src/test/java/org/apache/camel/cdi/bean/ManualStartupCamelContext.java

--
Antonin

> On 3 Jul 2019, at 17:35, Rick Wagner  wrote:
> 
> Hello Camel Riders,
> 
> I've recently spent some time working on Camel testing, but find the
> documentation a bit confusing when Camel is used with Arquillian.
> 
> The docs describe how 'AdviceWith' [1] can be used, and how
> isUseAdviceWith() can be used to let Camel know you are advising a route.
> The problem is that something like Arquillian can insert another layer of
> behavior into the scenario, the user may be unaware.  (The particular use
> case:  'AdviceWith' is ignored when using Arquillian, because Arquillian
> causes the route to be deployed and started before the unit test can apply
> 'AdviceWith'.)
> 
> Does anyone else find this confusing?
> 
> Thank you,
> 
> Rick
> 
> P.S.  I'd be glad to supply a PR or other suggested change to the Camel
> site, but I'm afraid I find the docs change process confusing as well.
> I've cloned the Camel repo, but can't seem to find the source for the
> article at [1], perhaps it's not on the source tip.  If I'm missing the
> 'right way' to do it, please let me know.
> 
> [1] https://camel.apache.org/advicewith.html

Re: [DISCUSS] - Apache Camel 3 - A new tagline

[Antonin Stefanutti]

> 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 connectors, is its target runtimes 
versatility. So Maybe something like:

"Apache Camel 3: Agile integration framework..."

As it captures that ability to run everywhere and may ring some other bells.

--
Antonin

> --
> Andrea Cosentino 
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
> 
> 
> 
> 
> 
> 
> On Tuesday, February 19, 2019, 4:52:06 PM GMT+1, Claus Ibsen 
>  wrote: 
> 
> 
> 
> 
> 
> Hi
> 
> As part of Apache Camel 3, we are working on a new modern website
> (yeah its long overdue, but work are in progress).
> 
> As part of that, we should get a new front-page with a new short
> summary what Apache Camel is (eg a tagline).
> 
> It would be good to get some ideas rolling what such a tagline could
> be and for users of Camel to come up with suggestions.
> 
> As Apache Camel has been around for so long, and that it covers so
> many different use-cases, then its maybe harder to come up with a
> single tag-line that spans all use-cases.
> 
> However with the new modern world of containers I came up with:
> 
> * Apache Camel 3 - A full-stack integration framework for building
> cloud-native micro integrations
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Camel CDI with non JTA transaction manager?

[Antonin Stefanutti]

> On 19 Oct 2018, at 12:33, Gary Hodgson  wrote:
> 
> Hi Antonin,
> 
> Thanks for the response. I'll revisit my previous attempts at integrating 
> standalone JTA - I believe I got a working example going, but had to put it 
> on hold during the testing.  If I get a 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: Antonin Stefanutti <>
> To: "users@camel.apache.org" 
> Cc: 
> Bcc: 
> Date: Thu, 18 Oct 2018 09:45:42 +
> Subject: Re: Camel CDI with non JTA transaction manager?
> 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 PlatformTransactionManager like:
> 
> @Produces
> @Singleton
> @Named("jtaTransactionManager")
> PlatformTransactionManager createTransactionManager(TransactionManager 
> transactionManager, UserTransaction userTransaction) {
> JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
> jtaTransactionManager.setUserTransaction(userTransaction);
> jtaTransactionManager.setTransactionManager(transactionManager);
> jtaTransactionManager.afterPropertiesSet();
> return jtaTransactionManager;
> }
> 
> And the JMS component:
> 
> @Produces
> @Named("jms-input")
> @ApplicationScoped
> Component produceInputJmsComponent(@ConfigProperty(name = 
> "jms.input.consumers") String inputQueueConcurrentConsumers) {
> CachingConnectionFactory cachingConnectionFactory = new 
> CachingConnectionFactory(connectionFactory);
> cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(consumers));
> return JmsComponent.jmsComponent(cachingConnectionFactory);
> 
> }
> 
> void disposeInputJmsComponent(@Disposes @Named("jms-input") Component 
> component) {
> ((SingleConnectionFactory) 
> component.getConfiguration().getConnectionFactory()).destroy();
> }
> 
> So that, you can write in your Camel routes:
> 
> from("jms-input:queue:{{jms.input.destination}}?transacted=true&concurrentConsumers={{jms.input.consumers}}&transactionManager=#jtaTransactionManager&cacheLevelName={{jms.input.consumers.cacheLevel}}")
> 
> I’ve already seen it implemented successfully.
> 
> Antonin
> 
> > On 18 Oct 2018, at 10:43, Gary Hodgson <> wrote:
> > 
> > Hi,
> > 
> > Is there a way to use JMSTransactionManager with cdi camel routes, i.e. not
> > JTA? It seems from the documentation and from googling that only JTA is
> > supported, and if this is the case then that entails camel-cdi is only
> > usable in JavaEE environments (when transactions are to be used at least).
> > 
> > We're using camel routes with CDI in a JavaSE environment but would like to
> > utilise the Transactional Client EIP rather than relying on exception
> > handlers.
> > 
> > Any hints would be appreciated,
> > Gary

Re: Camel CDI with non JTA transaction manager?

[Antonin Stefanutti]

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 PlatformTransactionManager like:

@Produces
@Singleton
@Named("jtaTransactionManager")
PlatformTransactionManager createTransactionManager(TransactionManager 
transactionManager, UserTransaction userTransaction) {
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransaction(userTransaction);
jtaTransactionManager.setTransactionManager(transactionManager);
jtaTransactionManager.afterPropertiesSet();
return jtaTransactionManager;
}

And the JMS component:

@Produces
@Named("jms-input")
@ApplicationScoped
Component produceInputJmsComponent(@ConfigProperty(name = 
"jms.input.consumers") String inputQueueConcurrentConsumers) {
CachingConnectionFactory cachingConnectionFactory = new 
CachingConnectionFactory(connectionFactory);
cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(consumers));
return JmsComponent.jmsComponent(cachingConnectionFactory);

}

void disposeInputJmsComponent(@Disposes @Named("jms-input") Component 
component) {
((SingleConnectionFactory) 
component.getConfiguration().getConnectionFactory()).destroy();
}

So that, you can write in your Camel routes:

from("jms-input:queue:{{jms.input.destination}}?transacted=true&concurrentConsumers={{jms.input.consumers}}&transactionManager=#jtaTransactionManager&cacheLevelName={{jms.input.consumers.cacheLevel}}")

I’ve already seen it implemented successfully.

Antonin

> On 18 Oct 2018, at 10:43, Gary Hodgson  wrote:
> 
> Hi,
> 
> Is there a way to use JMSTransactionManager with cdi camel routes, i.e. not
> JTA? It seems from the documentation and from googling that only JTA is
> supported, and if this is the case then that entails camel-cdi is only
> usable in JavaEE environments (when transactions are to be used at least).
> 
> We're using camel routes with CDI in a JavaSE environment but would like to
> utilise the Transactional Client EIP rather than relying on exception
> handlers.
> 
> Any hints would be appreciated,
> Gary

Re: Is it possible to use request scoped beans with Camel CDI ?

[Antonin Stefanutti]

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 integration currently does not provide support for automatic 
propagation of scopes like request scope.

This is something that we’d like to support though that may require a large 
effort to support all the possible cases where propagating thread-bound 
contexts is necessary (splitter, SEDA, ...).

I would suggest you create an issue in JIRA so that we can track your use case 
and start discussion the best approach to tackle the overall issue.

> I am using Camel CDI with Weld (Java DSL without Spring).
> 
> The pattern I am trying to implement is synchronous request response using
> parallel split-join to enrich my message before replying:
> 
> from("jetty:http://localhost:8280/metrics";)
> .to("http://localhost:10542/api/public/simulations?bridgeEndpoint=true";)
> .split().jsonpath("$").parallelProcessing()
> .setBody().jsonpath("$.id")
> // My call to third service would be there
> .bean(MyBean.class, "addItem")
> .end()
> .bean(MyBean.class, "items")
> .end();
> 
> Without CDI scope annotation on MyBean class:
> - a first instance is created and shared for every parallel calls
> (MyBean.addItem method binding)
> - a second instance is created at the end of the main route (MyBean.items
> method binding)
> 
> Of course I want to retrieve items added by every parallel calls.
> 
> With singleton scope qualifier, it is working but shared by every calls to
> the main route (see Jetty /metrics endpoint).
> 
> I need a way to share a "request" instance of my bean between the main
> route and the parallel (sub)routes but a new instance must be created for
> each call to the main route. @RequestScoped annotation
> throws ContextNotActiveException.
> 
> Is it possible ?
> 
> I tried using exchange properties but they are not shared between the main
> route and the parallel (sub)routes.

You may use the onPrepareRef option to propagate properties.

It might be possible to propagate the context "manually”.

An other approach to your problem may be to use the aggregate EIP with a 
batchAggregationStrategy that would be aware of the request context.

> Also, I had a look to camel examples but couldn't figure it out.
> 
> Thanks.
> 
> Best regards,
> 
> Julien

Hope it helps!

Antonin

Re: Camel CDI with standalone JTA in Weld SE

[Antonin Stefanutti]

 {commandId = 0, responseRequired = false, messageId =
>> null, originalDestination = null, originalTransactionId = null, producerId
>> = null, destination = null, transactionId = null, expiration = 0, timestamp
>> = 0, arrival = 0, brokerInTime = 0, brokerOutTime = 0, correlationId =
>> null, replyTo = null, persistent = false, type = null, priority = 0,
>> groupID = null, groupSequence = 0, targetConsumerId = null, compressed =
>> false, userID = null, content = null, marshalledProperties = null,
>> dataStructure = null, redeliveryCounter = 0, size = 0, properties = null,
>> readOnlyProperties = false, readOnlyBody = false, droppable = false,
>> jmsXGroupFirstForConsumer = false, text = null}
>>  [main] DEBUG com.atomikos.jms.AtomikosJmsMessageProducerProxy -
>> atomikos MessageProducer proxy for ActiveMQMessageProducer {
>> value=ID:garyhodgson-PC-57091-1511821093820-1:1:2:1 }: send ( message )...
>> 
>> Attempt to get transaction here...
>> 
>>  [main] TRACE com.atomikos.icatch.imp.CompositeTransactionManagerImp -
>> getCompositeTransaction() returning NULL!
>>  [main] WARN com.atomikos.jms.ConsumerProducerSupport - atomikos
>> MessageProducer proxy for ActiveMQMessageProducer {
>> value=ID:garyhodgson-PC-57091-1511821093820-1:1:2:1 }: The JMS session
>> you are using requires a JTA transaction context for the calling thread and
>> none was found.
>>  Please correct your code to do one of the following:
>>  1. start a JTA transaction if you want your JMS operations to be subject
>> to JTA commit/rollback, or
>>  2. increase the maxPoolSize of the AtomikosConnectionFactoryBean to
>> avoid transaction timeout while waiting for a connection, or
>>  3. create a non-transacted session and do session acknowledgment
>> 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 Antonin.
>>> 
>>> Thanks for the response.
>>> 
>>> I attempted a naive implementation of TransactionServices and it appears
>>> to load via the serviceloader correctly, and produce UserTransactions:
>>> https://github.com/garyhodgson/camel-example-cdi-standalone-
>>> jta/blob/TransactionServices/src/main/java/org/apache/
>>> camel/example/cdi/util/TransactionServices.java
>>> 
>>> Sadly the AtomikosTransactionRequiredJMSException is still thrown.
>>> 
>>> 
>>> On 6 November 2017 at 11:52, Antonin Stefanutti 
>>> wrote:
>>> 
>>>> 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.jboss.weld.transaction.spi.TransactionServices
>>>> and add it as a Weld service before starting the CDI container.
>>>> 
>>>> Let me know if that helps.
>>>> 
>>>> Antonin
>>>> 
>>>>> On 5 Nov 2017, at 21:54, Gary Hodgson 
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am trying to get camel-cdi to work with a standalone JTA provider in
>>>> a
>>>>> non-JEE environment.  I've made some progress but have a couple of
>>>> issues
>>>>> which I am not sure is due to my understanding or the code.
>>>>> 
>>>>> I created a standalone demo project here to show the issues:
>>>>> https://github.com/garyhodgson/camel-example-cdi-standalone-jta
>>>>> 
>>>>> The demo uses Atomikos as the JTA provider and embedded ActiveMQ for
>>>> JMS.
>>>>> Running the project with camel:run results in three messages being
>>>> sent to
>>>>> the route. The first two are called explicitly in a userTransaction and
>>>>> behave as expected: the first is processed normally, the second
>>>> triggers a
>>>>> rollback (as expected).
>>>>> 
>>>>> The third message is outside a userTransaction and throws the following
>>>>> exception from Atomikos:
>>>>> 
>>>>>   Caused by: com.atomikos.jms.AtomikosTrans
>>>> actionRequiredJMSException:
>

Re: Camel CDI with standalone JTA in Weld SE

[Antonin Stefanutti]

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.jboss.weld.transaction.spi.TransactionServices and add it as a Weld service 
before starting the CDI container.

Let me know if that helps.

Antonin

> On 5 Nov 2017, at 21:54, Gary Hodgson  wrote:
> 
> Hi,
> 
> I am trying to get camel-cdi to work with a standalone JTA provider in a
> non-JEE environment.  I've made some progress but have a couple of issues
> which I am not sure is due to my understanding or the code.
> 
> I created a standalone demo project here to show the issues:
> https://github.com/garyhodgson/camel-example-cdi-standalone-jta
> 
> The demo uses Atomikos as the JTA provider and embedded ActiveMQ for JMS.
> Running the project with camel:run results in three messages being sent to
> the route. The first two are called explicitly in a userTransaction and
> behave as expected: the first is processed normally, the second triggers a
> rollback (as expected).
> 
> The third message is outside a userTransaction and throws the following
> exception from Atomikos:
> 
>Caused by: com.atomikos.jms.AtomikosTransactionRequiredJMSException:
> The JMS session you are using requires a JTA transaction context for the
> calling thread and none was found.
>Please correct your code to do one of the following:
>1. start a JTA transaction if you want your JMS operations to be
> subject to JTA commit/rollback, or
>2. increase the maxPoolSize of the AtomikosConnectionFactoryBean to
> avoid transaction timeout while waiting for a connection, or
>3. create a non-transacted session and do session acknowledgment
> yourself, or
>4. set localTransactionMode to true so connection-level commit/rollback
> are enabled.
>  at
> com.atomikos.jms.AtomikosTransactionRequiredJMSException.throwAtomikosTransactionRequiredJMSException(AtomikosTransactionRequiredJMSException.java:23)
> ~[transactions-jms-4.0.4.jar:?]
>  at
> com.atomikos.jms.ConsumerProducerSupport.enlist(ConsumerProducerSupport.java:90)
> ~[transactions-jms-4.0.4.jar:?]
>  at
> com.atomikos.jms.AtomikosJmsMessageProducerProxy.send(AtomikosJmsMessageProducerProxy.java:34)
> ~[transactions-jms-4.0.4.jar:?]
>  at
> org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:626)
> ~[spring-jms-4.3.11.RELEASE.jar:4.3.11.RELEASE]
>  at
> org.apache.camel.component.jms.JmsConfiguration$CamelJmsTemplate.doSend(JmsConfiguration.java:624)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsConfiguration$CamelJmsTemplate.doSendToDestination(JmsConfiguration.java:563)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsConfiguration$CamelJmsTemplate.access$100(JmsConfiguration.java:505)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsConfiguration$CamelJmsTemplate$1.doInJms(JmsConfiguration.java:519)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:484)
> ~[spring-jms-4.3.11.RELEASE.jar:4.3.11.RELEASE]
>  at
> org.apache.camel.component.jms.JmsConfiguration$CamelJmsTemplate.send(JmsConfiguration.java:516)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsProducer.doSend(JmsProducer.java:440)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsProducer.processInOnly(JmsProducer.java:394)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.component.jms.JmsProducer.process(JmsProducer.java:157)
> ~[camel-jms-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
> ~[camel-core-2.20.0.jar:2.20.0]
>  at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
> ~[camel-core-2.20.0.jar:2.20.0]
>  ... 56 more
> 
> 
> I expected that "transacted()" on the 

Re: Using camel-cdi on Wildfly-10.1

[Antonin Stefanutti]

Ah indeed, it looks like DeltaSpike Data module impl JAR is included in:



https://github.com/apache/deltaspike/blob/a82f6ad27486756cc6d80d3a2db1695b779e36be/deltaspike/dist/full/src/main/distribution/modules-module.xml#L25-L26

That being said, it is likely to be an issue at how DeltaSpike integrates with 
WildFly module system rather than a Camel issue. SO I would you post a question 
on the WildFly forum or contact DeltaSpike user group.

Let us know what you think.

Antonin

> On 5 May 2017, at 11:35, Drazen Kozic  wrote:
> 
> Hello Antonin,
> Thanks for the help. My assumption also was related to DeltaSpike
> module configuration. Especially having in mind that tests are passing
> OK.
> I have downloaded distribution-full-1.7.2.zip of the DeltaSpike.
> Inside it there are module.xml files for Wildfly. I didn't change
> anything.
> 
> Regards
> 
> 
> 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 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 module or 
>> properly create a module for Deltaspike data module.
>> 
>> Antonin
>> 
>>> On 5 May 2017, at 08:05, Drazen Kozic  wrote:
>>> 
>>> Hello,
>>> 
>>> I want to use Camel 2.18.3 on WildFly-10.1.0.Final. My desired setup
>>> is as follow:
>>> - to use camel-cdi features
>>> - to deploy camel and all third party dependencies as WildFly modules
>>> - to deploy my application as war on WildFly with all internal
>>> dependencies as jars in web-inf/lib
>>> - I do not want to use WilfFly Camel Subsystem from
>>> https://github.com/wildfly-extras/wildfly-camel
>>> 
>>> I have deployed camel as module by looking at WildFly Camel Subsystem
>>> (wildfly-camel-patch-4.6.0). I took all content starting from
>>> modules/system/layers/fuse/org/apache/camel and put it into my Wildfly
>>> installation into modules/system/layers/base/org/apache/camel.
>>> 
>>> I have created some routes and processors. Everything went fine untill
>>> moment when I modified my processor to trigger one of my services
>>> which are using Deltaspike data module functionality. I got this log
>>> output:
>>> 
>>> 17:27:52,280 INFO
>>> [com.mvneco.tebio.batch.common.BatchCamelContextProducer] (MSC service
>>> thread 1-5) CamelContext configured: batch-camel-context
>>> 17:27:52,297 INFO  [com.mvneco.tebio.batch.simple.MySimpleProcessor]
>>> (MSC service thread 1-5) Processor constructed: MySimpleProcessor
>>> 17:27:52,335 INFO  [com.mvneco.tebio.batch.simple.MySimpleRoute] (MSC
>>> service thread 1-5) Route configured: MySimpleRoute
>>> 17:27:52,341 INFO  [org.apache.camel.cdi.CdiCamelExtension] (MSC
>>> service thread 1-5) Camel CDI is starting Camel context
>>> [batch-camel-context]
>>> 17:27:52,342 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
>>> service thread 1-5) Apache Camel 2.18.3 (CamelContext:
>>> batch-camel-context) is starting
>>> 17:27:52,344 INFO
>>> [org.apache.camel.management.ManagedManagementStrategy] (MSC service
>>> thread 1-5) JMX is enabled
>>> 17:27:52,455 INFO
>>> [org.apache.camel.impl.converter.DefaultTypeConverter] (MSC service
>>> thread 1-5) Loaded 189 type converters
>>> 17:27:52,493 INFO
>>> [org.apache.camel.impl.DefaultRuntimeEndpointRegistry] (MSC service
>>> thread 1-5) Runtime endpoint registry is in extended mode gathering
>>> usage statistics of all incoming and outgoing endpoints (cache limit:
>>> 1000)
>>> 17:27:52,498 WARN  [org.jboss.as.weld] (MSC service thread 1-5)
>>> WFLYWELD0052: Using deployment classloader to load proxy classes for
>>> module org.apache.camel.core:main. Package-private access will not
>>> work. To fix this the module should declare dependencies on
>>> [org.jboss.weld.core, org.jboss.weld.spi]
>>> 17:27:52,630 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
>>> service thread 1-5) StreamCaching is not in use. If using streams then
>>> its recommended to enable stream caching. See more details at
>>> http://camel.apache.org/stream-caching.html
>>> 17:27:52,693 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
>>> service thread 1-5) Route: MySimpleRoute 

Re: Using camel-cdi on Wildfly-10.1

[Antonin Stefanutti]

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 module or properly create a 
module for Deltaspike data module.

Antonin

> On 5 May 2017, at 08:05, Drazen Kozic  wrote:
> 
> Hello,
> 
> I want to use Camel 2.18.3 on WildFly-10.1.0.Final. My desired setup
> is as follow:
> - to use camel-cdi features
> - to deploy camel and all third party dependencies as WildFly modules
> - to deploy my application as war on WildFly with all internal
> dependencies as jars in web-inf/lib
> - I do not want to use WilfFly Camel Subsystem from
> https://github.com/wildfly-extras/wildfly-camel
> 
> I have deployed camel as module by looking at WildFly Camel Subsystem
> (wildfly-camel-patch-4.6.0). I took all content starting from
> modules/system/layers/fuse/org/apache/camel and put it into my Wildfly
> installation into modules/system/layers/base/org/apache/camel.
> 
> I have created some routes and processors. Everything went fine untill
> moment when I modified my processor to trigger one of my services
> which are using Deltaspike data module functionality. I got this log
> output:
> 
> 17:27:52,280 INFO
> [com.mvneco.tebio.batch.common.BatchCamelContextProducer] (MSC service
> thread 1-5) CamelContext configured: batch-camel-context
> 17:27:52,297 INFO  [com.mvneco.tebio.batch.simple.MySimpleProcessor]
> (MSC service thread 1-5) Processor constructed: MySimpleProcessor
> 17:27:52,335 INFO  [com.mvneco.tebio.batch.simple.MySimpleRoute] (MSC
> service thread 1-5) Route configured: MySimpleRoute
> 17:27:52,341 INFO  [org.apache.camel.cdi.CdiCamelExtension] (MSC
> service thread 1-5) Camel CDI is starting Camel context
> [batch-camel-context]
> 17:27:52,342 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
> service thread 1-5) Apache Camel 2.18.3 (CamelContext:
> batch-camel-context) is starting
> 17:27:52,344 INFO
> [org.apache.camel.management.ManagedManagementStrategy] (MSC service
> thread 1-5) JMX is enabled
> 17:27:52,455 INFO
> [org.apache.camel.impl.converter.DefaultTypeConverter] (MSC service
> thread 1-5) Loaded 189 type converters
> 17:27:52,493 INFO
> [org.apache.camel.impl.DefaultRuntimeEndpointRegistry] (MSC service
> thread 1-5) Runtime endpoint registry is in extended mode gathering
> usage statistics of all incoming and outgoing endpoints (cache limit:
> 1000)
> 17:27:52,498 WARN  [org.jboss.as.weld] (MSC service thread 1-5)
> WFLYWELD0052: Using deployment classloader to load proxy classes for
> module org.apache.camel.core:main. Package-private access will not
> work. To fix this the module should declare dependencies on
> [org.jboss.weld.core, org.jboss.weld.spi]
> 17:27:52,630 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
> service thread 1-5) StreamCaching is not in use. If using streams then
> its recommended to enable stream caching. See more details at
> http://camel.apache.org/stream-caching.html
> 17:27:52,693 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
> service thread 1-5) Route: MySimpleRoute started and consuming from:
> file://c:/test-folder?move=.done&moveFailed=.error
> 17:27:52,694 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
> service thread 1-5) Total 1 routes, of which 1 are started.
> 17:27:52,695 INFO  [org.apache.camel.impl.DefaultCamelContext] (MSC
> service thread 1-5) Apache Camel 2.18.3 (CamelContext:
> batch-camel-context) started in 0.351 seconds
> 17:27:52,968 INFO  [org.wildfly.extension.undertow] (ServerService
> Thread Pool -- 59) WFLYUT0021: Registered web context: /tebio-batch
> 17:27:53,013 INFO  [org.jboss.as.server] (ServerService Thread Pool --
> 34) WFLYSRV0010: Deployed "tebio-batch.war" (runtime-name :
> "tebio-batch.war")
> 17:27:53,164 INFO  [org.jboss.as] (Controller Boot Thread)
> WFLYSRV0060: Http management interface listening on
> http://127.0.0.1:9990/management
> 17:27:53,165 INFO  [org.jboss.as] (Controller Boot Thread)
> WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 17:27:53,165 INFO  [org.jboss.as] (Controller Boot Thread)
> WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final)
> started in 17385ms - Started 465 of 713 services (409 services are
> lazy, passive or on-demand)
> 17:28:14,328 WARN
> [org.apache.camel.component.file.GenericFileOnCompletion] (Camel
> (batch-camel-context) thread #0 - file://c:/test-folder) Rollback file
> strategy: 
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@77ab824b
> for file: GenericFile[c:\test-folder\test1.txt]
> 17:28:14,337 ERROR [com.mvneco.tebio.batch] (Camel
> (batch-camel-context) thread #0 - file://c:/test-folder) Failed
> delivery for (MessageId: ID-dkozic-PC-58228-1493825271666-0-1 on
> ExchangeId: ID-dkozic-PC-58228-1493825271666-0-2). Exhausted after
> delivery attem

Re: Camel-CDI in a multi-module project

[Antonin Stefanutti]

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* "beans.xml" on the webapp level
> was sufficient to activate the bean discovery for the *whole* application. I
> did not know a separate file on *each* module was necessary...
> 
> So, this was not a Camel nor Wildfly issue.
> Let's say is was rather a  PEBCAK   
> ;-)

These are hard to spot, but generally easy to fix ;)

> Everything is working fine now.
> Thank you very much for your precious help.

I’m glad it works!

> Regards,
> 
> Bernard.
> 
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-CDI-in-a-multi-module-project-tp5797510p5797691.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel-CDI in a multi-module project

[Antonin Stefanutti]

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:
> 
> 
> And the resulting war has the following structure
> 
> 
> Each module contains the following Camel stuff:
> 
> 
> When deployed on my app-server, I notice the following behaviour (with Camel
> 2.18.1).
> 
> 1) As long as this Camel stuff remains in the embedded jars, Camel does
> *NOT* see them. So Camel is not starting at all...
> 
> 2) If I move the various context producers into the webapp module
> (=>ContextFactory class now in WEB-INF/classes instead of
> /WEB-INF/lib/module-i.jar), then Camel is starting... Great ! But the
> started contexts do not detect my routes. So all contexts are empty :-(
> 
> So my conclusion is that Camel-CDI (classloader) expects that everything
> (=context producers as well as route definitions) should be located in
> WEB-INF/classes.
> Is this assumption right ?

Camel CDI is basically a CDI extension so it does not affect the way beans 
archives are being discovered and deployed by the container nor classes are 
being loaded. It solely up to the container, in your case WildFly.

> What are the solutions to make it work ?

I would expect the library JARs packaged within you WAR to be deployed as beans 
archives as long as they have a beans.xml file in module.jar/META-INF 
directory. Is this the case?

There may be some classloading issues but then you should turn to WildFly 
team...

> PS: I'm deploying to Wildfly 10.1.0. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-CDI-in-a-multi-module-project-tp5797510.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Why do we have to specify a context for @PropertyInject ?

[Antonin Stefanutti]

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: 
> http://camel.465427.n5.nabble.com/Why-do-we-have-to-specify-a-context-for-PropertyInject-tp5796699p5796750.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Why do we have we to specify a context for @PropertyInject ?

[Antonin Stefanutti]

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 qualifier) Camel context is 
resolved.

There is no further logic nor convention beyond that context attribute. I guess 
this is the way other DI frameworks handle bean post processing as well to 
support Camel annotations (which all have that context attribute).

That being said, we could add more sensible convention to the default 
behaviour, like when processing beans of type CamelContextAware, or 
BuilderSupport in you case, for which a Camel context may have been set already.

I would suggest you create a ticket in JIRA to track that enhancement.

Antonin

> On 29 Mar 2017, at 15:58, Bernard Ligny  wrote:
> 
> I am using Camel-CDI features in a war with multiple camel contexts
> (initialised via a factory), all of them sharing the same set of Camel
> components (initialised via a factory):
> 
> 
> In a route being part of a particular context, I want to inject properties
> (coming from my property file):
> 
> 
> This is working fine...as soon as i specify a context on the
> @PropertyInject.
> I do not understand why the context addition is necessary as:
> - the context is already set on the route builder 
> - my properties component is shared across all contexts (cfr
> @ApplicationScoped) 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Why-do-we-have-we-to-specify-a-context-for-PropertyInject-tp5796699.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Conditional registration of routes (or route builders)

[Antonin Stefanutti]

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 {

   void excludeRoutes(@Observes ProcessAnnotatedType 
pat) {
if (toExcludeForCustomer(pat.getAnnotatedType().getJavaClass()))
  pat.veto(); 
  }

}

Similarly, you can easily veto all the RouteBuilder classes from being 
discovered and add them manually to implement a white listing strategy.

We may want to have an @Conditional annotation (like in Spring) but then the 
condition will have to be based on a generic semantic.

Antonin

> On 16 Mar 2017, at 14:34, Bernard Ligny  wrote:
> 
> Hi Camel folks
> 
> I would like to have some advices/recommandations about the following
> requirement.
> 
> We have a webapp with *many* Camel routes (started with Camel-CDI). This war
> is deployed on various application servers for various customers.
> Some of theses routes are common to all customers, while other routes are
> limited/dedicated to a single customer (and should therefore not be
> "deployed" for all customers)
> 
> What would be the best solution to have a conditional (> depending on
> props/conf file) registration of my routes ?
> Please note I wish a conditional *registration* and not *starting* (> I do
> not want the unused routes to be part of my CamelContext, nor to be visible
> in hawt-io).
> So disabling autostart + manually starting needed routes is not an option...
> 
> Any idea  ? - of something different from this:
> 
> 
> I was thinking about a new annotation on the routebuilder, eg
> 
> 
> 
> Another alternative (but which requires a lot more refactoring) would be to
> have a more "micro-services" oriented approach, to break my monolithic war
> into a set of jars (each jar embedding a SINGLE RouteBuilder), and than in
> the war assembly phase, build a customer-specific artifact (that is, exclude
> the jars containing unneeded routes).
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Conditional-registration-of-routes-or-route-builders-tp5795589.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Simple CDI setup with Weld

[Antonin Stefanutti]

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/6e95af29bc289a60fa633530118f5a11a1ff55cd/examples/camel-example-cdi-metrics/pom.xml#L109-L113

Note that this dependency may be removed with CDI 2.0, as a standard way of 
bootstrapping CDI in Java SE is now provided.

Antonin

> On 20 Jan 2017, at 12:47, Tim Dudgeon  wrote:
> 
> Hi,
> 
> I'm trying to setup a simple Java SE app using Camel CDI and Weld.
> 
> The docs state that this can be run using the org.apache.camel.cdi.Main class.
> However when running this I get an exception:
> 
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/deltaspike/cdise/api/CdiContainerLoader
> at org.apache.camel.cdi.Main.doStart(Main.java:96)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at org.apache.camel.main.MainSupport.run(MainSupport.java:138)
> at org.apache.camel.main.MainSupport.run(MainSupport.java:390)
> at org.apache.camel.cdi.Main.main(Main.java:64)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.deltaspike.cdise.api.CdiContainerLoader
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 5 more
> 
> Looking at the source for that class is seems to assume its using Deltaspike 
> as the CDI implementation, but obviously I don't have the Deltaspike classes 
> present (not are they a transient dependency of camel-cdi.
> 
> So what is the right way to launch a Weld CDI Camel Java SE app?
> 
> Tim
> 
> 
> 

Re: sql component using spring-boot datasource

[Antonin Stefanutti]

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/application.yml#L26-L29

And the use in the Camel DSL:

https://github.com/fabric8-quickstarts/spring-boot-camel-rest-sql/blob/3fdcb17ce52d3f42f63dc38e6d73cf97deafefb2/src/main/java/io/fabric8/quickstarts/camel/Application.java#L63

Antonin

> On 19 Dec 2016, at 19:25, Claus Ibsen  wrote:
> 
> Hi
> 
> Yeah it would be nicer if we can make it use the spring boot data
> source OOTB, you setup in the application.properties file.
> 
> I have logged a ticket
> https://issues.apache.org/jira/browse/CAMEL-10618
> 
> 
> 
> On Mon, Dec 19, 2016 at 7:19 PM, Launcelot  wrote:
>> This could be a rookie mistake, if so apologies in advance
>> My router code :
>> @SpringBootApplication
>> public class MySpringBootRouter extends RouteBuilder {
>> 
>>@Autowired
>>DataSource dataSource;
>> 
>>public DataSource getDataSource() {
>>return dataSource;
>>}
>> 
>>public void setDataSource(DataSource dataSource) {
>>this.dataSource = dataSource;
>>}
>> 
>>@Override
>>public void configure() {
>> 
>>DataFormat mySyslog = new SyslogDataFormat().getDataFormat();
>> 
>>from("sql:select * from o365investigations.auditaad where
>> status=0").routeId("aadroute")
>> 
>> .onException(java.lang.Exception.class).useOriginalMessage().handled(true)
>>.to("sql:update o365investigations.auditaad 
>> set Status=2 where id =
>> :#ID?dataSource=#dataSource")
>>.log("Exception in auditaad 
>> ").end().transacted()
>>.to("sql:update o365investigations.auditaad 
>> set status=1 where id =
>> :#ID?dataSource=#dataSource")
>> 
>> .to("direct:debug").bean("com.standard.camel.converter.AuditToSyslogBean").marshal(mySyslog)
>>.to("mina2:udp://localhost:514?sync=false");
>> 
>>from("direct:debug").log("$body");
>> 
>>}
>> 
>> }
>> 
>> My application.yml :
>> 
>> spring.main.sources: deleteme.MySpringBootRouter
>> spring.datasource.url: jdbc:mysql://localhost:3306/o365investigations
>> 
>> spring.datasource.username: 
>> 
>> spring.datasource.password: 
>> 
>> spring.datasource.driver-class-name: com.mysql.jdbc.Driver
>> 
>> On mvn spring-boot:run I get
>> Failed to resolve endpoint:
>> sql://select%20*%20from%20o365investigations.auditaad%20where%20status=0 due
>> to: DataSource must be configured -> [Help 1]
>> 
>> I initially had dataSource=dataSource in the url but changed it to
>> #dataSource based on a post i saw trawling for a solution by Mr Ibsen.
>> Either way gives me the same error.
>> 
>> Please help,
>> 
>> Thanks
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://camel.465427.n5.nabble.com/sql-component-using-spring-boot-datasource-tp5791719.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: IdempotentExtractor error in CDI context

[Antonin Stefanutti]

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 annotated with @ApplicationScoped, and inside a route with
> idempotent
> settings.
> 
> Before route starts, i get this error,  
> 
> 07-12-2016 09:03:00 ERROR [DefaultQuartzScheduler-camel-1_Worker-4]
> IdempotentExtractor: Class='org.jboss.weld.bean.ProducerMethod'
> method='getEnhancedAnnotated' error='IllegalStateException: Enhanced
> metadata should not be used at runtime.'
> 
> and every file will be loaded. Idempotent is ignored.
> 
> I'm using camel 2.18.1.
> 
> Is this a bug or i set up something wrong ?
> 
> Regards
> Karlheinz
> 
> 
> 
> 
> 
> 
> 
> 
> -
> kh
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/IdempotentExtractor-error-in-CDI-context-tp5791192.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Canot start DefaultCamelContext for Camel-core 2.18.0

[Antonin Stefanutti]

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:
>> I simply create DefaultCamelContext and start for camel-core-2.18.0
>> 
>> public class Appl {
>>  public static void main(String[] args) throws Exception{
>>CamelContext context = new DefaultCamelContext();
>>context.start();
>>  }
>> }
>> 
>> However, it throws UnsupportedOperationException. It works fine in
>> camel-core-2.14.4.
>> 
>> Exception in thread "main" java.lang.UnsupportedOperationException
>> at
>> java.util.concurrent.CopyOnWriteArrayList$COWIterator.set(CopyOnWriteArrayList.java:1185)
>> at java.util.Collections.sort(Collections.java:234)
>> at
>> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3525)
>> at
>> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3308)
>> at
>> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3162)
>> at
>> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:182)
>> at
>> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2957)
>> at
>> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2953)
>> at
>> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2976)
>> at
>> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2953)
>> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
>> at
>> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2920)
>> at com.techoffice.example.Appl.main(Appl.java:18)
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://camel.465427.n5.nabble.com/Canot-start-DefaultCamelContext-for-Camel-core-2-18-0-tp5790801.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Testing CDI Route

[Antonin Stefanutti]

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
> injecting and mocking of the parts of the route.
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709p5789738.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Testing CDI Route

[Antonin Stefanutti]

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 with its default discovery mode 
enabled, hence those classes being deployed as well. IMHO, it’d be better to 
align with the testing approach recommended by WildFly Swarm as that is likely 
to make your life easier in the long run.

Antonin

> On 03 Nov 2016, at 17:06, Oli  wrote:
> 
> Hi Antonin,
> 
> in other words, CamelCdiRunner would do the job? Why it doesn't work for me?
> The test class:
> 
> @RunWith(CamelCdiRunner.class)
> @Beans(classes = Route.class)
> public class RouteTest {
> 
>void advice(
>@Observes CamelContextStartingEvent event, 
>@Uri("mock:test") MockEndpoint messages, 
>ModelCamelContext context) throws Exception {
> 
>context.getRouteDefinition("route")
>.adviceWith(context, new AdviceWithRouteBuilder() {
>@Override
>public void configure() {
>replaceFromWith("direct:start");
>weaveById("mybean").replace().to("mock:mybean");
>}
>});
>}
> 
>@Test
>/**
> * testing if the bean was properly mocked
> */
>public void testRoute(
>@Uri("direct:in") ProducerTemplate producer,
>@Uri("mock:mybean") MockEndpoint mock) throws
> InterruptedException {
> 
>mock.expectedMessageCount(1);
>mock.expectedBodiesReceived("bar");
>producer.sendBody("bar");
>MockEndpoint.assertIsSatisfied(5L, TimeUnit.SECONDS, mock);
>}
> 
> }
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709p5789714.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Testing CDI Route

[Antonin Stefanutti]

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 find some examples in the 
WildFly Swarm project, like 
https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/master/camel/camel-cdi.

Hope that helps.

Antonin 

> On 03 Nov 2016, at 15:30, Oli  wrote:
> 
> Hello camel experts,
> 
> I'm using camel inside of wildfly swarm application and having trouble to
> create a working test with CamelCdiRunner. I've followed the example from
> camel documentation but the test I've created fails with the error:
> 
> java.lang.NullPointerException
>   at
> org.wildfly.swarm.cdi.StageConfigBean.getBeanClass(StageConfigBean.java:48)
> 
> Now, I realize that it is might be wildfly swarm issue (or my fault :D), but
> I hope that there is the way to test the route without involving wildfly
> swarm at all. That's why I've used CamelCdiRunner. 
> 
> Here is demo project with the test.
> 
> https://doc-08-1o-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/g6huv41c8phejsrv7f9djrkie28con92/147818160/04138686178860852595/*/0B48lpc4O6VLJam5TLTZoc3VCZG8?e=download
> 
> Thank you
> 
> - oli
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: CamelCdiRunner loads all routes in each test case (sometimes)

[Antonin Stefanutti]

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 which is the intended
> behaviour. In both projects, my RouteBuilders are annotated with the
> following annotations, and are picked up by Wildfly with camel-wildfly
> added.
> 
> @Startup
> @ApplicationScoped
> @ContextName("foo-context")
> 
> In my jUnit tests however, the routes of project 1 are only picked up, when
> i add the RouteBuilder to @Beans(...) like this:
> 
> @RunWith(CamelCdiRunner.class)
> @Beans(classes = {MyFooRouteBuilder.class})
> 
> ... But in project 2, the routes are picked up (by Weld i guess) without
> adding @Beans, and if i add @Beans i get the following error from Weld:
> 
> org.jboss.weld.exceptions.DeploymentException: Exception List with 1
> exceptions:
> Exception 0 :
> org.apache.camel.FailedToStartRouteException: Failed to start route
> MyFooRouteRoute because of duplicate id detected: MyFooRouteRoute. Please
> correct ids to be unique among all your routes.
> at
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:963)
> at
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3295)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3018)
> 
> I've gone though the classpath, and it seems to be fairly similar with
> regards to Camel, Weld and Injection, which leaves med with a couple of
> questions:
> 
> 1) Which is the intended behaviour? I've found an email from @astefanutti (
> http://camel.465427.n5.nabble.com/Came-CDI-tests-start-non-test-routes-td5783324.html),
> that says that all routes should be loaded by default in test cases, but
> that does not seem desirable in larger projects.

For the time being, CamelCdiRunner bootstrap a Weld SE container with its 
discovery mode enabled, that is every explicit beans archive (that is with a 
beans.xml) that’s available in the classpath gets added to the deployment. 
@Beans annotations can then be used to add additional classes to that 
deployment, for example for test classes (generally test classes are not 
packaged in bean archives).

> 2) If the default behaviur is "load all", how do i keep that from
> happening, without changing my business-code?

The idea behind the CamelCdiRunner is to provide the simplest way to bootstrap 
your application in a SE CDI container for you to test. So it relies on what's 
available in the classpath. Besides, you can still rely on CDI features like 
alternatives and decorators, should you modify your application logic for 
testing purpose.

In case your classpath is too complex, the idea is to use Arquillian which 
leverages ShrinkWrap in order to build your test deployments as documented in 
[1].

That being said, we may want to improve CamelCdiRunner to meet your need, 
provided that it does not hinder the original intent, that is simplicity and 
convention over configuration.

> 3) If Weld and Camel versions are the same - where do i look for the
> error??!?

Not sure I understand the question here :(

Let us know if that helps.

[1]: http://camel.apache.org/cdi-testing.html#CDITesting-Arquillian

Antonin

Re: camel-cdi projects as fat jar

[Antonin Stefanutti]

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 shaded JAR which 
has other pros and cons.

[1] https://issues.jboss.org/browse/WELD-1930

Antonin

> On 26 Aug 2016, at 14:27, a746076drdrb  wrote:
> 
> Hello,
> 
> I've created example app with camel-cdi and it works, if launched with
> maven. However, I'd like to package and deploy it as a single jar file and
> it doesn't work. With other camel routes which don't use CDI it works fine.
> The error:
> 
> Exception in thread "main"
> javax.enterprise.inject.UnsatisfiedResolutionException: WELD-ENV-18:
> Unable to resolve a bean for class
> org.jboss.weld.environment.se.WeldContainer with bindings []
> 
> I've read some posts its not recommended to deploy cdi app as fat jar, but
> it would be very convenient. Had anyone success with it?
> 
> Regards,
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/camel-cdi-projects-as-fat-jar-tp5786762.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: CDI!

[Antonin Stefanutti]

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://github.com/apache/camel/tree/master/examples/camel-example-cdi-test

Antonin

> On 24 Aug 2016, at 22:19, Brad Johnson  wrote:
> 
> Great job on the CDI integration with OSGi support.  It's really fantastic.
> 
> 
> The only thing I've noticed is that the CDI runner for the unit tests will
> pick up the Camel route tests but doesn't run the other tests that are
> decorated with @RunWith(CamelCdiRunner.class)
> 
> Not a huge issue as the tests will still run when invoked by hand in
> Eclipse but don't run out of Maven.
> 
> Brad

Re: Camel CDI

[Antonin Stefanutti]

Camel CDI is not based on Weld, it’s only the Camel CDI test facility which 
relies on it for the JUnit runner as the simplest way to bootstrap a CDI 
capable environment. You can quite easily achieve the same with Arquillian if 
you need to target other kind of CDI environments, though Camel CDI test can be 
adapted if needed.

For the OSGi support, there is already some *optional* OSGi bits in Camel CDI, 
that adapts the Camel contexts managed by Camel CDI to be fully capable in OSGi 
runtimes [1].

Then, the idea is to use the PAX CDI API to have the CDI / OSGi integration. 
However the SCR integration is still an open area AFAIK. Obviously, Camel CDI 
could be improved to integrate that work at some point, provided that it'll 
remain optional for other type of users.

[1]: 
https://github.com/apache/camel/blob/0421c24dfcf992f3296ed746469771e3800200e3/components/camel-cdi/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java#L32
 

Antonin

> On 22 Aug 2016, at 17:26, Brad Johnson  wrote:
> 
> That's what gets a bit confusing about it all.  I'm coming from Blueprint
> which I've used for a few years now and very much like the automated wiring
> provided by CDI and especially the ease of testing.  But as I read about DS
> and CDI it gets a bit confusing.  Camel SCR probably can't work with CDI
> since it overrides an AbstractCamelRunner which requires route builder set
> up but CDI would likely bootstrap those routes.  I don't find not being
> able to use SCR a big loss however.
> 
> At this point even if I had to give up exporting services into the OSGi
> registry I'd probably live with it and simple use routes for integration.
> But working with the Camel CDI in 2.17 it is based on Weld, which is fine,
> and not on PAX CDI so as you point out the OSGi service annotations aren't
> there.  Which sort of anticipated the question I had this week end about
> whether or not those would be ported. So my dependencies look like this:
> 
> UTF-8
> UTF-8
> 
> 2.17.3
> 1.2
> 1.8
> 
> 
> 
> javax.enterprise
> cdi-api
> ${cdi.version}
> 
> 
> org.apache.camel
> camel-cdi
> ${camel.version}
> 
> 
> So then I'm rummaging around trying to figure out how this is going to work
> in the OSGi environment (Fuse 6.3 is pregnant and ready to drop an M1 soon
> I think).  The only difference I can really see there is that the
> camel-example-cdi-osgi also contains the basic OSGi pieces as provided and
> uses Pax Exam for tests.  I think Pax Exam is fine for integration testing
> but for basic unit tests it is a bit heavyweight and I'd prefer the Camel
> CDI test runner even if I have to mock external services.
> 
>
>
>  org.osgi
>  org.osgi.core
>  provided
>
>
>  org.osgi
>  org.osgi.compendium
>  provided
>
> 
> 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 as a
> dependency/installed as a feature in addition to camel-cdi?
> 
> Thanks for the feedback,
> Brad
> 
> On Mon, Aug 22, 2016 at 10:08 AM, Antonin Stefanutti 
> wrote:
> 
>> 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 the
>> objective here was to prove technically the portability of "plain" Camel
>> CDI applications on OSGi. The main outcome has been captured in [2], which
>> highlights the difficulty to make the CDI implementations subclass proxying
>> mechanism working seamlessly in a class loader constrained environment such
>> as OSGi.
>> 
>> Then, from the functional standpoint, Guillaume Nodet has been working
>> lately on improving the SCR-like annotation support [3]. Though I haven’t
>> found the time yet to test it with Camel CDI in particular.
>> 
>> [1]: https://github.com/astefanutti/camel-cdi/tree/
>> master/envs/osgi/src/test/java/org/apache/camel/cdi/osgi
>> [2]: https://github.com/ops4j/org.ops4j.pax.cdi/pull/30
>> [3]: https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-
>> cdi-api/src/main/java/org/ops4j/pax/cdi/api
>> 
>> Antonin
>> 
>>> On 22 Aug 2016, at 16:33, Brad Johnson 
>> wrote:
>>> 
>>> Has anyone used Camel CDI in an OSGi environment?  Does it work well or
>> at
>>> least OK there?
>>> 
>>> Brad
>> 
>> 

Re: Camel SCR and CDI

[Antonin Stefanutti]

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 / SCR integration is an area that still needs some 
work.

Antonin

> On 21 Aug 2016, at 02:38, Brad Johnson  wrote:
> 
> I've been working a bit with both the Camel SCR and CDI lately.  The CDI is
> quite impressive and works very well. SCR I'm not so certain about yet.
> 
> What I'm really unsure about is if they are compatible and can be used
> together.  I don't suppose there is anything that technically keeps them
> from working together but the examples of Camel SCR use the AbstractCamel
> runner which requires a list of route builders.
> 
> The Camel CDI automatically runs RouteBuilders it finds that are marked as
> such so it might end up with two of them making two starts.
> 
> Are they not supposed to be used together?
> 
> Part of what makes this a real question for me know is the Kura library as
> well.  It has an OSGi way of exposing it to the world.
> 
>  activate="activate" deactivate="deactivate" enabled="true" immediate="true">
>  
> 
> 
> So it's difficult to imagine how all three of those technologies might be
> used together or if they should be used together.
> 
> Any insights or thoughts or guesses are appreciated.
> Brad

Re: Question about OSGi services with Camel 2.17

[Antonin Stefanutti]

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 ApplicationScoped that gets exported via the OSGi
> service registry? But it is also a Camel component which may have other in
> built mechanisms that might be required. If it isn't ApplicationScoped does
> it stay private to the bundle using it?  I'm thinking of properties for
> example which might have their own configurations per bundle that one
> doesn't want being exported to the world.

The @ApplicationScoped scope does not mean the bean gets exported into the OSGi 
service registry. In that case, it’s the Camel registry that is specifically 
wrapped in OSGi environments so that Camel components get exported to and can 
be looked up from the OSGi service registry.

So the CDI beans are within the scope of the bundle, as there is one CDI 
container started per bundle which requires the CDI capability.
 
> If I have an interface like PaypalService and then a concrete
> implementation of that called PayPalImpl, would this work to export the
> service to the OSGi service registry?
> 
>@Produces
>@Named("paypal")
>@ApplicationScoped
> PayPal paypal() {
> //Disregarding any special setup...
>  return new PayPalImpl();
> }

It won’t be exported in the OSGi service registry.

> Or would that PayPalImpl have to extend a CamelComponent to get that
> behaviour?

To get the PayPal service exported in the OSGi service registry, you could rely 
on the @OsgiServiceProvider qualifier that’s provided by the PAX CDI API 
(https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-cdi-api/src/main/java/org/ops4j/pax/cdi/api).

Antonin

Re: Camel CDI

[Antonin Stefanutti]

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 the objective here was 
to prove technically the portability of "plain" Camel CDI applications on OSGi. 
The main outcome has been captured in [2], which highlights the difficulty to 
make the CDI implementations subclass proxying mechanism working seamlessly in 
a class loader constrained environment such as OSGi. 

Then, from the functional standpoint, Guillaume Nodet has been working lately 
on improving the SCR-like annotation support [3]. Though I haven’t found the 
time yet to test it with Camel CDI in particular.

[1]: 
https://github.com/astefanutti/camel-cdi/tree/master/envs/osgi/src/test/java/org/apache/camel/cdi/osgi
[2]: https://github.com/ops4j/org.ops4j.pax.cdi/pull/30
[3]: 
https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-cdi-api/src/main/java/org/ops4j/pax/cdi/api

Antonin

> On 22 Aug 2016, at 16:33, Brad Johnson  wrote:
> 
> Has anyone used Camel CDI in an OSGi environment?  Does it work well or at
> least OK there?
> 
> Brad

Re: CDI - Having 2 contexts within the same JVM

[Antonin Stefanutti]

Hi Rajith,

> On 10 Aug 2016, at 16:54, Rajith Muditha Attapattu  wrote:
> 
> Another worry I have is how to do transactions.
> If I'm not mistaken, Spring is the preferred transaction mechanism.

Some Camel components, like Spring JMS or the transactional error handler are 
tightly coupled to Spring TX as they rely on the platform transaction manager. 
That being said, that doesn’t prevent from using CDI and have CDI + JTA + 
Spring TX integrate nicely.

You can find a quick example here:

http://camel.apache.org/cdi.html#CDI-ReferringbeansfromEndpointURIs

I still have to contribute a full-fledged example...

Antonin

> On Wed, Aug 10, 2016 at 10:32 AM, Brad Johnson > wrote:
> 
>> Part of the reason I asked that question is that if you are using blueprint
>> you start your route builder in the context in the XML file.  Spring is
>> similar.  CDI requires the annotation help and I haven't used it before
>> 2.17 so I'm not sure how ready for primetime it was before.
>> 
>> 
>> 
>> 
>> 
>> http://camel.apache.org/schema/blueprint";>
>> 
>> 
>> 
>> On 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, 2016 at 4:18 AM, Antonin Stefanutti <
>> anto...@stefanutti.fr>
>>> wrote:
>>> 
>>>> 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 would use the provided @ContextName qualifier to do the
>>>> binding though you can use your own qualifiers if needed.
>>>> 
>>>> As Brad mentioned, you may want to precise / check the Camel version
>>>> you’re using. Indeed, multiple Camel context support has been greatly
>>>> improved since Camel 2.17.0. You may be able to use it before that but
>>> not
>>>> all the typical use cases will work.
>>>> 
>>>> Let us know if that helps.
>>>> 
>>>> Antonin
>>>> 
>>>>> On 08 Aug 2016, at 20:48, Brad Johnson >> 
>>>> wrote:
>>>>> 
>>>>> Which framework and version of Camel are you using?
>>>>> 
>>>>> On Mon, Aug 8, 2016 at 1:47 PM, Rajith Muditha Attapattu <
>>>> rajit...@gmail.com
>>>>>> wrote:
>>>>> 
>>>>>> Hey All,
>>>>>> 
>>>>>> Within the same JVM, there will be two camel contexts.
>>>>>> How do I mark a particular RouteBuilder to say it belongs to
>> Context1
>>> vs
>>>>>> Context2 ?
>>>>>> 
>>>>>> Is this even possible ?
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Rajith Muditha Attapattu <http://rajith.2rlabs.com/>
>>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> 
>>> Rajith Muditha Attapattu <http://rajith.2rlabs.com/>
>>> 
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Rajith Muditha Attapattu <http://rajith.2rlabs.com/>

Re: Loading all beans before the Camel Context starts

[Antonin Stefanutti]

Hi Rajith,

> On 10 Aug 2016, at 21:00, Rajith Muditha Attapattu  wrote:
> 
> I'm using Camel 2.15 bcos thats the version coming Fuse 6.2.1
> But my understanding is that CDI events are not supported until 2.17

Your understanding is correct. This will be available in Fuse 6.3 which is 
expected to be released soon.

> What's the drawback of overriding start() ?

Assuming you can use the observer method, I find it more straightforward and 
explicit that customising and overriding the default Camel context bean. Though 
that’s a matter of style.

Antonin

> On 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 CamelContextStartingEvent
>> event, MyBean bean) {
>>bean.init();
>> }
>> 
>> Either method argument or class field injection will work. And that avoids
>> having to override the start method on the context.
>> 
>> You can find more information in: http://camel.apache.org/cdi.html#CDI-
>> CameleventstoCDIevents
>> 
>> Antonin
>> 
>>> On 10 Aug 2016, at 19:48, Rajith Muditha Attapattu 
>> wrote:
>>> 
>>> I'm using CDI and want to make sure all my beans are loaded before the
>>> context and properly initialized.
>>> 
>>> I have them as attributes in my CamelContext class with @Inject.
>>> 
>>> However I override the start method in the context to make sure I call
>> the
>>> various initi methods for those beans to make sure they are loaded and
>>> ready when the routes start.
>>> 
>>> @Override
>>> public void start() throws Exception{
>>>  myBean1.init();
>>>  myBean2.init().
>>>  super.start();
>>> }
>>> 
>>> Is this advisable ? is there a better way to do this ?
>>> 
>>> Regards,
>>> 
>>> Rajith Muditha Attapattu <http://rajith.2rlabs.com/>
>> 
>> 
> 
> 
> -- 
> Regards,
> 
> Rajith Muditha Attapattu <http://rajith.2rlabs.com/>

Re: Loading all beans before the Camel Context starts

[Antonin Stefanutti]

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 will work. And that avoids 
having to override the start method on the context.

You can find more information in: 
http://camel.apache.org/cdi.html#CDI-CameleventstoCDIevents

Antonin

> On 10 Aug 2016, at 19:48, Rajith Muditha Attapattu  wrote:
> 
> I'm using CDI and want to make sure all my beans are loaded before the
> context and properly initialized.
> 
> I have them as attributes in my CamelContext class with @Inject.
> 
> However I override the start method in the context to make sure I call the
> various initi methods for those beans to make sure they are loaded and
> ready when the routes start.
> 
> @Override
> public void start() throws Exception{
>   myBean1.init();
>   myBean2.init().
>   super.start();
> }
> 
> Is this advisable ? is there a better way to do this ?
> 
> Regards,
> 
> Rajith Muditha Attapattu 

Re: CDI before Camel 2.17?

[Antonin Stefanutti]

Hi Brad,

If you’re interested in OSGi and CDI, you may want to check PAX CDI 
https://github.com/ops4j/org.ops4j.pax.cdi.

There is an example available on how to use it with Camel here: 
https://github.com/apache/camel/tree/master/examples/camel-example-cdi-osgi

Antonin

> On 08 Aug 2016, at 15:23, Brad Johnson  wrote:
> 
> Excellent. That's pretty much what I'm looking for since I recognize it is
> a matter of evolving toward that and not needing to jump into it whole hog.
> 
> I can probably live with CamelTestSupport with out the CDI runner for the
> time being as well.  Part of the problem is the underlying mechanisms
> aren't obvious to me since I've been using Spring and then Blueprint for so
> long and I've  pretty much always gone with hand wiring of internals.
> 
> I'm not sure where the future is going with Blueprint, DS, SCR, CDI, Spring
> Boot, Delta Spike, etc. but the Camel RouteBuilder will be germane in all
> situations and for now I'm using Blueprint for very basic bootstrap.
> 
> While I commonly use OSGi services and export and reference them from my
> bundles, to be honest I could live without them if necessary.  I mean the
> great benefit for me in using OSGi with Camel is the classloader
> segregation and ability to hide internal classes in a bundle.  But I can
> always run routes between bundles to accomplish much the same thing that
> service provide 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.*) 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.17.0 managed to be largely backward
>> compatible, these should work in prior versions with some little adaptation.
>> 
>> You can find some more details about these non backward compatible changes
>> in https://issues.apache.org/jira/browse/CAMEL-9201 and
>> http://camel.apache.org/camel-2170-release.html.
>> 
>> For testing, Camel CDI test won't be available, though you can use plain
>> Arquillian testing support. You can find more info in
>> http://camel.apache.org/cdi-testing.html.
>> 
>> If that’s not enough for you to wait until Camel 2.17 / Fuse 6.3, let me
>> know and we’ll try to help you further.
>> 
>> Antonin
>> 
>>> On 06 Aug 2016, at 00:30, Brad Johnson 
>> wrote:
>>> 
>>> Are there any good examples of how to use CDI with Camel before 2.17?
>>> Obviously that's a better option to go with and when the Fuse 6.3 release
>>> hits it's first milestone that's what I'll go to but until then I can use
>>> Camel 2.17 CDI test but have to use the older features with Fuse 6.2.1.
>>> 
>>> Unless there's a patch or upgrade that does this already?
>>> 
>>> Brad
>> 
>> 

Re: CDI - Having 2 contexts within the same JVM

[Antonin Stefanutti]

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 
would use the provided @ContextName qualifier to do the binding though you can 
use your own qualifiers if needed.

As Brad mentioned, you may want to precise / check the Camel version you’re 
using. Indeed, multiple Camel context support has been greatly improved since 
Camel 2.17.0. You may be able to use it before that but not all the typical use 
cases will work.

Let us know if that helps.

Antonin

> On 08 Aug 2016, at 20:48, Brad Johnson  wrote:
> 
> Which framework and version of Camel are you using?
> 
> On Mon, Aug 8, 2016 at 1:47 PM, Rajith Muditha Attapattu > wrote:
> 
>> Hey All,
>> 
>> Within the same JVM, there will be two camel contexts.
>> How do I mark a particular RouteBuilder to say it belongs to Context1 vs
>> Context2 ?
>> 
>> Is this even possible ?
>> 
>> Regards,
>> 
>> Rajith Muditha Attapattu 
>> 

Re: Camel JPA + JTA Transaction (TomEE)

[Antonin Stefanutti]

Hi Dimitri,

Thanks a lot for your feedback.

I’m planning to work on a Camel CDI example that would cover Camel JMS and JTA. 
I’ll try to extend it to cover Camel JPA or to have a dedicated Camel CDI 
example for it as well.

Meanwhile, you may want to contribute, if you think you have something generic 
enough to share, that’d be awesome! http://camel.apache.org/contributing.html

Keep in touch,

Antonin

> On 06 Aug 2016, at 22:25, Shultz, Dmitry  wrote:
> 
> I like the CDI way of doing DI, so I decided to dump the JPA  Camel component.
> 
> Ended up using beanRef invoking CDI Bean with injected EntityManager (for 
> RESOURCE_LOCAL datas source). Had to begin/commit transaction manually) and 
> it works.
> 
> It would be nice if Deltaspike JPA module ca help here (@Transactional 
> doesn't seem to be doing anything), but it's manageable so far.
> 
> 
> Cheers,
> 
> Dmitry
> 
> 
> From: Romain Manni-Bucau 
> Sent: 05 August 2016 23:53:16
> To: users@camel.apache.org
> Subject: RE: Camel JPA + JTA Transaction (TomEE)
> 
> Le 6 août 2016 02:22, "Shultz, Dmitry"  a écrit :
>> 
>> Can't set the org.apache.camel.cdi.CdiCamelExtension.active=false in
> conf/system.properties because there will be other apps deployed on the
> same TomEE and they have no problems  (because they don't use any Camel
> JPA).
>> Also can't override the afterDeploymentValidation() because it is
> private, in fact all the methods in org.apache.camel.cdi.CdiCamelExtension
> class are private except of default Constructor - very well encapsulated...
> may be a bit too well.
>> 
> 
> WEB-INF/application.properties can hold it within the app too
> 
>> While I'm working on the github project to reproduce the issue, I need to
> deploy something working into our environment (i.e. something that can be
> restarted), so I decided to try not to use RESOURCE_LOCAL instead of JTA
> data source. It fails on :
>> 
>> 17:15| ERROR | CamelLogger.java 156 |
> javax.persistence.TransactionRequiredException: no transaction is in
> progress
>>at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:993)
>>at
> org.apache.camel.component.jpa.JpaProducer$1.doInTransaction(JpaProducer.java:99)
>>at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
>>at
> org.apache.camel.component.jpa.JpaProducer.process(JpaProducer.java:62)
>>at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>>at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145)
>> 
>> How do I create transaction manually for JPA Camel?
>> 
>> 
> 
> Think you have to rely on spring.
> 
> That said a workaround for your app would be to use reflection - or add
> openejb-core as provided in your pom - and get the txmgr doing
> OpenEJB.getTransactionManager().
> 
>> 
>> -Original Message-
>> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
>> Sent: August-05-16 1:57 PM
>> To: users@camel.apache.org
>> Subject: RE: Camel JPA + JTA Transaction (TomEE)
>> 
>> org.apache.camel.cdi.CdiCamelExtension.active=false in
> conf/system.properties then redefine this extension - likely extend camel
> one to override afterDeploymentValidation and dont forget to register it
> through standard SPI file.
>> 
>> Thinking to it using a servletcontextlistener if in a servlet container
> can be a better way to init 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()
>> kicks up the Camel validation befiore TomEE is fully initialized. If
> there any way to disable this (or call validation manually later)?
>> 
>> -Original Message-
>> From: Antonin Stefanutti [mailto:anto...@stefanutti.fr]
>> Sent: August-05-16 11:48 AM
>> To: users@camel.apache.org
>> Subject: Re: Camel JPA + JTA Transaction (TomEE)
>> 
>> 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:
>>> 
>>> try sharing a sample with th

Re: CDI before Camel 2.17?

[Antonin Stefanutti]

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.17.0 managed to be largely backward compatible, 
these should work in prior versions with some little adaptation.

You can find some more details about these non backward compatible changes in 
https://issues.apache.org/jira/browse/CAMEL-9201 and 
http://camel.apache.org/camel-2170-release.html.

For testing, Camel CDI test won't be available, though you can use plain 
Arquillian testing support. You can find more info in 
http://camel.apache.org/cdi-testing.html.

If that’s not enough for you to wait until Camel 2.17 / Fuse 6.3, let me know 
and we’ll try to help you further.

Antonin

> On 06 Aug 2016, at 00:30, Brad Johnson  wrote:
> 
> Are there any good examples of how to use CDI with Camel before 2.17?
> Obviously that's a better option to go with and when the Fuse 6.3 release
> hits it's first milestone that's what I'll go to but until then I can use
> Camel 2.17 CDI test but have to use the older features with Fuse 6.2.1.
> 
> Unless there's a patch or upgrade that does this already?
> 
> Brad

Re: Camel JPA + JTA Transaction (TomEE)

[Antonin Stefanutti]

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:
> 
> try sharing a sample with this issue on github with tomee-maven-plugin
> setup to reproduce it (mvn package tomee:run -> fails). Would be more
> relevant than guessing the actual issue.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
> 
> 2016-08-05 20:06 GMT+02:00 dimas :
> 
>> Tried that, doesn't work. CDI is starting CamelContext even with
>> context.setAutoStartup(false).
>> 
>> SEVERE - Failed to create Producer for endpoint:
>> Endpoint[jpa://com.kaltire.mix.wosess.model.ScanEvent]. Reason:
>> javax.persistence.PersistenceException: No persistence providers available
>> for "camel" after trying the following discovered implementations:
>> org.apache.openjpa.persistence.PersistenceProviderImpl,
>> org.hibernate.ejb.HibernatePersistence
>> org.apache.camel.FailedToCreateProducerException: Failed to create
>> Producer
>> for endpoint: Endpoint[jpa://com.kaltire.mix.wosess.model.ScanEvent].
>> Reason: javax.persistence.PersistenceException: No persistence providers
>> available for "camel" after trying the following discovered
>> implementations:
>> org.apache.openjpa.persistence.PersistenceProviderImpl,
>> org.hibernate.ejb.HibernatePersistence
>>at
>> org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:444)
>>at
>> org.apache.camel.impl.ProducerCache.acquireProducer(
>> ProducerCache.java:160)
>>at org.apache.camel.processor.SendProcessor.doStart(
>> SendProcessor.java:243)
>>at org.apache.camel.support.ServiceSupport.start(
>> ServiceSupport.java:61)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:75)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:60)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startServices(
>> ServiceHelper.java:90)
>>at
>> org.apache.camel.processor.DelegateAsyncProcessor.doStart(
>> DelegateAsyncProcessor.java:79)
>>at org.apache.camel.support.ServiceSupport.start(
>> ServiceSupport.java:61)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:75)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:60)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startServices(
>> ServiceHelper.java:90)
>>at
>> org.apache.camel.processor.RedeliveryErrorHandler.doStart(
>> RedeliveryErrorHandler.java:1372)
>>at
>> org.apache.camel.support.ChildServiceSupport.start(
>> ChildServiceSupport.java:44)
>>at
>> org.apache.camel.support.ChildServiceSupport.start(
>> ChildServiceSupport.java:31)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:75)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:60)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startServices(
>> ServiceHelper.java:90)
>>at
>> org.apache.camel.processor.interceptor.DefaultChannel.
>> doStart(DefaultChannel.java:156)
>>at org.apache.camel.support.ServiceSupport.start(
>> ServiceSupport.java:61)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:75)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:60)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:62)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startServices(
>> ServiceHelper.java:90)
>>at
>> org.apache.camel.processor.MulticastProcessor.doStart(
>> MulticastProcessor.java:1149)
>>at org.apache.camel.support.ServiceSupport.start(
>> ServiceSupport.java:61)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:75)
>>at org.apache.camel.util.ServiceHelper.startService(
>> ServiceHelper.java:60)
>>at
>> org.apache.camel.util.ServiceHelper.startServices(ServiceHelper.java:104)
>>at org.apache.camel.util.ServiceHelper.startS

Re: Camel JPA + JTA Transaction (TomEE)

[Antonin Stefanutti]

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("jtaTransactionManager")
PlatformTransactionManager createTransactionManager(TransactionManager 
transactionManager, UserTransaction userTransaction) {
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransaction(userTransaction);
jtaTransactionManager.setTransactionManager(transactionManager);
jtaTransactionManager.afterPropertiesSet();
return jtaTransactionManager;
}

And reference it from your camel routes with the # notation, e.g.:

from("jms:queue:{{destination}}?transacted=true&transactionManager=#jtaTransactionManager").to("...");

In a typical JTA enabled application server, you can retrieve the 
TransactionManager and UserTransaction as resources to be used to produce the 
named PlatformTransactionManager, e.g.:

@Resource(lookup = "java:jboss/TransactionManager”) 
TransactionManager transactionManager; 

@Resource 
UserTransaction userTransaction; 

@Produces
@Named("jtaTransactionManager")
PlatformTransactionManager createTransactionManager() {
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransaction(userTransaction);
jtaTransactionManager.setTransactionManager(transactionManager);
jtaTransactionManager.afterPropertiesSet();
return jtaTransactionManager;
}

Hope this helps.

Antonin

> On 29 Jul 2016, at 17:57, dimas  wrote:
> 
> Hi All,
> 
> I'm using TomEE (7.0.0) + Camel JMS + Camel CDI + Camel JPA  to receive and
> store messages in the DB. Camel version is 2.17.2.
> 
> Out of the box, Camel JPA is failing because it is trying to access the
> EntityTransaction of TomEE. 
> 
> 08:36| ERROR | CamelLogger.java 156 |  nonfatal user error> org.apache.openjpa.persistence.InvalidStateException:
> You cannot access the EntityTransaction when using managed transactions.
>   at
> org.apache.openjpa.persistence.EntityManagerImpl.getTransaction(EntityManagerImpl.java:553)
>   at
> org.apache.openjpa.persistence.EntityManagerImpl.getTransaction(EntityManagerImpl.java:103)
>   at
> org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67)
>   at
> org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380)
>   at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373)
>   at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
>   at 
> org.apache.camel.component.jpa.JpaProducer.process(JpaProducer.java:62)
>   at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> 
> 
> In the 'transactionManeger' description column of Camel JPA doc
> (http://camel.apache.org/jpa.html) there is some info about the ability to
> set up JTA Transaction Manger 'Can be used to set a JTA transaction manager
> (for integration with an EJB container).', but it's not clear how to do it
> exactly.
> 
> I tried to use the doc page of Camel CDI (http://camel.apache.org/cdi.html),
> the 'Referring beans from Endpoint URIs' section where it says that
> following code should be used:
> 
> @Produces
> @Named("jtaTransactionManager")
> PlatformTransactionManager createTransactionManager(TransactionManager
> transactionManager, UserTransaction userTransaction) {
>JtaTransactionManager jtaTransactionManager = new
> JtaTransactionManager();
>jtaTransactionManager.setUserTransaction(userTransaction);
>jtaTransactionManager.setTransactionManager(transactionManager);
>jtaTransactionManager.afterPropertiesSet();
>return jtaTransactionManager;
> }
> 
> And I'm using it in my route like this:
> 
> .to("jpa://com.some.Event?transactionManager=#jtaTransactionManager");
> 
> But if fails:
> 
> Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: Api type
> [javax.transaction.TransactionManager] is not found with the qualifiers 
> Qualifiers: [@javax.enterprise.inject.Default()]
> for injection into Method Injection Point, method name : 
> createTransactionManager, Bean Owner : [PlatformTransactionManager,
> WebBeansType:PRODUCERMETHOD, Name:jtaTransactionManager, API
> Types:[java.lang.Object,org.springframework.transaction.PlatformTransactionManager],
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]]
>   at
> org.apache.webbeans.util.InjectionExceptionUtil.throwUnsatisfiedResolutionException(InjectionExceptionUtil.java:65)
>   at
> org.apache.webbeans.container.InjectionResolver.checkInjectionPoint(InjectionResolver.java

Re: RuntimeCamelException:IllegalStateException:Unablefind BeanManager.Please ensure config CDI

[Antonin Stefanutti]

> 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 BeanManagerProvider while it should not [1].

Unfortunately BeanManagerProvider relies on ThreadLocal and static state that 
makes it hard to troubleshoot issues as the one you face.

If you cannot upgrade Camel, my best advise would be at least trying to use the 
camel-cdi JAR from Camel 2.17.0 by doing the adaptation to camel-core 2.12, 
which should be small. Otherwise, you’ll need to investigate further and gets 
into the BeanManagerProvider internals.

Antonin

[1]: https://issues.apache.org/jira/browse/CAMEL-6338


> But I looked at 2.17 camel patch
> and its fixes. Its targeted for many CDI BeanManager Component loading
> issues which covers one this issue.
> https://issues.apache.org/jira/browse/CAMEL-9201
> 
> We are using 2.12 and don't have any sooner plan to upgrade it 2.17 as its
> being used and part of large integration system.
> Is there any other work around instead of upgrading camel version?
> 
> One of the big challenge for us reproducing this issue, as it happened for 1
> day and goes off after jboss restart. I believed, as we have context
> clear/destroy might helped.
> 
>@PreDestroy
>private void OnCloseTest() throws Exception {
>ctx.getContext().stop();
>}
> 
> 
> Thanks again for your help. Appreciated. 
> 
> regards,
> Vishal
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/RuntimeCamelException-java-lang-IllegalStateException-Unable-to-find-BeanManager-Please-ensure-that-y-tp5784059p5784096.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: RuntimeCamelException:IllegalStateException:Unablefind BeanManager.Please ensure config CDI

[Antonin Stefanutti]

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, saysvishal  wrote:
> 
> Error- Unable to find BeanManager. Please ensure that you configured the CDI
> implementation of your choice properly. I am getting this error while
> running one of the job route name TestAccount job. On start up.. CDI manager
> is getting loaded and DI context is added to route, snipped as follows,
> 
> CreationalContext createCtx = beanManager.createCreationalContext(bean);
>JobRouter job = (JobRouter) beanManager.getReference(bean,
> JobRouter.class, createCtx);
>RouteBuilder routeToAdd = (RouteBuilder)
> beanManager.getReference(bean, RouteBuilder.class, createCtx);
>log.info("jobName: "+job.getJobName());
> Server is restarted 30 days before.. TestAccount job is scheduled every 2 hr
> to run. But the issue is happening since two day.. and its happening only
> for few occurrences.. say e.g. out of last 4 jobs.. 3 are not-successful and
> 1 is successful.
> 
> Complete stack trace as follows,
> 
> -
> 
> org.apache.camel.RuntimeCamelException:
>   java.lang.IllegalStateException: Unable to find BeanManager. Please
>   ensure that you configured the CDI implementation of your choice
>   properly.  at
> 
> org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1363)
>   at
> 
> org.apache.camel.impl.PropertyPlaceholderDelegateRegistry.lookupByNameAndType(PropertyPlaceholderDelegateRegistry.java:65)
>   at
> 
> org.apache.camel.component.bean.BeanInfo.createParameterMappingStrategy(BeanInfo.java:169)
>   at org.apache.camel.component.bean.BeanInfo.(BeanInfo.java:92) 
>   at
> 
> org.apache.camel.component.bean.ConstantBeanHolder.(ConstantBeanHolder.java:44)
>   at
> 
> org.apache.camel.model.language.MethodCallExpression.createExpression(MethodCallExpression.java:177)
>   at
> 
> org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:118)
> 
>   Caused by: java.lang.IllegalStateException: Unable to find
>   BeanManager. Please ensure that you configured the CDI implementation
>   of your choice properly.
> Please let me know if you need any other help. Any kind of help is
> appreciated
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/RuntimeCamelException-IllegalStateException-Unablefind-BeanManager-Please-ensure-config-CDI-tp5784059.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Came CDI tests start non-test routes

[Antonin Stefanutti]

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 have your application routes (non-test routes) not started 
by default, one alternative is to customise the Camel context by setting the 
autoStartup property to false, e.g.:


@ApplicationScoped
public class ManualStartupCamelContext extends DefaultCamelContext {

@PostConstruct
void postConstruct() {
setAutoStartup(false);
}
}

If your need is to be able to perform some testing logic before the routes have 
started in your test class, to add some advices for example, you could declare 
an observer method in your test class for the CamelContextStartingEvent, e.g.:

void advice(@Observes CamelContextStartingEvent event, ModelCamelContext 
context) throws Exception {
context.getRouteDefinition("route")
.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() {
weaveAddLast().to("mock:messages");
}
});
}

So that depends on what exactly is your need for not having your application 
routes started.

Let me know if that does not meet your need.

Antonin

> On 31 May 2016, at 20:07, Anton  wrote:
> 
> Hello
> 
> I have several unit tests that are annotated
> with @RunWith(org.apache.camel.test.cdi.CamelCdiRunner.class) and also
> inject
> 
> @Inject
> @ContextName("camel-test-cdi")
> CamelContext context;
> 
> I do not inject any non-test routes, yet, when I run the tests the routes
> start.
> 
> How is it possible to run the tests without the non test routes from
> starting?
> 
> Thanks

Re: Camel delta-spike: How to share properties between conexts ?

[Antonin Stefanutti]

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
>  @ConfigProperty(name = "ftp.path")
>  private static String myProp;

Re: Camel delta-spike: How to share properties between conexts ?

[Antonin Stefanutti]

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]: 
https://github.com/apache/camel/tree/master/examples/camel-example-cdi-properties
[2]: http://camel.apache.org/cdi-testing.html#CDITesting-CamelCDITest

Antonin

> On 31 May 2016, at 12:01, nicolasduminil 
>  wrote:
> 
> Hello,
> 
> I'm using delta-spike to manage camel routes as I've seen in the provided
> CDI samples. I have the following route builder:
> 
> public class MyRouteBuilder extends RouteBuilder
> {
>  @Override
>  @ContextName("...")
>  public void configure()
>  {
>from("ftp:{{ftp.path}}").log("Uploading file
> ${file:name}").to("file:{{file.path}}").log("Uploaded file ${file:name}
> complete.");
>  }
> 
>  @Produces
>  @Named("properties")
>  public PropertiesComponent properties(PropertiesParser parser)
>  {
>PropertiesComponent component = new PropertiesComponent();
>component.setPropertiesParser(parser);
>return component;
>  }
> }
> 
> and I have the following class:
> 
> public class DeltaSpikeParser extends DefaultPropertiesParser {
>  @Override
>  public String parseProperty(String key, String value, Properties
> properties) {
>return ConfigResolver.getPropertyValue(key);
>  }
> }
> 
> The {{...}} get injected from the apache-deltaspike.properties file.
> 
> In my unit tests I need to use the same property file, for example:
> 
> public class UnitTests extends CamelTestSupport
> {
>  @Override
>  protected RouteBuilder createRouteBuilder()
>  {
>return new RouteBuilder()
>{
>  public void configure()
>  {
>from("direct:start").to("ftp:{{ftp.path}}");
>  }
>};
>  }
> 
> But here {{ftp.path}} is not defined any more. How could i do this ?
> 
> Many thanks in advance,
> 
> Nicolas
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-delta-spike-How-to-share-properties-between-conexts-tp5783288.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to run camel-cdi projects ?

[Antonin Stefanutti]

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();
>cdiContainer.boot();
>ContextControl contextControl = cdiContainer.getContextControl();
>contextControl.startContext(ApplicationScoped.class);
>/*
> * Your code here 
> */
> 
> But I'm not sure what the code is supposed to do once the container and the
> context started. In my case, the Camel route starts but it stops immediately
> because the JVM exits. I don't know how to tell to the container to run for
> ever.

You have to block the main thread, one way or another, otherwise the JVM exits 
as all the non-daemon threads have returned / died. An alternative to is to use 
Camel Main support (which I realise I forgot to mention) that relies on 
DeltaSpike [2] and that does the blocking for you and register a shutdown hook 
by default. So you can use the org.apache.camel.cdi.Main class which is part of 
the camel-cdi component.

> I have tried also to create an uber jar using the shade maven plugin but I
> cannot run it with java -jar as there is no any main().

You could try using the Main class provided by camel-cdi.

> So I would be very grateful if you could enlighten me. Many thanks in
> advance.

Let us know if you need further help.

> Kind regards,
> 
> Nicolas DUMINIL
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-run-camel-cdi-projects-tp5781727p5782448.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to use cdi annotation to reference shared netty server in karaf?

[Antonin Stefanutti]

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("sharedNettyHttpServer")
  private NettySharedHttpServer server() {
return server;
  }

  @Override 
  public void configure() { 

restConfiguration().component("netty4-http").endpointProperty("nettySharedHttpServer",
 "#sharedNettyHttpServer"); 
rest("/say").get("/hello").to("mock:hello"); 
  }
}

That’d be the equivalent of the declaration in blueprint hereafter:

 https://github.com/apache/camel/blob/62ac1a9ef9c8f61754de2450303023ee165edabf/examples/camel-example-netty-http/myapp-cdi/src/main/java/org/apache/camel/example/netty/cdi/NettyHttpRoute.java#L31-L39

And tested it successfully with Camel 2.17.0 and Karaf 2.4.4.

Let us know if you need further assistance.

Antonin

> On 05 May 2016, at 18:13, leon  wrote:
> 
> Hi guys,
> 
> I just followed this example
> (http://camel.apache.org/netty-http-server-example.html) and successfully
> deployed a shared netty http server to apache karaf. But I could not figure
> out how to reference this shared netty http server in my Rest Java DSL route
> file. Here is my route file:
> 
> import javax.inject.Inject;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.cdi.ContextName;
> import org.apache.camel.component.netty4.http.NettySharedHttpServer;
> import org.ops4j.pax.cdi.api.OsgiService;
> 
> @ContextName("sample")
> public class SampleRoute extends RouteBuilder {
> 
>  @Inject @OsgiService
>  private NettySharedHttpServer server;
> 
>  @Override
>  public void configure() {
> 
> restConfiguration().component("netty4-http").endpointProperty("nettySharedHttpServer",
> "#WHAT_IS_THIS_ID");
>rest("/say").get("/hello").to("mock:hello");
>  }
> 
> }
> 
> I wonder to know if I inject netty shared http server into my route file
> like above sample code instead of using OSGi blueprint, what is the id of
> netty shared http server? Must I use blueprint xml configuration file? Could
> someone shed some light on this please? Thanks in advance!
> 
> Leon
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-use-cdi-annotation-to-reference-shared-netty-server-in-karaf-tp5782250.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel 2.17, @Producer works only for select objects ?

[Antonin Stefanutti]

> 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 of those beans are requested.

This works for the PropertiesComponent because the Camel context requests an 
instance of that bean at start time.

So in your example, where is the @Named("not-prop1") bean actually used? If it 
is reference in a Camel route, then it’ll be called when the route starts.

> -- Is it normal that the method return null? 
> It's only a test, wanna see if ' 'System.out.println("Not Properties")'
> works.
> 
> So there is a limitation, only referenced object can be produced.

That is the way CDI works. Beans are lazy instantiated, hence @Produces methods 
are called only if the beans need to be instantiated.

> Wy this limitation, e need to produce auxiliary beans for processing.
> 
> How can i make My Bean reference ?

There are ways to have beans eagerly instantiated, though that’s more a CDI 
question than a Camel question.

Maybe you could share your Camel CDI example so that we can help further.

Antonin

> -
> kh
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-2-17-Producer-works-only-for-select-objects-tp5782226p5782265.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel 2.17, @Producer works only for select objects ?

[Antonin Stefanutti]

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? Is it normal that the method return null? Note that the 
producer method will actually be invoked only if a reference to it is needed, 
for example if a Camel route refers to it.

Antonin

> On 05 May 2016, at 14:07, kalber  wrote:
> 
> Hi,
> 
> i'm trying to create managed beans with @Producer, but only for
> PropertiesComponent
> works. In the example below method prodceProperties works,  produceConfig
> not.
> 
> Is there a limitation under camel for @Producer ?
> 
> 
> @ApplicationScoped
> public class TestProducer {
> 
>@Produces
>@Named("prop")
>public PropertiesComponent produceProperties() {
>System.out.println("Produces Properties");
>return null;
>}
> 
>@Produces
>@Named("not-prop1")
>public MyBean produceConfig() {
>System.out.println("Not Properties");
>return null;
>}
> 
> }
> 
> 
> 
> -
> kh
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-2-17-Producer-works-only-for-select-objects-tp5782226.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to run camel-cdi projects ?

[Antonin Stefanutti]

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 way to bootstrap a CDI 
container in Java SE [3].

So in production, you could use one of the above options (CDI 2.0 is still a 
draft though), wrapping them in a script is necessary, and rely on the 
discovery mechanism provided by the container to scan bean archives in the 
classpath. You may want to create fat JARs if that ease your deployment though 
that’s not necessary and may not be currently well supported by the 
implementations out-of-the-box.

I’ll update the Camel CDI examples to provide an example.

[1]: 
https://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_bootstrapping_cdi_se
[2]: https://deltaspike.apache.org/documentation/container-control.html
[3]: https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#bootstrap-se

Antonin

> On 26 Apr 2016, at 16:36, nicolasduminil 
>  wrote:
> 
> Hello,
> 
> Using at several camel-cdi examples, they are all supposed to be ran with
> camel:run plugin. Which is okay but how things are supposed to happen in
> production, where using maven is often not an option ? Should one create fat
> runnable run-with-dependencies or is there any other option ?
> 
> I have to mention that I'm talking about Java SE projects.
> 
> Many thanks in advance,
> 
> Nicolas DUMINIL
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-run-camel-cdi-projects-tp5781727.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: java.lang.IllegalArgumentException: Cannot add component as its already previously added: jms

[Antonin Stefanutti]

> 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 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 
>> JmsComponentFactory or declare the producer method static.
>> 
> 
> Yeah that is a good idea to keep those @produces separated from routes
> and etc (eg their clients). I guess its a habit of coming up with a
> good naming for those factory classes. Do you create 1 class per kind,
> or have more in the same class? or a mix?

I would tend to create one class per kind, for example for JMS typically 
something like:

class JmsComponentFactory {

// Connection factory resource (from JNDI for example)
@Resource(mappedName = "jndi.connectionFactoryName")
private ConnectionFactory connectionFactory;

@Produces
@Named("jms")
@ApplicationScoped
// Some external configuration parameters
Component produceJmsComponent(@ConfigProperty(name = "jms.consumers") 
String inputQueueConcurrentConsumers) {
CachingConnectionFactory cachingConnectionFactory = new 
CachingConnectionFactory(connectionFactory);

cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(consumers));
return JmsComponent.jmsComponent(cachingConnectionFactory);
}

// Don’t forget to close the connections
void disposeJmsComponent(@Disposes @Named("jms") Component component) {
((SingleConnectionFactory) 
component.getConfiguration().getConnectionFactory()).destroy();
}
}

I’m planning to add a JMS / CDI example :)

>> Antonin
>> 
>>> On 25 Apr 2016, at 14:46, nicolasduminil 
>>>  wrote:
>>> 
>>> Hi Claus,
>>> 
>>> Many thanks for your suggestion. Now the code looks as follows:
>>> 
>>> public class MyRoutes extends RouteBuilder {
>>> @Inject
>>> @Uri("file:data/inbox?noop=true")
>>> private Endpoint inputEndpoint;
>>> 
>>> @Inject
>>> @Uri("jms:incommingData")
>>> private Endpoint resultEndpoint;
>>> 
>>> @Produces
>>> @Named("jms")
>>> public Component jmsComponent()
>>> {
>>>   ConnectionFactory connectionFactory = new
>>> ActiveMQConnectionFactory("tcp://cac40:61616?create=false");
>>>   return JmsComponent.jmsComponentAutoAcknowledge(connectionFactory);
>>> }
>>> 
>>> @Override
>>> public void configure() {
>>>   from(inputEndpoint).to("bean:counterBean").to(resultEndpoint);
>>> }
>>> }
>>> 
>>> Running it with camel:run raises the following:
>>> 
>>> [ERROR] Caused by: org.apache.camel.ResolveEndpointFailedException: Failed
>>> to resolve endpoint: jms://incommingData due to: Cannot auto create
>>> component: jms
>>> [ERROR] at
>>> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:588)
>>> [ERROR] at
>>> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:601)
>>> [ERROR] at
>>> org.apache.camel.impl.DefaultCamelContext$Proxy$_$$_WeldClientProxy.getEndpoint(Unknown
>>> Source)
>>> [ERROR] at
>>> org.apache.camel.cdi.CdiCamelFactory.endpoint(CdiCamelFactory.java:119)
>>> [ERROR] ... 65 more
>>> 
>>> Is there anything else I could try. This code was generated by the
>>> maven-camel-jms-cdi archetype.
>>> 
>>> Kind regards,
>>> 
>>> Nicolas DUMINIL
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://camel.465427.n5.nabble.com/java-lang-IllegalArgumentException-Cannot-add-component-as-its-already-previously-added-jms-tp5781607p5781658.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>> 
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: java.lang.IllegalArgumentException: Cannot add component as its already previously added: jms

[Antonin Stefanutti]

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 
JmsComponentFactory or declare the producer method static.

Antonin

> On 25 Apr 2016, at 14:46, nicolasduminil 
>  wrote:
> 
> Hi Claus,
> 
> Many thanks for your suggestion. Now the code looks as follows:
> 
> public class MyRoutes extends RouteBuilder {
>  @Inject
>  @Uri("file:data/inbox?noop=true")
>  private Endpoint inputEndpoint;
> 
>  @Inject
>  @Uri("jms:incommingData")
>  private Endpoint resultEndpoint;
> 
>  @Produces
>  @Named("jms")
>  public Component jmsComponent()
>  {
>ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://cac40:61616?create=false");
>return JmsComponent.jmsComponentAutoAcknowledge(connectionFactory);
>  }
> 
>  @Override
>  public void configure() {
>from(inputEndpoint).to("bean:counterBean").to(resultEndpoint);
>  }
> }
> 
> Running it with camel:run raises the following:
> 
> [ERROR] Caused by: org.apache.camel.ResolveEndpointFailedException: Failed
> to resolve endpoint: jms://incommingData due to: Cannot auto create
> component: jms
> [ERROR] at
> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:588)
> [ERROR] at
> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:601)
> [ERROR] at
> org.apache.camel.impl.DefaultCamelContext$Proxy$_$$_WeldClientProxy.getEndpoint(Unknown
> Source)
> [ERROR] at
> org.apache.camel.cdi.CdiCamelFactory.endpoint(CdiCamelFactory.java:119)
> [ERROR] ... 65 more
> 
> Is there anything else I could try. This code was generated by the
> maven-camel-jms-cdi archetype.
> 
> Kind regards,
> 
> Nicolas DUMINIL
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/java-lang-IllegalArgumentException-Cannot-add-component-as-its-already-previously-added-jms-tp5781607p5781658.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: camel-cdi-test sendBodyAndHeaders not sending headers

[Antonin Stefanutti]

I’ve just tried with the following test class:

@RunWith(CamelCdiRunner.class)
public class MyTest {

@Inject
private CamelContext context;

@Produce(uri = "direct:in")
private ProducerTemplate template;

@Test
public void test() throws Exception {
String xml = "1";
Map headers = Maps.newHashMap();
headers.put("TEST_HEADER", "BLAH");

template.sendBodyAndHeaders(context.getEndpoint("direct:in"), xml, 
headers);
}

static class ContextConfig extends RouteBuilder {

@Override
public void configure() {
from("direct:in")
.log(" Received Message ")
.log("${headers}")
.to("mock:out");
}
}
}

And get the correct headers logged:

2016-04-20 13:01:48,611 [main   ] INFO  Version
- WELD-000900: 2.3.3 (Final)
2016-04-20 13:01:52,986 [main   ] INFO  CdiCamelExtension  
- Camel CDI is starting Camel context [camel-1]
2016-04-20 13:01:52,988 [main   ] INFO  DefaultCamelContext
- Apache Camel  (CamelContext: camel-1) is starting
2016-04-20 13:01:53,685 [main   ] INFO  DefaultCamelContext
- Route: route1 started and consuming from: Endpoint[direct://in]
2016-04-20 13:01:53,685 [main   ] INFO  DefaultCamelContext
- Total 1 routes, of which 1 are started.
2016-04-20 13:01:53,691 [main   ] INFO  DefaultCamelContext
- Apache Camel  (CamelContext: camel-1) started in 0.697 seconds
2016-04-20 13:01:53,786 [main   ] INFO  route1 
-  Received Message 
2016-04-20 13:01:53,790 [main   ] INFO  route1 
- {breadcrumbId=ID-mbp-local-61449-1461150112430-0-1, TEST_HEADER=BLAH}
...

What the URI you’re using for the logEndpoint and what is the exact behaviour 
you’re facing?

Antonin

> On 20 Apr 2016, at 12:45, craigmjones96  wrote:
> 
> Hi,
> 
> I am trying to use camel-cdi-test framework and it is working in all
> scenarios i have needed to test so far. However, now i need to send Headers
> in as part of my message to a route but when i inspect the Exchange as soon
> as it has entered to route (via a logEndpoint) the headers i provided are
> not set.
> 
> @Inject
> private CamelContext context;
> 
> @Produce(uri=RequestHandlerConstants.ROUTE_REQUEST_PREVALIDATION)
> private ProducerTemplate template;
> 
> @Test
> public void test() throws Exception {
>String xml = "1";
>Map headers = Maps.newHashMap();
>headers.put("TEST_HEADER","BLAH");
> 
> template.sendBodyAndHeaders(context.getEndpoint(RequestHandlerConstants.ROUTE_REQUEST_PREVALIDATION),
> xml, headers);
> }
> 
> my route has been simplified for the time being:
> 
> from(RequestHandlerConstants.ROUTE_REQUEST_PREVALIDATION)
>.log(" Received Message ")
>.log("${headers}")
>.to(logEndpoint);
> 
> Is anyone able to offer any assistance? Am i missing something obvious?
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/camel-cdi-test-sendBodyAndHeaders-not-sending-headers-tp5781416.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Clarification on how Converters work with CDI

[Antonin Stefanutti]

> On 13 Apr 2016, at 14:08, Anton  wrote:
> 
> On Wed, Apr 13, 2016 at 1:58 PM, John D. Ament 
> wrote:
> 
>> The JPA component doesn't do any type conversion (based on code
>> inspection).  It assumes the object coming in is the right type.  Good
>> catch on adding the converter to the body.
>> 
> 
> Thanks John
> 
> I think it would be good to have some consistency in regards to whether
> components do conversion or not.
> 
> What is the best way to know if a component supports implicit type
> conversion?

I’d said the documentation ATM. The JPA component doc mentions type conversion 
for the producer but not for the consumer. That being said, I agree it’d be 
better to have a way to have type conversion consistently applied.

Antonin

Re: Clarification on how Converters work with CDI

[Antonin Stefanutti]

Yes, I haven’t checked the code though I guess the JPA component isn’t doing 
the conversion automatically.

Maybe that could be an enhancement to the JPA component.

Antonin

> On 13 Apr 2016, at 13:15, Anton  wrote:
> 
> When I add the following it works
> On Wed, Apr 13, 2016 at 1:04 PM, Antonin Stefanutti 
> wrote:
> 
>> .convertBodyTo(SupportRequest.class)
>> 
> 
> And it doesnt when this is not included.

Re: Clarification on how Converters work with CDI

[Antonin Stefanutti]

Hi Anton,

And just to be sure this is a Camel CDI problem, could you add a:

convertBodyTo(SupportRequest.class)

in your Camel route, like:

public void configure() {

   from(ticketEndpoint) // returns a Ticket
   .convertBodyTo(SupportRequest.class)
   .to("jpa:my.domain.SupportRequest&persistenceUnit=camel"); // attempt
to persist SupportRequest
   }

and give that a try.

Thanks,

Antonin

> On 13 Apr 2016, at 12:58, Antonin Stefanutti  wrote:
> 
> Hi Anto,
> 
> Type converter annotated with @Converter are automatically discovered by 
> Camel CDI and added to the Camel context.
> 
> You can find an example here: 
> https://github.com/apache/camel/blob/337a6756480354afea7531a1a4216de9d232f211/components/camel-cdi/src/test/java/org/apache/camel/cdi/converter/InjectedTypeConverter.java#L27
> 
> So your type converter class just needs to be a class discovered by the CDI 
> container as documented in 
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#type_discovery_steps.
> 
> Could you activate Weld DEBUG log and provide us the container bootstrap logs?
> 
> Antonin
> 
>> On 13 Apr 2016, at 12:54, Anton  wrote:
>> 
>> Hi John
>> 
>> Thanks for your reply.
>> 
>> Im using Weld.
>> Im using Camel 2.17.0
>> 
>> My beans.xml looks like this:
>> 
>> 
>> 
>> 
>> 
>> I tried adding AppScoped, but it did not make any difference.
> 

Re: Clarification on how Converters work with CDI

[Antonin Stefanutti]

Hi Anto,

Type converter annotated with @Converter are automatically discovered by Camel 
CDI and added to the Camel context.

You can find an example here: 
https://github.com/apache/camel/blob/337a6756480354afea7531a1a4216de9d232f211/components/camel-cdi/src/test/java/org/apache/camel/cdi/converter/InjectedTypeConverter.java#L27

So your type converter class just needs to be a class discovered by the CDI 
container as documented in 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#type_discovery_steps.

Could you activate Weld DEBUG log and provide us the container bootstrap logs?

Antonin

> On 13 Apr 2016, at 12:54, Anton  wrote:
> 
> Hi John
> 
> Thanks for your reply.
> 
> Im using Weld.
> Im using Camel 2.17.0
> 
> My beans.xml looks like this:
> 
> 
> 
> 
> 
> I tried adding AppScoped, but it did not make any difference.

Re: CDI questions

[Antonin Stefanutti]

Tim,

For the second problem, I’ve just looked at how Camel looks up for the custom 
ExecutorService and it actually looks up the CDI registry for a named bean of 
type ExecutorService, so you can just produce your custom ExecutorService 
instead of a ThreadPoolProfile bean. Otherwise, it falls back to the configured 
ExecutorServiceManager so your first way of doing it (with a custom Camel 
context) should work with Camel 2.17.0.

Antonin

> On 06 Apr 2016, at 19:00, Antonin Stefanutti  wrote:
> 
> Hi Tim,
> 
> I see that it uses Camel 2.16.2. The Camel CDI component has been rewritten 
> and improved in Camel 2.17.0.
> 
> Could you upgrade your Camel dependencies to 2.17.0 version? That should 
> solve the issues.
> 
> Antonin
> 
>> On 06 Apr 2016, at 18:13, Tim Dudgeon  wrote:
>> 
>> Hi Antonin
>> 
>> I tried your suggestion for problem 2, but couldn't get it to work.
>> 
>> I've put an example that illustrates both problems here:
>> https://github.com/tdudgeon/camel-cdi-servlet-example
>> 
>> To reproduce the first problem just remove the @ContextName annotation from 
>> 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'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 is 
>>>> essential.
>>>> e.g. if my app comprise just of a couple of classes extending RoutBuilder 
>>>> then I MUST have this annotation present.
>>>> I would have assumed that if I only have a single CamelContext then this 
>>>> would have been unnecessary?
>>> This should work as you assume. For example, if you execute the following 
>>> test:
>>> 
>>> @RunWith(Arquillian.class)
>>> public class CdiTest {
>>> 
>>>@Deployment
>>>public static Archive deployment() {
>>>return ShrinkWrap.create(JavaArchive.class)
>>>// Camel CDI
>>>.addPackage(CdiCamelExtension.class.getPackage())
>>>// Bean archive deployment descriptor
>>>.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
>>>}
>>> 
>>>static class FirstRoute extends RouteBuilder {
>>> 
>>>@Override
>>>public void configure() {
>>>from("direct:first").to("mock:first");
>>>}
>>>}
>>> 
>>>static class SecondRoute extends RouteBuilder {
>>> 
>>>@Override
>>>public void configure() {
>>>from("direct:second").to("mock:second");
>>>}
>>>}
>>> 
>>>@Test
>>>public void test() {
>>>}
>>> }
>>> 
>>> You see that the two route builders get added to the default Camel context:
>>> 
>>> 2016-04-06 16:56:53,201 INFO  [   main] o.a.c.c.CdiCamelExtension   
>>>  : Camel CDI is starting Camel context [camel-1]
>>> 2016-04-06 16:56:53,202 INFO  [   main] o.a.c.i.DefaultCamelContext 
>>>  : Apache Camel 2.17.0 (CamelContext: camel-1) is starting
>>> 2016-04-06 16:56:53,581 INFO  [   main] o.a.c.i.DefaultCamelContext 
>>>  : Route: route1 started and consuming from: 
>>> Endpoint[direct://second]
>>> 2016-04-06 16:56:53,585 INFO  [   main] o.a.c.i.DefaultCamelContext 
>>>  : Route: route2 started and consuming from: 
>>> Endpoint[direct://first]
>>> 2016-04-06 16:56:53,586 INFO  [   main] o.a.c.i.DefaultCamelContext 
>>>  : Total 2 routes, of which 2 are started.
>>> 2016-04-06 16:56:53,587 INFO  [   main] o.a.c.i.DefaultCamelContext 
>>>  : Apache Camel 2.17.0 (CamelContext: camel-1) started in 0.385 
>>> seconds
>>> 2016-04-06 16:56:53,649 INFO  [   main] 
>>> o.a.c.c.CamelContextProducer : Camel CDI is stopping Camel 
>>> context [camel-1]
>>> 2016-04-06 16:56:53,649 INFO  [   main] o.a.c.i.DefaultCamelContext 
>&g

Re: CDI questions

[Antonin Stefanutti]

Hi Tim,

I see that it uses Camel 2.16.2. The Camel CDI component has been rewritten and 
improved in Camel 2.17.0.

Could you upgrade your Camel dependencies to 2.17.0 version? That should solve 
the issues.

Antonin

> On 06 Apr 2016, at 18:13, Tim Dudgeon  wrote:
> 
> Hi Antonin
> 
> I tried your suggestion for problem 2, but couldn't get it to work.
> 
> I've put an example that illustrates both problems here:
> https://github.com/tdudgeon/camel-cdi-servlet-example
> 
> To reproduce the first problem just remove the @ContextName annotation from 
> 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'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 is 
>>> essential.
>>> e.g. if my app comprise just of a couple of classes extending RoutBuilder 
>>> then I MUST have this annotation present.
>>> I would have assumed that if I only have a single CamelContext then this 
>>> would have been unnecessary?
>> This should work as you assume. For example, if you execute the following 
>> test:
>> 
>> @RunWith(Arquillian.class)
>> public class CdiTest {
>> 
>> @Deployment
>> public static Archive deployment() {
>> return ShrinkWrap.create(JavaArchive.class)
>> // Camel CDI
>> .addPackage(CdiCamelExtension.class.getPackage())
>> // Bean archive deployment descriptor
>> .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
>> }
>> 
>> static class FirstRoute extends RouteBuilder {
>> 
>> @Override
>> public void configure() {
>> from("direct:first").to("mock:first");
>> }
>> }
>> 
>> static class SecondRoute extends RouteBuilder {
>> 
>> @Override
>> public void configure() {
>> from("direct:second").to("mock:second");
>> }
>> }
>> 
>> @Test
>> public void test() {
>> }
>> }
>> 
>> You see that the two route builders get added to the default Camel context:
>> 
>> 2016-04-06 16:56:53,201 INFO  [   main] o.a.c.c.CdiCamelExtension
>> : Camel CDI is starting Camel context [camel-1]
>> 2016-04-06 16:56:53,202 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Apache Camel 2.17.0 (CamelContext: camel-1) is starting
>> 2016-04-06 16:56:53,581 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Route: route1 started and consuming from: 
>> Endpoint[direct://second]
>> 2016-04-06 16:56:53,585 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Route: route2 started and consuming from: 
>> Endpoint[direct://first]
>> 2016-04-06 16:56:53,586 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Total 2 routes, of which 2 are started.
>> 2016-04-06 16:56:53,587 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Apache Camel 2.17.0 (CamelContext: camel-1) started in 0.385 
>> seconds
>> 2016-04-06 16:56:53,649 INFO  [   main] o.a.c.c.CamelContextProducer 
>> : Camel CDI is stopping Camel context [camel-1]
>> 2016-04-06 16:56:53,649 INFO  [   main] o.a.c.i.DefaultCamelContext  
>> : Apache Camel 2.17.0 (CamelContext: camel-1) is shutting down
>> 2016-04-06 16:56:53,651 INFO  [   main] 
>> o.a.c.i.DefaultShutdownStrategy  : Starting to graceful shutdown 2 
>> routes (timeout 300 seconds)
>> 2016-04-06 16:56:53,655 INFO  [ - ShutdownTask] 
>> o.a.c.i.DefaultShutdownStrategy  : Route: route2 shutdown complete, 
>> was consuming from: Endpoint[direct://first]
>> 2016-04-06 16:56:53,655 INFO  [ - ShutdownTask] 
>> o.a.c.i.DefaultShutdownStrategy  : Route: route1 shutdown complete, 
>> was consuming from: Endpoint[direct://second]
>> 2016-04-06 16:56:53,656 INFO  [   main] 
>> o.a.c.i.DefaultShutdownStrategy  : Graceful shutdown of 2 routes 
>> completed in 0 seconds
>> 2016-04-06 16:56:53,660 INFO  [  

Re: CDI questions

[Antonin Stefanutti]

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 is essential.
> e.g. if my app comprise just of a couple of classes extending RoutBuilder 
> then I MUST have this annotation present.
> I would have assumed that if I only have a single CamelContext then this 
> would have been unnecessary?

This should work as you assume. For example, if you execute the following test:

@RunWith(Arquillian.class)
public class CdiTest {

@Deployment
public static Archive deployment() {
return ShrinkWrap.create(JavaArchive.class)
// Camel CDI
.addPackage(CdiCamelExtension.class.getPackage())
// Bean archive deployment descriptor
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}

static class FirstRoute extends RouteBuilder {

@Override
public void configure() {
from("direct:first").to("mock:first");
}
}

static class SecondRoute extends RouteBuilder {

@Override
public void configure() {
from("direct:second").to("mock:second");
}
}

@Test
public void test() {
}
}

You see that the two route builders get added to the default Camel context:

2016-04-06 16:56:53,201 INFO  [   main] o.a.c.c.CdiCamelExtension   
 : Camel CDI is starting Camel context [camel-1]
2016-04-06 16:56:53,202 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Apache Camel 2.17.0 (CamelContext: camel-1) is starting
2016-04-06 16:56:53,581 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Route: route1 started and consuming from: Endpoint[direct://second]
2016-04-06 16:56:53,585 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Route: route2 started and consuming from: Endpoint[direct://first]
2016-04-06 16:56:53,586 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Total 2 routes, of which 2 are started.
2016-04-06 16:56:53,587 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Apache Camel 2.17.0 (CamelContext: camel-1) started in 0.385 seconds
2016-04-06 16:56:53,649 INFO  [   main] o.a.c.c.CamelContextProducer
 : Camel CDI is stopping Camel context [camel-1]
2016-04-06 16:56:53,649 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Apache Camel 2.17.0 (CamelContext: camel-1) is shutting down
2016-04-06 16:56:53,651 INFO  [   main] o.a.c.i.DefaultShutdownStrategy 
 : Starting to graceful shutdown 2 routes (timeout 300 seconds)
2016-04-06 16:56:53,655 INFO  [ - ShutdownTask] o.a.c.i.DefaultShutdownStrategy 
 : Route: route2 shutdown complete, was consuming from: 
Endpoint[direct://first]
2016-04-06 16:56:53,655 INFO  [ - ShutdownTask] o.a.c.i.DefaultShutdownStrategy 
 : Route: route1 shutdown complete, was consuming from: 
Endpoint[direct://second]
2016-04-06 16:56:53,656 INFO  [   main] o.a.c.i.DefaultShutdownStrategy 
 : Graceful shutdown of 2 routes completed in 0 seconds
2016-04-06 16:56:53,660 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Apache Camel 2.17.0 (CamelContext: camel-1) uptime 0.459 seconds
2016-04-06 16:56:53,660 INFO  [   main] o.a.c.i.DefaultCamelContext 
 : Apache Camel 2.17.0 (CamelContext: camel-1) is shutdown in 0.011 
seconds

Could you please send more details about your deployment so that I can help 
identify why that is not working as expected?

> 2. I'm try to use a custom thread pool. As described in the docs I use a 
> @Producer to generate the thread pool profile:
> 
> public class CamelContextFactory {
> 
> @Produces
> @ApplicationScoped
> CamelContext customize() {
> DefaultCamelContext context = new DefaultCamelContext();
> context.setName("mycontext");
> ThreadPoolProfile profile = new 
> ThreadPoolProfileBuilder("poolName").poolSize(4).maxPoolSize(50).build();
> context.getExecutorServiceManager().registerThreadPoolProfile(profile);
> return context;
> }
> }
> 
> This seems to be executed as expected, but when I try to use the thread pool 
> in a route like this:
> 
> from("direct:foo" )
> .threads().executorServiceRef("poolName")
> .log("route executed");
> 
> then the pool can't be found:
> 
> Caused by: java.lang.IllegalArgumentException: ExecutorServiceRef poolName 
> not found in registry or as a thread pool profile.

The lookup is done by name so you need to have a @Named("poolName") bean 
deployed or have the ExecutorService register manually into the Camel context 
(which you do but for some reasons it does not get found).

So in your example, I would try:

@Produces
@Named("poolName")
ThreadPoolProfile profile() {
return 
ThreadPoolProfileBuilder("poolNam

Re: Camel 2.17 camel-cdi injection problem

[Antonin Stefanutti]

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 this area in
> this new release.
> 
> I am trying to run camel as part of JBoss EAP 6.4 (I cannot use Wildfly with
> the camel extensions, and I cannot use Fuse which my company pays for (as it
> currently only supports camel 2.16 and I need elasticsearch 2.0 support
> which is only available in camel 2.17))
> 
> The fault: 
> WELD-000119 Not generating any bean definitions from
> org.apache.camel.cdi.Main because of underlying class loading error
> 
> Which I tracked down to as being caused by 
> java.lang.NoClassDefFoundError:
> Lorg/apache/deltaspike/cdise/api/CdiContainer;
> 
> It seems that the inclusion of deltaspike in 2.17 is optional (from
> camel-cdi pom.xml file)
> 
> DeltaSpike is only used to provide Main support thus optional
>
>org.apache.deltaspike.cdictrl
>deltaspike-cdictrl-api
>${deltaspike-version}
>true
>
> 
> How can i ensure that the jar file is included in camel-cdi 2.17?

The org.apache.camel.cdi.Main is only useful when using Camel CDI in Java SE. 
It then uses DeltaSpike (for the time being, as CDI 2.0 will provide a standard 
way of doing it) to bootstrap the CDI container, hence the optional dependency, 
to avoid other environments to depend on it.

So the CDI container should not scan that class. That’s why it’s excluded in 
the beans.xml file of the camel-cdi.jar. Unfortunately, that scan exclusion is 
only supported starting CDI 1.1 and JBoss EAP 6.4 is still CDI 1.0. So the 
exception occurs because there is no way to tell the CDI 1.0 / Weld 1.x to not 
scan that class. So new CDI versions (1.1 and 1.2) avoids having an unnecessary 
dependency on DeltaSpike, the trade-off being that CDI 1.0 users have to 
declare that dependency explicitly.

That being said, I think WELD-000119 is only a warning and does not prevent the 
application to deploy. So either that warning is acceptable for you (until you 
upgrade to a newer CDI version), or you can add the dependency on DeltaSpike 
control API explicitly.

Let me know if that answers your question.

Antonin

> thanks
> /murt
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-2-17-camel-cdi-injection-problem-tp5780050.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: [CAMEL-CDI] What's is the CDI scope for the RouteBuilder?

[Antonin Stefanutti]

> On 24 Mar 2016, at 12:47, Charlee Chitsuk  wrote:
> 
> My project is based on CDI and Camel-CDI. I've tried to reduce the some of
> "similar" RouteBuilder concrete classes by making it to receive the
> different parameter, e.g source and destination. I'm not sure if
> registering manually is a suitable way or not.

In the 'nominal' use cases, you would let the Camel CDI extension do the 
auto-configuration of your Camel context. However, you can still do some more 
configuration ‘manually'.

In your case, I understand you’ve tried to factorise some route definitions 
into some sort of templates.

For example:

if you have two routes:
from("direct:in1").routeId("route1").to("direct:out1");
from("direct:in2").routeId(“route2").to("direct:out2");

You’ve tried to parameterised it to have a single reusable route.

IMO, the Camel DSL is so compact that the duplication is so little that it’s 
not always worth the factorisation effort. And often the readability is better 
as you don’t have to understand the parametrisation when reading the code.

Still if you think that is a better approach for you use case, indeed, you can 
declare a RouteBuilder bean @Dependent, having it parameterised depending for 
example on the InjectionPoint metadata and add these parameterised instances to 
the Camel context manually.

Antonin

> --
>   Best Regards,
> 
>   Charlee Chitsuk
> 
> ===
> Application Security Product Group
> *Summit Computer Co., Ltd.* <http://www.summitthai.com/>
> E-Mail: char...@summitthai.com
> Tel: +66-2-238-0895 to 9 ext. 164
> Fax: +66-2-236-7392
> ===
> *@ Your Success is Our Pride*
> --
> 
> 2016-03-24 18:30 GMT+07:00 John D. Ament :
> 
>> On Thu, Mar 24, 2016 at 7:29 AM Charlee Chitsuk 
>> wrote:
>> 
>>> Hi Antonin,
>>> 
>>> Thank you very much. This answer my question.
>>> 
>>> 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?
>>> 
>> 
>> Well if you're doing manual registration, then you're not using the Camel
>> CDI capability of looking up your route builders automatically.
>> 
>> 
>>> 
>>> --
>>>   Best Regards,
>>> 
>>>   Charlee Ch.
>>> 
>>> 2016-03-24 15:20 GMT+07:00 Antonin Stefanutti :
>>> 
>>>> 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 @AppplicationScoped generally.
>>>> 
>>>> So that’s up to the developer to decide what’s the best scope depending
>>> on
>>>> its need. Obviously, if the RouteBuilder instance needs to be shared
>>>> somehow, then it needs to be @ApplicationScoped.
>>>> 
>>>> I’ll mention that to the documentation if that answers your question.
>>>> 
>>>> Antonin
>>>> 
>>>>> On 24 Mar 2016, at 06:49, Charlee Chitsuk 
>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>  Regarding to the Camel CDI [1] which mentions that it provides
>>>>> the Auto-detecting Camel routes. I would like to know what the CDI
>>> scope
>>>> of
>>>>> that RouteBuilder is. Is it @ApplicationScoped?
>>>>> 
>>>>> 
>>>>> [1] http://camel.apache.org/cdi.html
>>>>> 
>>>>> --
>>>>>  Best Regards,
>>>>> 
>>>>>  Charlee Ch.
>>>> 
>>>> 
>>> 
>> 

Re: [CAMEL-CDI] What's is the CDI scope for the RouteBuilder?

[Antonin Stefanutti]

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 @AppplicationScoped generally.

So that’s up to the developer to decide what’s the best scope depending on its 
need. Obviously, if the RouteBuilder instance needs to be shared somehow, then 
it needs to be @ApplicationScoped.

I’ll mention that to the documentation if that answers your question.

Antonin

> On 24 Mar 2016, at 06:49, Charlee Chitsuk  wrote:
> 
> Hi,
> 
>   Regarding to the Camel CDI [1] which mentions that it provides
> the Auto-detecting Camel routes. I would like to know what the CDI scope of
> that RouteBuilder is. Is it @ApplicationScoped?
> 
> 
> [1] http://camel.apache.org/cdi.html
> 
> --
>   Best Regards,
> 
>   Charlee Ch.

Re: ScalaRouteBuilder with CDI

[Antonin Stefanutti]

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 2.17.0 release so that classes like CamelContextConfig no longer 
exists. The documentation has been updated: http://camel.apache.org/cdi.html 
and some new samples have been contributed as well.

That’d be great to complement these samples with a Camel CDI Scala one. So if 
you have a demo sample to share, that may serve as the basis for it and I’d be 
glad to help make it works.

Antonin

> On 01 Mar 2016, at 08:18, Raphael Parree  wrote:
> 
> Hi,
> 
> I am porting some of my camel demos to CDI (for FIS/Fabric8).
> The RouteBuilder has been deprecated a while back in favour of the
> ScalaRouteBuilder which requires a constructor value for the CamelContext.
> I can only get it to work with the deprecated RouteBuilder as i am
> unsuccessful so far injecting a value for the CamelContext. In addition one
> can use the @CamelContext to define the context for the route.
> 
> Is there a recommended approach or does it need a change in
> the org.apache.camel.cdi.internal.CamelContextConfig?
> 
> tx.,
> 
> 
> 
> -- 
> Raphaël Parrée
> EDC4IT Europe BV
> (m) +33 673 75 34 62
> (p) + 31 88 584 8895
> @rparree  | LinkedIn
> 
> 
> -- 
> EDC4IT Europe BV is a company registered in the Netherlands. Registered 
> number: 58704663. Registered office: Leeghwaterstraat 25, 2811 DT Reeuwijk. 
> | This communication is for use by the intended recipient and contains 
> information that may be privileged, confidential or copyrighted under 
> applicable law. If you are not the intended recipient, you are hereby 
> formally notified that any use, copying or distribution of this e-mail, in 
> whole or in part, is strictly prohibited. Please notify the sender by 
> return e-mail and delete this e-mail from your system. Unless explicitly 
> and conspicuously designated as " E-Contract Intended", this e-mail does 
> not constitute a contract offer, a contract amendment, or an acceptance of 
> a contract offer. This e-mail does not constitute a consent to the use of 
> sender's contact information for direct marketing purposes or for transfers 
> of data to third parties. | i...@edc4it.com. 
> 
> 

Re: CDI Injection support

[Antonin Stefanutti]

Hi John,

Thanks for the info. I didn’t see you created CAMEL-9630.

Antonin

> On 24 Feb 2016, at 01:20, John D. Ament  wrote:
> 
> Hi Antonin,
> 
> Looks like you pushed up already what I was working on (when I found this
> issue): https://issues.apache.org/jira/browse/CAMEL-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 resources.
>> 
>> For #2, I’ve opened issue OWB-1122 [2] in OpenWebBeans JIRA.
>> 
>> At that occasion, I've refactored a bit the qualifier literals for
>> @ContextName and @Uri in order to match the style of those that will be
>> provided in CDI 2.0 [3].
>> 
>> [1]:
>> https://github.com/apache/camel/commit/93631c85f4250b3843a7ada987c99aeed909a11d
>> [2]: https://issues.apache.org/jira/browse/OWB-1122
>> [3]: https://issues.jboss.org/browse/CDI-485
>> 
>> Do not hesitate if you any have other points.
>> 
>> Thanks,
>> Antonin
>> 
>>> On 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 opposed to OWB.
>>> 
>>>> On 22 Feb 2016, at 17:36, John D. Ament  wrote:
>>>> 
>>>> Hi 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.
>>>>> 
>>>>> 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 does not return the correct set of refined qualifiers
>> when
>>>>> calling InjectionPoint.getQualifiers in producer methods for Instance
>> with
>>>>> selected qualifiers.
>>>>> 
>>>>> I have a fix for the former. I’ll polish it a bit and commit it ASAP.
>> For
>>>>> the later, I’ll report an issue in OWB JIRA and reactivate the test
>> case
>>>>> once it gets fixed.
>>>>> 
>>>>> Antonin
>>>>> 
>>>>>> On 22 Feb 2016, at 13:40, John D. Ament 
>> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I was looking at the changes that went into Camel 2.17 with CDI
>> injection
>>>>>> support.  It seems that injection support doesn't work consistently
>> when
>>>>>> done not using an annotated member.
>>>>>> 
>>>>>> I tried a few different ways:
>>>>>> 
>>>>>> @Inject
>>>>>> @Any
>>>>>> private Instance endpointInstance;
>>>>>> 
>>>>>> ...
>>>>>> 
>>>>>> endpointInstance.select(MockEndpoint.class, new
>>>>>> UriLiteral("mock:outgoing")).get()
>>>>>> 
>>>>>> Which consistently gives back (in Weld 1.1.x, 2.x, OWB 1.2.x and OWB
>>>>> 1.6.x)
>>>>>> an error that no beans are defined, even though I have that endpoint
>>>>>> defined.
>>>>>> 
>>>>>> Now, if I try the CDI 1.1 way of using the utility class to look up
>> the
>>>>>> instance, it works fine in Weld 2.x but not OWB 1.6.x.  As far as I
>> know,
>>>>>> this setup should work in both, and since I know I use pattern in
>> other
>>>>>> apps I don't think its a case of a bug in the impl.  I was wondering
>> if
>>>>> any
>>>>>> camel gurus could comment on it?
>>>>>> 
>>>>>> 
>>>>> 
>> https://github.com/johnament/camel/commit/05dd5f6f8cda541fedfc68c6f199e014defe3f09
>>>>>> 
>>>>>> John
>>>>> 
>>>>> 
>>> 
>> 
>> 

Re: CDI Injection support

[Antonin Stefanutti]

Hi John,

For #1, I’ve just pushed [1] to improve the support for programmatic lookup of 
Camel resources.

For #2, I’ve opened issue OWB-1122 [2] in OpenWebBeans JIRA.

At that occasion, I've refactored a bit the qualifier literals for @ContextName 
and @Uri in order to match the style of those that will be provided in CDI 2.0 
[3].

[1]: 
https://github.com/apache/camel/commit/93631c85f4250b3843a7ada987c99aeed909a11d
[2]: https://issues.apache.org/jira/browse/OWB-1122
[3]: https://issues.jboss.org/browse/CDI-485

Do not hesitate if you any have other points.

Thanks,
Antonin

> On 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 opposed to OWB.
> 
>> On 22 Feb 2016, at 17:36, John D. Ament  wrote:
>> 
>> Hi 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.
>>> 
>>> 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 does not return the correct set of refined qualifiers when
>>> calling InjectionPoint.getQualifiers in producer methods for Instance with
>>> selected qualifiers.
>>> 
>>> I have a fix for the former. I’ll polish it a bit and commit it ASAP. For
>>> the later, I’ll report an issue in OWB JIRA and reactivate the test case
>>> once it gets fixed.
>>> 
>>> Antonin
>>> 
>>>> On 22 Feb 2016, at 13:40, John D. Ament  wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I was looking at the changes that went into Camel 2.17 with CDI injection
>>>> support.  It seems that injection support doesn't work consistently when
>>>> done not using an annotated member.
>>>> 
>>>> I tried a few different ways:
>>>> 
>>>> @Inject
>>>> @Any
>>>> private Instance endpointInstance;
>>>> 
>>>> ...
>>>> 
>>>> endpointInstance.select(MockEndpoint.class, new
>>>> UriLiteral("mock:outgoing")).get()
>>>> 
>>>> Which consistently gives back (in Weld 1.1.x, 2.x, OWB 1.2.x and OWB
>>> 1.6.x)
>>>> an error that no beans are defined, even though I have that endpoint
>>>> defined.
>>>> 
>>>> Now, if I try the CDI 1.1 way of using the utility class to look up the
>>>> instance, it works fine in Weld 2.x but not OWB 1.6.x.  As far as I know,
>>>> this setup should work in both, and since I know I use pattern in other
>>>> apps I don't think its a case of a bug in the impl.  I was wondering if
>>> any
>>>> camel gurus could comment on it?
>>>> 
>>>> 
>>> https://github.com/johnament/camel/commit/05dd5f6f8cda541fedfc68c6f199e014defe3f09
>>>> 
>>>> John
>>> 
>>> 
> 

Re: CDI Injection support

[Antonin Stefanutti]

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 opposed to OWB.

> On 22 Feb 2016, at 17:36, John D. Ament  wrote:
> 
> Hi 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.
>> 
>> 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 does not return the correct set of refined qualifiers when
>> calling InjectionPoint.getQualifiers in producer methods for Instance with
>> selected qualifiers.
>> 
>> I have a fix for the former. I’ll polish it a bit and commit it ASAP. For
>> the later, I’ll report an issue in OWB JIRA and reactivate the test case
>> once it gets fixed.
>> 
>> Antonin
>> 
>>> On 22 Feb 2016, at 13:40, John D. Ament  wrote:
>>> 
>>> Hi all,
>>> 
>>> I was looking at the changes that went into Camel 2.17 with CDI injection
>>> support.  It seems that injection support doesn't work consistently when
>>> done not using an annotated member.
>>> 
>>> I tried a few different ways:
>>> 
>>> @Inject
>>> @Any
>>> private Instance endpointInstance;
>>> 
>>> ...
>>> 
>>> endpointInstance.select(MockEndpoint.class, new
>>> UriLiteral("mock:outgoing")).get()
>>> 
>>> Which consistently gives back (in Weld 1.1.x, 2.x, OWB 1.2.x and OWB
>> 1.6.x)
>>> an error that no beans are defined, even though I have that endpoint
>>> defined.
>>> 
>>> Now, if I try the CDI 1.1 way of using the utility class to look up the
>>> instance, it works fine in Weld 2.x but not OWB 1.6.x.  As far as I know,
>>> this setup should work in both, and since I know I use pattern in other
>>> apps I don't think its a case of a bug in the impl.  I was wondering if
>> any
>>> camel gurus could comment on it?
>>> 
>>> 
>> https://github.com/johnament/camel/commit/05dd5f6f8cda541fedfc68c6f199e014defe3f09
>>> 
>>> John
>> 
>> 

Re: CDI Injection support

[Antonin Stefanutti]

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 does not return the correct set of refined qualifiers when 
calling InjectionPoint.getQualifiers in producer methods for Instance with 
selected qualifiers.

I have a fix for the former. I’ll polish it a bit and commit it ASAP. For the 
later, I’ll report an issue in OWB JIRA and reactivate the test case once it 
gets fixed.

Antonin

> On 22 Feb 2016, at 13:40, John D. Ament  wrote:
> 
> Hi all,
> 
> I was looking at the changes that went into Camel 2.17 with CDI injection
> support.  It seems that injection support doesn't work consistently when
> done not using an annotated member.
> 
> I tried a few different ways:
> 
> @Inject
> @Any
> private Instance endpointInstance;
> 
> ...
> 
> endpointInstance.select(MockEndpoint.class, new
> UriLiteral("mock:outgoing")).get()
> 
> Which consistently gives back (in Weld 1.1.x, 2.x, OWB 1.2.x and OWB 1.6.x)
> an error that no beans are defined, even though I have that endpoint
> defined.
> 
> Now, if I try the CDI 1.1 way of using the utility class to look up the
> instance, it works fine in Weld 2.x but not OWB 1.6.x.  As far as I know,
> this setup should work in both, and since I know I use pattern in other
> apps I don't think its a case of a bug in the impl.  I was wondering if any
> camel gurus could comment on it?
> 
> https://github.com/johnament/camel/commit/05dd5f6f8cda541fedfc68c6f199e014defe3f09
> 
> John

Re: Camel and CDI moving from CdiCamelContext to CamelContext

[Antonin Stefanutti]

> 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 and installing Fuse 6.2.1 on top.
> I was using 2.15.1 before the move and now using 2.15.1.redhat-621084 with
> the idea that I could mark it as provided and not bundle it up with the war
> (that is not working but I'll write a separate question for it as it works
> when I scope it to compile).
> 
> So anyway, after reading a bit:
> - http://camel.apache.org/cdi.html
> - https://wildflyext.gitbooks.io/wildfly-camel/content/javaee/cdi.html
> -
> http://blog.eisele.net/2015/07/using-camel-routes-in-java-ee-components.html
> 
> To give you an idea, before I had it working doing something similar to:
> -
> https://github.com/myfear/CamelEE7/blob/master/src/main/java/org/javaee7/extra/camel/Bootstrap.java
> 
> I managed to deploy but changing from CdiCamelContext and removing the
> manual bootstrap gives me the following error when trying to use my
> application:
> 
> WELD-49 Unable to invoke [method] @PostConstruct public
> org.apache.camel.cdi.CdiCamelContext.start() on CamelContext(camel-2)
> 
> Any ideas of what am I doing wrong?

So you can still be using CdiCamelContext. The Camel CDI documentation has just 
been updated for the upcoming 2.17.0 release. That release comes with an 
improved Camel CDI component that can managed any kind of CamelContext so that 
you don’t have to use CDI specific thing.

However, it previous versions, you still have to use CdiCamelContext. I’ll make 
that clearer in the documentation.

Let us know if that answers your question.

Re: Errors:DirectConsumerNotAvailableException: No consumers available.

[Antonin Stefanutti]

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 this message in context: 
> http://camel.465427.n5.nabble.com/Errors-DirectConsumerNotAvailableException-No-consumers-available-tp5777818p5777863.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel - CDI and Servlet Context Implementation

[Antonin Stefanutti]

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 been merged into Camel master branch so that it will be part of the 
upcoming 2.17.0 release.

Let me know if the example needs to be improved.

Antonin

> On 26 Jan 2016, at 18:58, Tim Dudgeon  wrote:
> 
> I didn't see any answer to this, and have hit the same.
> 
> I've got Camel running in Tomcat using camel-servlet and 
> camel-servletlistener as described here:
> http://camel.apache.org/servletlistener-component.html
> 
> Also, independently I've used the new camel-cdi stuff found here:
> https://github.com/astefanutti/camel-cdi
> to get a very basic Camel implementation running using CDI e.g. creating a 
> CDI injected subclass of HttpServlet annotated with @WebServlet.
> 
> But its not clear how to combine the two. In my case I've got routes that use 
> the REST DSL and are using the camel-servlet component.
> 
> e.g. starting from a RouteBuilder that looks like this:
> 
>@Inject Something something
> 
>@Override
>public void configure() throws Exception {
> 
>restConfiguration().component("servlet").host("0.0.0.0");
> 
>rest("/ping")
>.get()
>.produces("text/plain")
>.route()
>.transform(constant("Ping\n")).endRest();
>}
> 
> 
> what's the shortest path of travel to get this working e.g. how to define the 
> servlet?
> 
> Thanks
> Tim
> 
> 
> On 19/03/2015 08:02, Naveen Subramanian wrote:
>> Hi,
>> 
>> I have implemented Camel with Servlet implementation using ServletContext.
>> I wish to implement CDI as well (which needs CdiCamelConext).
>> 
>> I am unable to find a way to implement both. Please suggest.
>> 
>> 
>> My web.xml
>> 
>> 
>> routeBuilder-routes
>> packagescan:com.example.api.routes
>> 
>> 
>> 
>> CamelContextLifecycle
>> com.example.api.camel.CustomCamelContextLifeCycle
>> 
>> 
>> org.apache.camel.component.servletlistener.SimpleCamelServletContextListener
>> 
>> 
>> 
>> 
>> 
>> 
>> APIServerServlet
>> CamelServlet
>> org.apache.camel.component.servlet.CamelHttpTransportServlet
>> 1
>> 
>> 
>> 
>> CamelServlet
>> /*
>> 
>> 
>> 
>> 
>> (P.S no Spring )
>> 
> 

Re: camel-sjms support for JMS 2 in OSGI

[Antonin Stefanutti]

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 the sjms component's manifest reflect jms version range till 3 (similar
> to camel jms). This way the compatibility with JMS 1.1 wouldn't be broken.
> 
> I havent tried changing the manifest and checking out if it really works.. I
> can proceed ahead (raise a JIRa and contribute) on this if the support is
> needed and makes sense.
> 
> Regards,
> -Yogesh
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/camel-sjms-support-for-JMS-2-in-OSGI-tp5776164.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: State of the camel-cdi component

[Antonin Stefanutti]

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 bring, among other things, better CDI programming model integration 
plus the portability to all targeted runtimes (Java SE, servlets containers, 
Java EE, OSGi with the expositing of the CDI camel contexts as OSGi services) 
and implementations (Weld and OpenWebBeans).

In the meantime, you can use the version in 
https://github.com/astefanutti/camel-cdi as a drop-in replacement and switch 
back to the official one once that gets merged and released into the official 
component.

Antonin

> On 04 Jan 2016, at 19:37, Tim Dudgeon  wrote:
> 
> Hi,
> 
> Was wondering what the latest status was here (read below)?
> I'm trying to adapt a camel-servlet app to use CDI and it's not clear how to 
> best go about this.
> 
> Thanks
> 
> Tim
> 
> On 11/12/2014 16:07, Charles Moulliard wrote:
>> Hi Jason,
>> 
>> I'm working with Antonin on that new camel-cdi. when the code will be ready
>> it will be integrated with Camel project
>> 
>> Regards,
>> 
>> On Thu, Dec 11, 2014 at 4:17 PM, Jason Holmberg  wrote:
>> 
>>> Will the Camel project will officially adopt:
>>> 
>>> https://github.com/astefanutti/camel-cdi
>>> 
>>> as its CDI extension.  I have experimented with the 'official' extension
>>> available in 2.14.0 and feel that it is lacking much of what it needs to a
>>> viable component where as https://github.com/astefanutti/camel-cdi seems
>>> to
>>> have addresses many if not all of the deficiencies.
>>> 
>>> I see that there is active development on the official camel-cdi component,
>>> I feel that the work being done in
>>> https://github.com/astefanutti/camel-cdi
>>> is looking and working really well.
>>> 
>>> We would really prefer CDI over Spring for DI.
>>> 
>>> Thanks,
>>> Jason
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/State-of-the-camel-cdi-component-tp5760578.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>> 
>> 
>> 
> 

Re: Dynamically created CamelContext not visible in fuse console

[Antonin Stefanutti]

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 Karaf commands.

Antonin

> On 09 Dec 2015, at 15:52, rwijngaa  wrote:
> 
> ok, tried that. 
> 
>CamelContext camelContext = new
> OsgiSpringCamelContext(getApplicationContext(),
> Activator.getBundleContext());
> ((OsgiSpringCamelContext)camelContext).setName(contextId);
> 
> 
> The OsgiSpringCamelContext constructor is calling
> OsgiCamelContextHelper.osgiUpdate(this, bundleContext)) and this seems to do
> a lot of OSGi initialisation, but still no luck !
> note: Activator is copied from org.apache.camel.osgi.Activator and present
> in my bundle's manifest as Bundle-Activator.
> 
> Any pointers would be apprecciated
> Regards
> Rino
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Dynamically-created-CamelContext-not-visible-in-fuse-console-tp5774855p5774864.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to improve throughput by grouping messages in a Transaction (in JMS)

[Antonin Stefanutti]

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-batch-core library. (although the javadocs says
> its available)
> 
> I don't see the package org/springframework/batch/container at all in the
> library.
> I am using version 3.0.5
> 
> 
> regards
> D
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-improve-throughput-by-grouping-messages-in-a-Transaction-tp5773344p5774072.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to improve throughput by grouping messages in a Transaction (in JMS)

[Antonin Stefanutti]

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.apache.org/jms.html#JMS-Alltheotheroptions.

> On 18 Nov 2015, at 16:43, deepak_a  wrote:
> 
> Hi,
> 
> Thanks for the reply, the XA connection factory is in place,
> Can you pls point to an example on how to override the default
> messageListener?
> 
> (I have checked in forum - I am not able to see anyone done this in the
> past)
> 
> regards
> D
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-improve-throughput-by-grouping-messages-in-a-Transaction-tp5773344p5774063.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: How to improve throughput by grouping messages in a Transaction (in JMS)

[Antonin Stefanutti]

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' [2].

[1] 
http://docs.spring.io/spring-batch/apidocs/org/springframework/batch/container/jms/BatchMessageListenerContainer.html

[2] http://camel.apache.org/jms.html#JMS-Alltheotheroptions

> On 18 Nov 2015, at 14:17, deepak_a  wrote:
> 
> Hi,
> 
> As mentioned in my previous post - I am developing a bridge that will set
> b/w ActiveMQ and TIBCO EMS.
> 
> My aim is to use a XATransactionManager (like Atomikos) that will be common
> for the JMS Session that will consume from ActiveMQ and the JMS Session that
> will be publish to TIBCO EMS.
> 
> With the intermediate Queue - I still cannot achieve the above (especially
> when I want to group n messages into one transaction - since I want to
> achieve high throughput)
> 
> Is there any other work-around any one can recommend?
> 
> regards
> D
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/How-to-improve-throughput-by-grouping-messages-in-a-Transaction-tp5773344p5774044.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: catch exception in camel

[Antonin Stefanutti]

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, 
errorHandlerLogStackTrace

You can configure as well the interval between to recovery attempt with the 
'recoveryInterval' option.

See http://camel.apache.org/jms.html#JMS-Alltheotheroptions

> On 17 Nov 2015, at 10:13, Ishada  wrote:
> 
> errorHandler(deadLetterChannel("file:somelocation");
> 
>from("jms:queuwlocation").to(
>"file:someLocation");
> 
> I have read that camel error handling comes when there's a processing
> between two nodes, such as Processor, Predicate etc. But what if I cannot
> consume the message, in my case the camel cannot connect to jms. How should
> I log this exception ?. As I am trying to use a deadLetterChannel to send
> the message to filesystem, but since I have not received the message there
> is nothing new on the file location. how should I encounter this type of
> situation?
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/catch-exception-in-camel-tp5773978.html
> Sent from the Camel - Users mailing list archive at Nabble.com.