Currently, we are able to use #Property(unbounded=PropertyUnbounded.ARRAY) to create a property in OSGi Configuration with Multiple-Values.
Is it possible to create a property in OSGi Configuration that behaves same as that of multifield functionality of AEM authoring dialogs? On click of Add button, the property field with all its-sub fields gets increased. So that we can add multiple entries of key/value pair.
[
{
"path":"/content/demo/page1",
"date":"20-12-2018",
"language":"english"
},
{
"path":"/content/demo/page2",
"date":"23-10-2019",
"language":"french"
}
]
The same key/value pair to be configured using OSGi Configuration and fetched as required.
The felix console allows you to add multi-value properties. however, they are typically a single field value. Meaning, you cannot create the complex data structure in your question. However, I have seen implementations that allowed you to enter an ordered CSV. For example, you could have a multivalued String OSGI property where each property is of the format:
<path>,<date>,<language>
your first entry then becomes:
/content/demo/page1,20-12-2018,english
Or, you could even enter the whole JSON as a string value, then parse it when you need it. But that becomes ugly to enter very quickly.
You can use the above with any serializable data structure, but the more complex it gets, the harder it is to enter in a single input field.
Another option would be to create a page with a component that has a multifield and just point your OSGI config to the path of that page/component, then in your OSGI service, lookup that path and extract the configuration.
Related
I am developing rest api update method for user profile resource user/profile. I am disappointed what http method should i use. Update contains some required attributes so it more PUT request, where client need to fill all attributes. But how it can extend attributes in future. If i will decide to add new attribute then it will automatically clear because client is not implement it yet.
But what if this new attribute has default value or is set by another route?
Can i use PUT with not stricting number of attributes and use old data if new isn't come in request. Or how it can be done normally?
HTTP is an application whose application domain is the transfer of documents over a network -- Webber, 2011.
PUT is the appropriate method to use when "saving" a new version of a document onto a web server.
how it can extend attributes in future.
You design your schemas to be forward and backward compatible; in practice, what this means is that you can add new optional elements with reasonable default values. When you need to add a new required element, you change the name of the schema.
You'll find prior art in this topic by searching XML literature for must ignore.
You understand correctly: PUT is for complete replacement, so values that you don't include would be lost.
Instead, use the PATCH method, which is for making partial updates. You can update only the properties you include values for.
Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.
Typically when I am making API calls I am using javascript (ajax). JSON doesn't include value types of properties, and so everything is passed as a string.
Since I manage my own API I create request-able models that will tell you the definition of a model.
For example Id value type is int, StartDate value type is date.
I use the property types to automate form creation.
Is there a standard as to how to do this? My way works, but I'd prefer to be doing this by the book if it already exists.
OpenAPI is a standard you could follow. If you also make use of Swagger, it will allow you to produce a JSON schema which can be used in generating forms.
The hard part is typings are done at compilation and JS does that in browser.
You could use a typing model agent such as graphQL that adds a definition for those types ahead of time. Those definitions can then be dynamically fetched and enforced using typescript and a tool like apollo.
If you dont want to use typescript or graphql you could use something like mongoose schema and expose the schema on an endpoint then have your front end rebuild the schema dynamically to check types by casting when creating new objects.
Personally ive done this old fashion way by writing my own form schema and enforce the form types strictly on the front end by interpreting the fieldTypes
// returned from API somewhere
const fields = [{
type: 'input',
name: 'firstName'
rank: 0,
validation: '/^[a-zA-Z\s]+$/'
}]
Edit:
Found this great library that exports typed interfaces based on graphQL models.
https://github.com/avantcredit/gql2ts
I want to post a message to a SOAP webservice with MULE Enterprise edition.
For creating the Request object i am using a data mapper with the
input a POJO and for
the output i selected XML , and from example XML schema i added my own XSD.
Because there are a lot of elements in the xsd, i selected the root element from the list provided.
Then i am dragging the fields from input to the corresponding values i want in the output.
(i also tried to map just one field, to be sure that i keep the minimum the probability for error).
And now the problem:
when the flow is accessed, the following WARN is shown and the data-mapper fails
*[XML WRITER:EXT_XML_WRITER0] - Invalid mapping (With port binded to root element, result might contain multiple root elements. Such XML is not well-formed. To avoid that, set 'Records per file' or 'Max number of records' component attribute to '1'.)*
Where can i set this kind of options in the data mapper ?
And also i want the root element to be only one, i don't need a foreach for the root element, i just need to fill the contents of it. Can i specify this anywhere in the data mapper ?
Thanks.
Mule EE DataMapper uses CloverETL for data transformations, and this annoying warning concerns CloverETL settings. I don't know if you can advise CloverETL to use a specific configuration file in the context of Mule DataMapper, but you can always edit the mapping file generated by Mule with a text editor. Just find your root Node entry in the mapping file and add recordsPerFile="1" attribute.
The problem with this is that Mule may overwrite your manual edits if you use the graphical editor, though.
Check out the Anypoint Studio May 2014. Mule now includes a new Web Service Connector for posting messages to a SOAP web service using just a WSDL. Studio will read the XML Schema from the WSDL and automatically create the metadata for DataMapper for you. See http://www.mulesoft.org/documentation/display/current/Web+Service+Consumer for more details.
I need to update the JSF2.0 (Primefaces) tooltips dynamically without server restart.
Meaning need to find a way where tooltips (atm from properties file) of the a running application can be changed without requiring a server restart.
We are running websphere and deploying a non exploded EAR (can probably convince to deploy exploded war)
Any Ideas or tips please. Thanks you
The value attribute of the p:toolTip component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using the var attribute of the f:loadBundle tag, in the EL expression for the tooltip.
The underlying resource bundle declared using the basename attribute could be backed by a property file itself (in which case you need to place the property file in the appropriate directory on the classpath), or for that matter it could be a custom ResourceBundle implementation that could read from a properties file (located outside the container), or a database or any store for that matter.
You could therefore change your existing EL expression from the existing one defined as:
<f:loadBundle var="msg" basename="propfile_location" />
to
<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />
In simpler words, you will need to roll your own ResourceBundle class(es) to support the various locales. Needless to state, but you will need to override the ResourceBundle.getObject(java.lang.String) method, as it is invoked by the ResourceBundleELResolver implementation when evaluating the EL expressions referencing ResourceBundles.
Additionally, you will need to ensure that the ResourceBundle.getObject(java.lang.String) implementation of your ResourceBundle will always re-fetch and return the value corresponding to the provided key. Failure to ensure this would mean that the initial value fetched by the resource bundle may be returned on subsequent invocations, especially if you are caching the initial value. You are likely to encounter this behavior even if you deploy an exploded WAR file where you can modify the property file contents without a redeployment of the application, and that is why it is important to use a custom ResourceBundle implementation that does not cache values.