MULE ESB 3.3 - Your java component reading properties from a property file

The problem:

I had a mule XML configuration file defining some property files that is loaded by mule container, like this:
<context:property-placeholder location="classpath:my-mule-app.properties,classpath:my-mule-app-override.properties" />
and I I had a java component that need to read the value of  a property called jbc.url. That property is on my my-mule-app.properties.



Ok, I am pretty sure there are a few other ways to solve this problem but I came up with a very simple solution for that so I want to share (besides that, several ways that I found on the web did not work for me, including using @Value from Spring or using the registry from muleContext).

Anyways, here is what worked:


This is what I had to add on the flow file configuration file when declaring my java component:


<component doc:name="AgeHandler">
<singleton-object class="com.citi.isg.java.components.AgeHandler">
<property value="${jdbc.url}"
key="jdbcUrl" />
</singleton-object>
</component>

And this is a sniped of my AgeHandler.java:


public class AgeHandler {

private String jdbcUrl;

 public void setJdbcUrl(String url) { this.jdbcUrl = url; }

.....

}


That is all you need. Mule/Spring will invoke setJdbcUrl when the component is called to perform the injection of the property jdbc.url into the local field jdbcUrl.

Good luck!



Comments

Post a Comment

Popular posts from this blog

Logging in Mule

I don't like wrapping well stablished frameworks to add little to no functionality. It does not sound right. Creating wrappers around log4j is the most common example of this awful practice. It is just a dragging thing that we should all avoid. My point is: if it is simple and it works, just live it alone. After all, the best code you can ever write is the code you did not write! So, most of my Mule applications rely solely on bare Log4j for logging. The below is a collection of some of the best log4j practices I have been using for awhile in my Mulesoft applications. One log file per application Each application logs to its own log files. That is, only the errors thrown by a application are allowed to be written on the main mule console or default log files. Everything else is on the application log file. Therefore, each application have its own appender and logger: ...     <Appenders>         <RollingFile name="file" fileName="${sys:mule.h
Read more

Enterprise Integration Patterns applied in Mule - Dead Letter Channel

Overview This post explains how to use Mule with RabbitMQ AMQP Connector with Dead Letter queues. The Sample code can be easily adapted to other Message Brokers. The Problem We have a Mule application consuming messages from a Message Broker and pushing those messages to a database table. The database server becomes temporally unavailable returning ConnectExceptions. How to save that message that failed to be delivered so it can be reprocessed later when the target system is back? How to retry delivering the same message to the target system before giving up? How to wait between each retry, avoiding overflowing the target system with requests that will most likely fail? Introducing the Dead-letter Channel Integration Pattern This pattern gives the consumer applications an opportunity to reprocess the same message several times. If a final retry also fails, the message is forwarded to an auxiliary queue for further manual intervention. Being selective on the errors we wan
Read more