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.

Fixes CAMEL-5963 via adding a new producer specific uri param so called messageReceiverRouteId which is however optional and so backward compatible (i.e. if not set then previous TX behavior will be seen exactly as before). If set then the user wouldn't define a corresponding redundant consumer. Camel will use the specified route above as corresponding consumer - internally it uses one and same SmppSession as producer. Example:

                from("direct:start")
                        .to("smpp://j@localhost:8056?password=jpwd&systemType=producer" +
                            "&messageReceiverRouteId=testMessageReceiverRouteId");

                from("direct:messageReceiver").id("testMessageReceiverRouteId")
                        .to("mock:result");

CamelContext startup would fail in the first place on a wrong messageReceiverRouteId value via registering a StartupListener when no route can be found for the specified id. This has integrated tested in org/apache/camel/component/smpp/integration/SmppTRXProducerIT.java

NOTE: When user's SMPP Server doesn't support TRX, still possible and she/he has to define separate producer (TX by default) and consumer (unchanged and RX by default) as before.

[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)

WIP do not merge!

This PR is supposed to be a work in progress seeking for guidance and help on implementing multiple data types on components feature as described in https://issues.apache.org/jira/browse/CAMEL-18698

The changes made in this PR should be seen as a POC starting some discussions and refinements of the feature.

The idea is to let the user choose a specific data type that the component is producing as an output. The component itself may offer specific data transformation logic that gets automatically triggered when this data type is explicitly used on an endpoint URI:

from("kafka:topic?format=avro").to("aws2-s3:bucketName?format=string")

The format option tells the component to apply the specific data type as an input or output. The data type may be directly supported by the component or it may be a generic data type that makes use of the Camel TypeConverter logic to transform from one data to another.

In the PR the feature is implemented as a POC for aws2-ddb and aws2-s3 components. The aws2 components often use Java POJO domain objects as input and output so the user needs to know the domain model when interacting with the components.

The idea is to also add support for more generic data types on these components. As an example the user may also provide a generic Json structure as an input instead of the AWS domain object. The component takes care on transforming the data type to the required Java POJO used in the AWS client libraries.

On the output side the aws2-s3 component by default produces byte[] or InputStream output. With the addition of data types the user is able to request another data type such as String. The component makes sure to apply transformation logic from the AWS domain model InputStream implementation to a String.

This feature is beneficial for Camel users that do not have to know about domain specific Java types anymore. Also declarative Camel DSL use cases e.g. used in Camel K and Kamelets benefit from the auto data type conversion as discussed in https://github.com/apache/camel-k/issues/1980

A Kamelet may use the provided data types information and expose this as part of the Kamelet specification.

apiVersion: camel.apache.org/v1alpha1
kind: Kamelet
metadata:
  name: aws-s3-source
spec:
  definition:
    title: "AWS S3 Source"
  properties:
    ...
  types:
    out:
      default: binary
      binary:
        mediaType: application/octet-stream
      stream:
        mediaType: application/octet-stream
      json:
        mediaType: application/json
        schema:
          type: object
          required:
            - key
            - fileContent
          properties:
            key:
              title: Key
              description: The S3 file name key
              type: string
            fileContent:
              title: Content
              description: The S3 file content as String
              type: string
        dependencies:
          - "camel:jackson"
      string:
        mediaType: plain/text
      avro:
        mediaType: application/avro

Also the user is able to choose the input/output data type in a binding:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: aws-s3-uri-binding
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: aws-s3-source
    output:
      type: avro
      schema:
        uri: http://schema-registry/person
    properties:
      outputFormat: avro
      bucketNameOrArn: ${aws.s3.bucketNameOrArn}
  sink:
    uri: log:info

The new data types implementation provided in this PR use a specific SPI annotation @DataType. A resolver mechanism DefaultDataTypeResolver is capable of doing a lookup of the respective data type implementation with given component scheme and a format name that identifies a data type.

The PR definitely needs more polishing and has some ToDos in the code that seek for guidance and help how to do it the Camel way (e.g. how to do an automatic resource lookup for data type implementations provided by components).

Also it would be nice to have some guidance on the already existing org.apache.camel.spi.DataType and how that could be related to this implementation.

Many thanks in advance!

Note that groupid of Maven artifact has been modified but not old package names. Thus some package named org.apache.groovy.* have been created.

it requires to upgrade Spock to a Milestone version.

locally launched tests successfully for:

• component camel-groovy
• component camel-grape
• camel-catalog
• camel-groovy-dsl