Details
-
Task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
-
Unknown
Description
Multiple components have overlapping functionality and/or duplicated logic that could possibly be consolidated into abstract platforms. These abstract platforms would provide a reusable interface for components handling things as:
- HTTP clients
- HTTP servers
- WebSocket servers
- JMS clients
- Messaging
- Servlet containers
- Socket-based I/O
- Web Services frameworks
Concrete example:
For instance, the Telegram component:
- In Camel version 3.18x, it allowed the users to provide a custom AsyncHttpClient through the `client` parameter.
- In Camel version 3.19.x and newer, the `client` parameter changed to use the Java's own HTTP client (due to
CAMEL-18506).
With a core platform, instead of using a concrete client, it would use an abstract HTTP platform that would provide the functionality required for the component.
Among other things, this would prevent situations such as the one we now have with Whatsapp and Telegram components, where both implement their own HTTP multi-part body handling logic on top of the Java's HTTP client.
Benefits:
- Reduce duplicated code
- Increase testability and test coverage
- Increase flexiblity by allowing users to implement their own pluggable platforms if they wish
- Increase flexiblity for Camel to decouple from legacy platforms and projects