here is a small tip that might be useful.
Make sure you do not only use dynamic endpoints but also generic endpoints!
Say you would like to expose a REST endpoint with an inbound HTTP/ HTTPS endpoint.
You do not want to use hard coded values anywhere? Great - dynamic endpoints backed with external properties or MEL expressions to the rescue!
But what if you are supposed to deploy the application to an embedded Mule ESB let's say in a JBoss container?
In that case you do not want Mule to spawn new HTTP/HTTPS servers for each endpoint within the JBoss container, you want to use the web container within JBoss when you deploy embedded but you still want to use HTTP/ HTTPS inbound enpoints when you run it standalone.
But how can we do that easily when Mulesoft documentation states that scheme/transport may not be generated dynamically?
Use generic endpoints instead!
It could be something like this:
for a connector:
As stated before, what you want to achieve here is the endpoint to be a http inbound server on standalone builds and a servlet endpoint using the web containers web server when using embedded build.
Your endpoint base address can now be set in your maven build sensitive mule properties files (again see
For standalone configuration the properties would be:
but for embedded builds it would be
VOILA! Dynamic and generic endpoint in action!