I have configured proxy with following xml:
<parameter name="transport.vfs.FileURI">vfs:file:///data/queues/documents-validation</parameter>
But I would like to use something more manageable than hard coded value. Maybe something like
<parameter name="transport.vfs.FileURI" expression="get-property('source.uri')" />
Any suggestions would be appreciated.
I asked myself the same questions a couple of weeks. Unfortunately there's no way to achive this when you want to pick up files. I was told that this will work in version 4.9.
If you want to have this when you write files than this is no problem. You just need to set the 'to' header parameter and then call the send mediator.
Example:
Regards
Martin
Related
Is there a way in mule to specify a configuration reference dynamically?
instead of having:
<a:connector config-ref="the_config_name" other-properties="here" />
Something like the following?
<a:connector config-ref="#[flowVars.configName]" other-properties="here" />
This is needed because the configuration used has some properties (URL) that does not allow dynamic values since they are instantiated at the start of the mule app.
No, config-refs are static. Instead, configurations themselves can be dynamic in Mule 4. This requires special handling of the parameters so that then can be re instantiated per configuration.
For more information on this, you can take a look here.
I have recently become aware of Confluence's servlet-filter module. However, after trying to get it to work, I have run into a dead end. I am getting my information here:
https://developer.atlassian.com/confdev/confluence-plugin-guide/confluence-plugin-module-types/servlet-filter-module
Here is what I tried. I annotated my atlassian-plugin.xml file like so:
<servlet-filter name="My Test Filter" key="OURAPP" class="com.test.filters.HelloWorldFilter" location="after-encoding" weight="100">
<description>Forwards you to a test "Hello, world!" page.</description>
<url-pattern>/helloworld</url-pattern>
<dispatcher>REQUEST</dispatcher>
</servlet-filter>
Then, I created a standard Java servlet (extends HttpServlet, etc.) at com/test/filters called HelloWorldFilter.java. In the "doGet()" method, I simply have a System.out.println() line that reads "IN THE FILTER". However, when I go to the following URLs, I always get the "Page Not Found" error page:
http://127.0.0.1:8090/helloworld
http://127.0.0.1:8090/OURAPP/helloworld
http://127.0.0.1:8090/plugins/OURAPP/helloworld
http://127.0.0.1:8090/rest/helloworld
http://127.0.0.1:8090/rest/OURAPP/helloworld
http://127.0.0.1:8090/OURAPP/rest/helloworld
We have a custom Confluence plugin, lets call it OURAPP, that is serving up data not only through the browser GUI, but also through Confluence's REST capabilities. I am trying to create a filter that manages valid and invalid requests alike. We can access the REST at:
http://127.0.0.1:8090/rest/reststuff/v1/some_function_here
Like I said in the beginning, I have run into a dead end here, and cannot figure out how to get this to work. Can anybody offer up any suggestions or example code of how to get this working?
After a couple of days messing around with this, I FINALLY figured out what was wrong. I was extending javax.servlet.http.HttpServlet instead of implementing javax.servlet.Filter. After I changed to implementing Filter, and implemented all the proper methods, my servlet filter started to work at 127.0.0.1:8090/helloworld. There are a number of examples out there that use a standard Java Servlet (i.e., extending HttpServlet) but that [apparently] does not work with Confluence. I hope this helps somebody else out there struggling with Confluence's confusion. Thanks to all who took the time to read.
Your dispatcher tag is missing the closing ">":
<dispatcher>REQUEST</dispatcher
Regards,
Gorka
I am doing some work using the NCQRS frameworks and NServiceBus 3.3.4. I have been struggling with getting some subscriptions to fire and as far as I can tell all my config is 100% correct.
After some digging I noticed that the MessageType name saved in the subscription document in Raven DB looks a bit odd. The NCQRS framework wraps the domain event in a generic typed named EventMessage'1. Now when that message is saved in the scubscription store it seems to chop off part of the name, see below:
Ncqrs.Nsb.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Version=1.0.0.0
Where I would expect the name to be more along the lines of this:
Ncqrs.Nsb.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Version=1.0.0.0]]
At the very least.
Could this be a bug or am I doing something wrong? My subscriptions in the app.config appear as follows:
<add Messages="Ncqrs.NServiceBus.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Platform.Events]], Ncqrs.NServiceBus" Endpoint="core.platform.domain" />
It's making me crazy!
This is not a bug, NServiceBus won't support this since we want to push you into using more explicit message contracts. Perhaps there is a way to configure NCQRS not to require that "EventMessage" thingy?
I've been playing with Spring integration, and I can't see how best to solve the following problem.
Say I have XML messages arriving onto a channel. These messages may have arbitrary structure, and I want to convert them to my canonical form, so I think I want to write custom converters for each type of structure, so that I can do whatever processing and error-checking I want.
The obvious thing is to wire up a router to have a look at the messages and route to an appropriate converter, but I think this means I need to hard-code the processing flow onto a channel pointing at each converter.
I'd like to avoid hard-configuring in the different converters and routing logic, and the alternative that springs to mind is to have a set of converters that implement some kind of boolean canHandle(message), so that we just show the message to each converter until one 'claims' the message or we run out. This way, it seems like I might be able to annotate the converters into the configuration without actually modifying the processing flow.
I'm new to Spring integration and I may well be mis-thinking this. Is there a stock way to do this in Spring integration, have I missed something or am I going about it all wrong?
There are a number of ways to do this. The first one that came to mind is a recipient list router with selector expressions:
<recipient-list-router id="simpleDynamicRouter" input-channel="simpleDynamicInput">
<recipient selector-expression="#handler1.canHandle(payload)" channel="toHandler1"/>
<recipient selector-expression="#handler2.canHandle(payload)" channel="toHandler2"/>
<recipient selector-expression="#handler3.canHandle(payload)" channel="toHandler3"/>
</recipient-list-router>
<transformer ... ref="handler1" />
<transformer ... ref="handler2" />
<transformer ... ref="handler3" />
Where handler1 etc are <bean/>s with your implementation, and canHandle() method.
Another option is to write your own custom dynamic router; there's an example of how to do that here https://github.com/SpringSource/spring-integration-samples/tree/master/advanced/dynamic-ftp
I have an Opera 11 extension, which has a background process and an injected script. These communicate very frequently with a remote server (not the webpage the user's viewing), using the background script's cross-site XMLHttpRequest capabilities.
I would like the URL of the server to be a preference, so that it can be modified by the user without editing the package. The config.xml file would good, for it accepts <preference name="serverUri" value="..." />. However, I would like the script to be able to update itself directly from the server (not through Opera's site), which can be achieved using <update-description href="http://myserver.com/client/update" />.
So what I would like to do is have the href attribute of the update-description element to be dependent on the value of the preference serverUri. I would imagine some syntax like this:
<update-description href="{$serverUri}" />
But I could not find any references to this kind of functionality. Is there some way to solve this?
It's not possible to use variables in the config.xml file as you've written and I don't think there are plans to add this.
I'm sure you know that preferences can be set not just with the preference element in config.xml but also using widget.setPreferenceForKey(value, key), but I don't think that solves your problem in this case.
The only workaround I can think of is if you have all your logic in an external script on your server and in your extension's local files (background script or injected script), just have a very simple couple of lines that reference your external script. Something like:
var script = document.createElement('script');
script.src = 'http://www.example.com/script.js';
document.body.appendChild(script);
You could then make the script's URL editable by the user and store it in widget.preferences.
EDIT by hallvors: This solution has serious drawbacks, see my comment below.
As far as I know this is not currently possible. It seems like a bit of an unusual use case, which could potentially be risky to implement, so it would be interesting to hear more about why you want to do this.