What is a standart way of passing properties to a custom action without parsing them? I mean if I write "X1=X1value X2=X2value", then in my custom action X1 will be equal to "X1value X2=X2value", and X2 won't exist as a separate property. So what is the properties string format?
I don't know that there is a "standard" for serializing and serializng CustomActionData. There are a couple libraries out there though. If you happen to be using C# DTF custom actions there is a CustomActionData class that can serialize and deserialize the property collection for you. Otherwise you pretty much come up with your own pattern like:
/PROPERTYA=VALUEA /PROPERTYB=VALUEB
or
PROPERTYA=VALUEA;PROPERTYB=VALUEB
Or even an XML fragment like
<Properties>
<Property Id="PROPERTYA">VALUEA</Property>
<Property Id="PROPERTYB">VALUEB</Property>
</Properties>
The point is to serialize and deserialize so that it can be available to your deferred CA.
Related
I would like to know what would be the best way to load the properties file in mule for the following scenario.
I have a properties file where in I set all the email related fields set in it like templates, to and from etc.
All these need to be set to a specific object along with other changes to that object so I'm planning to use a Java transformer and now I need to load all those values from that properties file and send to transformer. So what would be a best approach to work in above scenario.
Load properties in Java transformer using core java load properties
Load properties using spring context and send it to transformer and access using inbound properties
Kindly let me know if there is any other better approach other than above
First, you should be able to load the property file using spring context as shown below:
<context:property-placeholder location="somename.properties" />
Then, you can set specific property value as flow variable as shown below:
<set-variable variableName="fromAddress" value="${xyz.fromAddress}" />
Finally, you can access this flow variable in your processor class as shown below:
String fromAddress = muleEvent.getFlowVariable("fromAddress");
I will suggest to use Java load properties if these properties are only used in one Transformer. There is one more benefit out of Java load properties is that after modifying your properties file you do not need to restart the application.
I have a properties file shared on several apps. To access this properties into one app, I use this tag:
<context:property-placeholder location="classpath:br/com/empresa/configuracao/mule-apps.properties"/>
On several Mule components, like database attributes connections, I use the following expression to access the properties, p.e.: ${db.user}. It works!
But on Java Transformer, how I access the properties?
I tried the following instructions, but returned null:
System.getProperty("db.user");
message.getInboundProperty("db.user");
message.getOutboundProperty("db.user");
message.getInvocationProperty("db.user");
Is there a way to access properties into Mule Java Transformer?
This question has been answered for components here: How to get property from context property placeholder tag inside custom java component The exact same logic applies to transformers.
Use property injection:
<custom-transformer class="org.myCompany.CustomTransformer">
<property name="dbUser" value="${db.user}" />
</custom-transformer>
Don't forget to add setDbUser on your custom component!
You could use the old way of retrieving a property:
#Value("${db.user")
private String dbUser;
I need to set the global property grammatically. Functionally it should do exactly what the following statement should be doing
<global-property name="host-name" value="localhost" doc:name="Global Property"/>
I believe I should be able to access this property using ${host-name}. In this specific scenarion I don't want to load the property from properties file.
If you just want to resolve placeholders like ${host-name} you can extend the Spring PropertyPlaceholderConfigurer class with a custom implementation of method resolvePlaceholder, and add it as a Spring bean like this:
<spring:beans>
<spring:bean id="myConfigurer" class="my.test.MyConfigurer"/>
</spring:beans>
Your custom resolvePlaceholder is then called to resolve any unresolved properties.
It is also fairly simple to set actually set properties in the Mule context registry by getting the context from a message (message.getMuleContext()) or by implementing a MuleContextAware bean, but in those cases the property will not yet be available at the time when the property placeholders are resolved.
You would set the property like this:
context.getRegistry().registerObject("myKey", "myVal")
and access it later like this:
context.getRegistry().get("myKey")
I created a Web API using VS 2012. I have a method with a custom object parameter that I am passing JSON to via Fiddler for testing:
[HttpPost, HttpPut]
public HttpResponseMessage UpsertProject(Projects p)
{
...
}
My Projects object has about a dozen properties marked as JsonIgnore. My assumption was that when my object was serialized into Json those properties would be ignored...which is true. However, when I debug my method I'm noticing that all the object properties marked with JsonIgnore are set to null even if the Json that I pass in from Fiddler is setting them. I also try to get data as Json and deserialize it into a new instance of the object but that also does not set the properties that are marked JsonIngore. I knew JsonIgnore would work for serializing but didn't think it would prevent properties from being set when deserializing. What's frustrating is I know that ScriptIgnore doesn't behave this way, but I want to use JSON.net to handle my serializing/deserializing. I've also created a windows app and tested the same serializing/deserializing functionality and it works in it. So I'm wondering if this is a Web API limitation with the JsonIgnore attribute?
If it works the way you want in the Windows application but not in the Web API, that tells me that the JSON serializer settings are different between the two. What settings are you using in the Windows app that makes it work? You can take those settings and apply them to the Web API serializer in the Register method of the WebApiConfig class (in the App_Start folder of your Web API project). For example:
JsonSerializerSettings jsonSettings = config.Formatters.JsonFormatter.SerializerSettings;
jsonSettings.NullValueHandling = NullValueHandling.Ignore;
jsonSettings.DefaultValueHandling = DefaultValueHandling.IgnoreAndPopulate;
...
EDIT
OK, so if I understand you correctly, based on your most recent comments, you want everything to be deserialized if possible, but you only want two specific properties to be serialized and those apparently do not have null or default values. In that case, there are two approaches you can take:
Set the properties that you don't want serialized to null or zero or false (the default value) just before serializing. Because you have DefaultValueHandling set to Ignore, this will cause those properties not to be serialized.
Create several boolean ShouldSerializeXXX() methods in your class where XXX is the name of each property you don't want serialized. These methods should return false. See the first answer of this question for an example.
Don't use JsonIgnore because, as you have seen, this will cause the property to be completely ignored by Json.Net, both for serializing and deserializing.
I am interested in the best practice of the following scenario. I have a CustomAction method that hits a web service and returns some information that I use to populate a combo box. Later in the install process in another CustomAction method, I need to access some of the meta data returned from that first web service call.
In the first method, I create a List that is a public static member of my CustomAction class. In my second method when I access the list its empty.
My thoughts were to serialize it using xaml serialization into a session variable then deserialize it in my second method.
Am I way off here? Is there a better way?
I will assume that your second custom action is making configuration changes to the machine and running in the execute sequence as deferred with no impersonation. This means it can only access the CustomActionData property.
This means your first custom action will have to serialize the CustomActionData property for the second one to deserialize. Now the CustomActionData is a Key:Value collection and what you do with it ( including have a Key with a Value that is yet another serialized datatype ) is completely up to you.
Be sure to read the DTF documentation to understand how to use the CustomActionData type and members off the Session class to your advantage.