I am currently deploying multiple application instances through the FabricClient. A simple implementation of this would be:
var appDesc = new ApplicationDescription(new Uri(appName), appType, appVersion);
await fabricClient.ApplicationManager.CreateApplicationAsync(appDesc);
Whenever this code is executed the new application is started with its default parameters. It is possible to add name value pairs to the ApplicationDescription through its constructor. I would prefer to use the ApplicationParameters.xml files however. Is there a way to specify the new application to use an ApplicationParameters.xml file for its parameters?
Try creating the application with the ApplicationDescription(Uri, String, String, NameValueCollection) overload.
The last parameter is the list of parameters passed to the application.
Related
im using
integration toolkit for each external system ... externalService
definition, Servers registation datas, ENV refers the J2C creds to use, datamapping, bussines-errors handling etc.
(Bussines-Layer TK ex. TK_SAP)
for the common functionality such as logging, tokenizing,
pseudomizing, common http-error handling i want to use another one
toolkit (Generic implementation for Transport-layer ex. TK_COM).
So its looks like this dependicies chain:
ProcessApp -> TK_SAP -> TK_COM
There is the serviceFlow with inputs externalServiceName, operationName and a serviceFlow ask for oAuth-token and call to target system using externalServiceName, operationName.
The problem is - when i try to invoke the BPMRESTRequest from TK_COM, i get NullPointerException because "externalServiceName" cant be resolved.
var request = new BPMRESTRequest();
request.externalServiceName = "language-translator-v2";
request.operationName="checkout";
...
var response = tw.system.invokeREST(request);
is it possible to store service definition in another TK (upper) and refer it from Toolkit-invoker?
Or is there callbacks for BPMRESTRequest-Construct to say which ServiceDefinition must be used and avoid NPE.
Or another way to call Rest programmaticaly supporting Environments.
Im understand that switching the layers can help (serviceDefinition in lower TK-dependency), but it unlogisch is:
ProcessApp -> TK_COM -> TK_SAP
the answer is: JS-lib implementation.
Implementing common functionality as JS-Server-file in TK_COM makes that a call to it from TK_SAP will instatiate JS-execution context in the TK_SAP namespace so all defined in TK_SAP externalServices and variables will be accesible by executing of JS-code (actualy provided by lower-dependency Toolkit)
I am looking to open up multiple connections using a netty client bootstrap in order to parse messages coming from multiple sources. The messages all have the same format, however, due to the amount of data that needs to be processed, I must run each connection on separate threads (This is assuming netty creates a thread per client channel, which I couldn't find a reference for - if that's not the case, how would this be achieved?).
This is the code that I use to connect to the data server:
var b = new Bootstrap()
.group(group)
.channel(classOf[NioSocketChannel])
.handler(RawFeedChannelInitializer)
var ch1 = b.clone().connect(host, port).sync().channel();
var ch2 = b.clone().connect(host, port).sync().channel();
The initializer calls RawPacketDecoder, which extends ReplayingDecoder, and is defined here.
The code works well without #Sharable when opening a single connection, but for the purpose of my application I must connect to the same server multiple times.
This results in the runtime error #Sharable annotation is not allowed pointing to my RawPacketDecoder class.
I am not entirely sure on how to get past this issue, short of reimplementing in scala an instantiable class of ReplayingDecoder as my decoder based directly on ByteToMessageDecoder.
Any help would be greatly appreciated.
Note: I am using netty 4.0.32 Final
I found the solution in this StockExchange answer.
My issue was that I was using an object based ChannelInitializer (singleton), and ReplayingDecoder as well as ByteToMessageDecoder are not sharable.
My initializer was created as a scala object, and therefore a single instance allowed. Changing the initializer to a scala class and instantiating for each bootstrap clone solved the problem. I modified the bootstrap code above as follows:
var b = new Bootstrap()
.group(group)
.channel(classOf[NioSocketChannel])
//.handler(RawFeedChannelInitializer)
var ch1 = b.clone().handler(new RawFeedChannelInitializer()).connect(host, port).sync().channel();
var ch2 = b.clone().handler(new RawFeedChannelInitializer()).connect(host, port).sync().channel();
I am not sure whether this ensures multithreading as wanted but it does allow to split the data access into multiple connections to the feed server.
Edit Update: After performing additional research on the subject, I have determined that netty does in fact create a thread per channel; this was verified by printing to console after the creation of each channel:
println("No. of active threads: " + Thread.activeCount());
The output shows an incremental number as channels are created and associated with their respective threads.
By default NioEventLoopGroup uses 2*Num_CPU_cores threads as defined here:
DEFAULT_EVENT_LOOP_THREADS = Math.max(1, SystemPropertyUtil.getInt(
"io.netty.eventLoopThreads",
Runtime.getRuntime().availableProcessors() * 2));
This value can be overriden to something else by setting
val group = new NioEventLoopGroup(16)
and then using the group to create/setup the bootstrap.
I'm using the packaged app version of Postman to write tests against my Rest API. I'm trying to manage state between consecutive tests. To faciliate this, the Postman object exposed to the Javascript test runtime has methods for setting variables, but none for reading.
postman.setEnvironmentVariable("key", value );
Now, I can read this value in the next call via the {{key}} structure that sucks values in from the current environment. BUT, this doesn't work in the tests; it only works in the request building stuff.
So, is there away to read this stuff from the tests?
According to the docs here you can use
environment["foo"] OR environment.foo
globals["bar"] OR globals.bar
to access them.
ie;
postman.setEnvironmentVariable("foo", "bar");
tests["environment var foo = bar"] = environment.foo === "bar";
postman.setGlobalVariable("foobar", "1");
tests["global var foobar = true"] = globals.foobar == true;
postman.setGlobalVariable("bar", "0");
tests["global var bar = false"] = globals.bar == false;
Postman updated their sandbox and added a pm.* API. Although the older syntax for reading variables in the test scripts still works, according to the docs:
Once a variable has been set, use the pm.variables.get() method or,
alternatively, use the pm.environment.get() or pm.globals.get()
method depending on the appropriate scope to fetch the variable. The
method requires the variable name as a parameter to retrieve the
stored value in a script.
I'm trying to do some logic in my Spring controller where I route to a website node based on the template used in another website node.
I can use LifeTimeJCRSessionUtil.getHierarchyManager("website").getContent("mynodepath").getTemplate() to do this, but I see that the HierarchyManager and Content classes are depreciated.
I looked at the Session class, but I have thus far been unable to figure out how to get the Template id based on the jcrNode.
You can use instead:
javax.jcr.Session jcrSession = LifeTimeJCRSessionUtil.getSession("website");
Node mynode = jcrSession.getNode("/my/node/path");
info.magnolia.cms.core.MetaData metaData = info.magnolia.jcr.util.MetaDataUtil.getMetaData(mynode);
String template = metaData.getTemplate();
Basically, instead of getHierarchyManager("website").getContent("mynodepath") you should use
getSession("website").getNode("/my/node/path").
In my project, there are additional (non-wicket) applications, which need to know the URL representation of some domain objects (e.g. in order to write a link like http://mydomain.com/user/someUserName/ into a notification email).
Now I'd like to create a spring bean in my wicket module, exposing the URLs I need without having a running wicket context, in order to make the other application depend on the wicket module, e.g. offering a method public String getUrlForUser(User u) returning "/user/someUserName/".
I've been stalking around the web and through the wicket source for a complete workday now, and did not find a way to retrieve the URL for a given PageClass and PageParameters without a current RequestCycle.
Any ideas how I could achieve this? Actually, all the information I need is somehow stored by my WebApplication, in which I define mount points and page classes.
Update: Because the code below caused problems under certain circumstances (in our case, being executed subsequently by a quarz scheduled job), I dived a bit deeper and finally found a more light-weight solution.
Pros:
No need to construct and run an instance of the WebApplication
No need to mock a ServletContext
Works completely independent of web application container
Contra (or not, depends on how you look at it):
Need to extract the actual mounting from your WebApplication class and encapsulate it in another class, which can then be used by standalone processes. You can no longer use WebApplication's convenient mountPage() method then, but you can easily build your own convenience implementation, just have a look at the wicket sources.
(Personally, I have never been happy with all the mount configuration making up 95% of my WebApplication class, so it felt good to finally extract it somewhere else.)
I cannot post the actual code, but having a look at this piece of code will give you an idea how you should mount your pages and how to get hold of the URL afterwards:
CompoundRequestMapper rm = new CompoundRequestMapper();
// mounting the pages
rm.add(new MountedMapper("mypage",MyPage.class));
// ... mount other pages ...
// create URL from page class and parameters
Class<? extends IRequestablePage> pageClass = MyPage.class;
PageParameters pp = new PageParameters();
pp.add("param1","value1");
IRequestHandler handler = new BookmarkablePageRequestHandler(new PageProvider(MyPage.class, pp));
Url url = rm.mapHandler(handler);
Original solution below:
After deep-diving into the intestines of the wicket sources, I was able to glue together this piece of code
IRequestMapper rm = MyWebApplication.get().getRootRequestMapper();
IRequestHandler handler = new BookmarkablePageRequestHandler(new PageProvider(pageClass, parameters));
Url url = rm.mapHandler(handler);
It works without a current RequestCycle, but still needs to have MyWebApplication running.
However, from Wicket's internal test classes, I have put the following together to construct a dummy instance of MyWebApplication:
MyWebApplication dummy = new MyWebApplication();
dummy.setName("test-app");
dummy.setServletContext(new MockServletContext(dummy, ""));
ThreadContext.setApplication(dummy);
dummy.initApplication();