Fixesr https://issues.apache.org/jira/browse/CAMEL-18661

~~!Looking for input on the overall approach!~~

This change enables current span propagation to underlying libraries and end-user-code (for OpenTelemetry): for all spans created by Camel, it calls into span.makeCurrent()

However, OpenTelemetry (and other tracing tools) rely on ThreadLocal to propagate context. They do it carefully for Executors, Reactor, etc, so it works in async scenarios too.

Instrumentations have to close scope returned by span.makeCurrent() on the same thread where it was created to avoid leaking context (by leaving current span on current thread).

This is easy to guarantee with sync operations in Camel - ExchangeStarted/Sending and ExchangeCompleted/Sent events (where spans start and end) are called on the same thread.

However, for async operations, they are called on different threads.

This change also adds a new event - ExchangeAsyncStarted (naming needs more work), that notifies that Processor.process call has ended, i.e. async operation has started. Tracers would end the scope (but not span) when this event is sent.

Alternative approach:

add a dependency on camel-tracing to camel-base-engine and call into ActiveSpanManager directly:

try(AutoCloseable scope = ActiveSpanManager.makeSpanCurrent(exchange)) {
    sync = processor.process(exchange, async);
}

This would be easier to maintain and would more or less guarantee that scope is disposed on the same thread, however, dependency on tracing might not be desirable.

Traces with this change

(tick/testme spans come from Camel and were previously not correlated with ServiceBus spans coming from Azure SDK)

Submitted for review, thanks 👍

See the discussion on the user forum.

This makes CamelSpringBootApplicationController lifecycle bean with top priority during ApplicationContext close.

This PR implements components DSL according to CAMEL-13807. Few notes:

1. To use it to create a component, it can be used like this ComponentsBuilderFactory.kafka().setBrokers("{{host:port}}").build()
2. Since I needed to maintain the POM file and ComponentsBuilderFactory interface, I used a metadata json file to keep track on the generated DSL classes and update whatever needed.
3. To set the properties, I used component property configurer since it generates what is needed and I made use of that.
4. Since I used the metadata file approach, the build speed wasn't impacted much which is good.
5. If the placeholder needs to be resolved, the component needs to be built with the context being passed as parameter: ComponentsBuilderFactory.kafka().setBrokers("{{host:port}}").build(camelContext)
6. There are a lot of shared functionality between endpoinsDslMojo and componentsDslMojo, hence I have created an abstract class for both and helpers that can be shared in both. However, I left EndpointDslMojo untouched for now. Will remove some shared core once I am done from this PR.

Topics need to be done:

• [x] Fix checkstyle.
• [x] Add unit tests for the maven plugin generators.
• [x] Add more unit tests for camel-componentDsl.
• [x] Optimize some classes on the go.

Google PubSub component with producer and consumer endpoints, unit and integration tests. Speed optimisation (mini batching, async processing) will be done in subsequent releases - dependent on the new client library from Google. For now it is synchronous, message by message processing.

https://issues.apache.org/jira/browse/CAMEL-11879 Upgraded Lucene to latest version 7.0.0.

Passed the iTests for Karaf and OSGi without issues, including the camel-lucene component tests.

• Particular queries were raised in this issue.

1. Should there be summary pages for groups of related components? There already existed summary pages for groups including Ignite, Spring, and a few others. However, as this brings in clarification to understand the documentation, I also added a summary for other groups including AWS, AWS 2, Google.

2. What should their structure and appearance be? In the nav panel, I believe that the highly distributed related components should be bundled and grouped together within the parent component.

3. Should the nav pane indent the components in a group? As for user manual documentation under camel Kafka and others, the nav pane is well indented with subgroups and parent groups. Thus, it has been done in the same manner for this PR.

Before the upgrade I was not able to run tests properly, because of an error during setup of HadoopMinicluster. In that case all tests pass, but are not started. I have a linux environment.

After the update I was able to run tests. There are 18 positive results and 2 negative in my environment. I cannot check how many negative tests were on the previous versions, because of the error mentioned at the beginning.

Operations :

• Delete folder
• Delete document
• Move folder
• Move document
• Rename folder
• Rename document
• Copy folder
• Copy document
• CheckIn
• CheckOut
• CancelCheckOut

I have to mention that I am not able to build the original apache camel project. That means I cant run the test written by the author of Camel-cmis. I was working only on Camel-cmis module in a separate project. I was testing all new operations with alfresco repository.

• [ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• [ ] Each commit in the pull request should have a meaningful subject line and body.
• [ ] If you're unsure, you can format the pull request title like [CAMEL-XXX] Fixes bug in camel-file component, where you replace CAMEL-XXX with the appropriate JIRA issue.
• [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [ ] Run mvn clean install -Psourcecheck in your module with source check enabled to make sure basic checks pass and there are no checkstyle violations. A more thorough check will be performed on your pull request automatically. Below are the contribution guidelines: https://github.com/apache/camel/blob/main/CONTRIBUTING.md

Hello, since WhatsApp business released new public API, https://developers.facebook.com/docs/whatsapp/cloud-api/, I created a new component camel-whatsapp which integrate camel with those API (pretty much like telegram).

As you can see from the integration test, the producer is working as expected, but before adding more features, documentation and so on I'd like to have your feedback if it is worth to have this component.

Moreover I have some question:

• I'm using async-http-client as HTTP client, but seems like that the project is not maintained anymore, should I use another library?
• As you can see from cloud-api documentation, webhook can be used, I was wondering if camel-webhook can be used and if I could receive some help

The output of the test right now is:

Adding Camel example for Ceylon 1.3.3.

Followed the path of the Kotlin example as instructed on the ticket.

Compile/Runs without errors and I'm able to access Jetty's localhost:8080 for the welcome message.

Things I couldn't get around:

1. The module.ceylon file cannot refer to Maven POM versions/properties unfortunately needing a hardcoded version of the used libs (double-checked on the Ceylon Gitter channel too)
2. I had to hardcode the version of camel-http-common since the 2.22.0-SNAPSHOT does not exist

This component should allow to use Google Firebase (see https://firebase.google.com/docs/admin/setup ) from Camel. It contains an end point with a Producer and a Consumer. The producer can create and update values in Firebase. The consumer listens to child events and can consume add, change, remove, move and cancel operations.

You will find some integration unit tests in this first commit. But these tests will need to have a JSON file ('firebase-admin-connection.json') with the Firebase keys so that the tests can run. For security reasons I have removed these. Not quite sure how to solve that.

I am a newbie on this project, so it might well be that I am not complying to your standards. Please guide me where needed.

Currently, Pulsar producer can't send a message larger than maxMessageSize. This PR enables the producer to chunk such a message for overcoming this limitation.

• [x] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• [x] Each commit in the pull request should have a meaningful subject line and body.
• [x] If you're unsure, you can format the pull request title like [CAMEL-XXX] Fixes bug in camel-file component, where you replace CAMEL-XXX with the appropriate JIRA issue.
• [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [x] Run mvn clean install -Psourcecheck in your module with source check enabled to make sure basic checks pass and there are no checkstyle violations. A more thorough check will be performed on your pull request automatically. Below are the contribution guidelines: https://github.com/apache/camel/blob/main/CONTRIBUTING.md

Fixes https://issues.apache.org/jira/browse/CAMEL-18860

Motivation

To ease the native compilation of routes written using the Java DSL, we need to adapt the code to be able to reuse some parts of the existing code.

Modifications

• Move the reusable methods asClassName and determineName to a helper class
• Allow providing compilation options when compiling to give the ability to set the classpath
• Fix some violations

[camel-bean] Problem when parameter type of bean method is String. Problems with more than 2 parameters.

Expression to evaluate the bean parameter parameters and provide the correct values when the method is invoked.

There are several problems:

1. There is a problem with quotes being removed in the splitSafeQuote method used inside the evaluate method. splitSafeQuote("'Camel', 'Test'", ",", true) -> ["Camel","Test"]
2. The quote is removed and false is returned from the isValidParameterValue method. isValidParameterValue("Camel") -> return false
3. When “ClassLoader” is working which make thread blocked it caused by Disk I/O. So it behavior make that performance deteriorates.

This PR also adds TestCase.

Trying to add SSLContext option to AS2Configuration.

I added a new SSLContext field to AS2Configuration class and got "Unable to create mojo: Empty doc for option: sslContext, parent options: " error while compiling. Following the contribution page, I have already added javadoc comment before the setter method (didn't see it before any getter method of other fields so skipped it for getter) and @UriParam for the field declaration.

(I had written code for adding the SSLContext configuration at component and endpoint level, but keeping the code minimal here. Also changed SSLContext to a String. Getting the same error though)