In this post we’re going to continue the discussion started our last post “A sneak peek into Mule 3.7’s deepest internals” about how Mule’s registry, lifecycle and dependency injection mechanism are being overhauled in Mule 3.7. In this case, we’re going to take a deep dive into how we managed to unify the registries while keeping backwards compatibility and all the implications of such maneuvers.
Mule 3.7 is approaching, and among other things we decided to put a lot of focus on the experience of the guy coding custom components (Devkit based or not). For this, the first 3.7 milestone is incorporating big changes in terms of the how Mule Lifecycle and Dependency Injection are applied.
As I said, these changes are BIG, so for clarity reasons we’ll cover them in a series of post starting with this one.
We are all very proud to announce that Mule’s December 2013 release shipped with a major leap forward feature that will massively change and simplify Mule’s user experience for both SaaS and On-Premise users. Yes, we are talking about the new Batch jobs. If you need to handle massive amounts of data, or you’re longing for record based reporting and error handling, or even if you are all about resilience and reliability with parallel processing,
If you want to avoid including configuration parameters (probably connection related parameters) in your Mule configuration, you can use property placeholders, which will allow you to upload these parameters from a properties file. This enables you, for example, to have different property files for different environments (Dev, QA, Prod) or allows you to reuse the same value in different parts of your configuration.
When developing a Mule Application the normal way to define an SQL statement is by declaring it directly in the connector, as shown in the following snippet.
However is possible that you’ll face a situation in which you have to use large and complex queries. For that scenario the previous approach is not adequate since you’ll end up with a configuration difficult to read. So the best thing to do is to externalize these queries in one or more files.
Spring has become a highly popular framework for the development of web applications, thanks to a compelling support for web features, both at its core and within extensions modules. When it comes to deployment time, Spring shines again by its container agnosticism. Because Spring web applications are pretty much self contained, they can get deployed on any JavaEE container. With a plethora of containers available, picking one can be a daunting task.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.