wildfly-extras / wildfly-camel Goto Github PK

There should be a separate project that provides all the modules that are shared with switchyard

It is planned to integrate insight-camel from Fabric8 as a portable component that runs on Gravia. Storage is delegated to elastic search. Hawt.io plugin via Kibana

The cdi-api in eap-4.2 cannot be upgraded. Instead, we try downgrade the camel-cdi implementation

Dynamic provisioning is not a primary goal. We can hard wire all supported camel components

Currently there is a CamelContextRegistry which provides a view of contexts that were deployed to wildfly. It does not see contexts that were created through the DSL nor CDI contexts

Currently, there is a webapp deployed as part of the subsystem that contains

• camel-cdi
• deltaspike-core-api
• deltaspike-core-impl
• deltaspike-cdictrl-api

Same is true for the the CDIIntegrationTest.

In both cases I would like to replace these embedded jars with references to the already existing modules.

WildFly Issue: https://issues.jboss.org/browse/WFLY-4009

Verify that the camel-cdi component integrates with our cdi subsystem and that it actually works when a cdi/camel deployment gets processed by our DUPs. When such a thing gets deployed, the camel context and its associated routes must work with the components all wired together. I suspect there is work to be done at the DUP level.

https://issues.jboss.org/browse/WFCAM-11

The packaging of test deployments and server startup options differ depending on whether the subsystem is installed or not.

For example, with the camel subsystem (CSS) in place we cannot package the camel-cdi component with the CDI example WAR

We currently support camel system context definitions like this

<subsystem xmlns="urn:jboss:domain:camel:1.0">
      <camelContext id="system-context-1">
        <![CDATA[
        <route>
          <from uri="direct:start"/>
          <transform>
            <simple>Hello #{body}</simple>
          </transform>
        </route>
        ]]>
      </camelContext>
   </subsystem>

WildFly is moving towards a provisioning system based on feature packs. This is also important for a container based approach like wildfly-swarm

For this to work, smartics would need to be directed to generate modules.xml files that contain

<artifact name="${org.hibernate:hibernate-core}"/>

instead of

<resource-root name="hibernate-core-1.2.3.jar"

For details see Wildfly Build Process

We have a camel-cdi example that works on 8.1.0.Final, but not on 9.0.0.Alpha1.

WildFly Issue: https://issues.jboss.org/browse/WFLY-4046

To reproduce, build https://github.com/wildflyext/wildfly-camel/tree/2.0

The cxf-rt-frontend-jaxrs has a non-optional dependency on blueprint, which we don't want to bind to at the moment.

Cross-Ref: https://issues.apache.org/jira/browse/CXF-5082

We currently support camel system context definitions like this

   <subsystem xmlns="urn:jboss:domain:camel:1.0">
      <camelContext id="system-context-1">
        <![CDATA[
        <route>
          <from uri="direct:start"/>
          <transform>
            <simple>Hello #{body}</simple>
          </transform>
        </route>
        ]]>
      </camelContext>
   </subsystem>

This uses a substitution hack for $

http://camel.apache.org/bindy.html