I'd like to control how many threads can be used by a web application.
So far I thought it can be set by creating an application-scope workmanager (Deployments -> [application] -> Configuration -> Workload) and setting the Maximum Thread Constraint.
However recently I have the feeling that it is not true as this workmanager should be referenced from the code so it has to be used explicitly from the application.
What I'd need is to configure that from now on the XYZ application can use max 5 threads but no more. It can be done on global level but I want to control only one application.
As far as I know, if you define the workmanager in app's weblogic.xml or weblogic-application.xml, it's for sure will work on application level instead of config.xml which is domain-level config.
If you create and configurate the workmanager's max-threads-constraint and then reference to it in your app’s web.xml file like this:
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>your_workmanager_name</param-value>
</init-param>
i'm pretty sure, that this constraint will apply only on certain app's level.
I have the feeling that it is not true as this workmanager should be referenced from the code so it has to be used explicitly from the application.
Where'd you find this? I may be wrong but I never heard or read that it should be referenced explicitly from code instead of xml.
For more details take a look on this and this in case you hadn't.
Related
My application has 2 purposes:
It needs to run stand-alone, where it needs routing for choosing a
study etc.
Or, it runs integrated in an other project, and only needs
one controller and one view.
Currently i have a routeProvider configured for the stand-alone application, injecting the pages in the ng-view tag in the HTML.
Now is my question: How can i inject an controller and view in the ng-view (For the integration). I cannot manipulate the HTML since it is static. I cant use a single routeProvider rule, because this can interfeir the application that integrates mine (Other plugins can use the #/.. for info or other things).
In your situation you can't use routeProvider when other stuff interferes.
Of Course you could prevent routeProvider to act on outside changes of the hashbang with workarounds but thats not nice.
routeProvider will listen to all changes of the url after the hashbang.
So what you should do is to manually bootstrap() your angular app with the controllers you need. If your app is small enough you could even use directives to achieve lazy loading of templates with the attribute templateUrl : "/myurl"
Usually to create a dynamic App use Routing. Simnple point.
The best way to use Angular if you want to unleash all its might don't integrate it.
I explain why:
+ Your state never gets lost due to page reloads
+ You have full control of the environment and don't have to worry about interfering scripts etc.
+ If your user should manually reload, you can redirect to home/login or even better use requireJS or HTML5 local storage to recover your scopes after a reload
Cheers, Heinrich
My application needs to be able to serve up static content which can be contained in a number of different places (directories and/or via the class loader). So, for example, a resource /static/file.html might be found in /dir1/file.html or /dir2/file.html; I would want it to try /dir1, and if not found there, then /dir2, and so on.
With servlets in Jetty, I can use either a HandlerList of DefaultServlet, to sequentially try to handle the request from each directory until satisfied, or even easier a single DefaultServlet with a ResourceCollection.
I can't see a way to do something similar in restlet, without writing a class to specifically do this. I could modify Directory to handle multiple sources (in a similar way to DefaultServlet with ResourceCollection), or write a new Restlet which tries each contained Restlet sequentially, until successfully handled (like HandlerList). But before I do that, am I missing another way that already exists to achieve this?
thanks,
Stuart
I confirm that Directory doesn't know how to handle multiple source directories. It would be a nice to add support for this and contribute it back.
I'm working on something that needs to install files periodically into a folder in /Library.
I understand that in the past I could have used one of the Authenticate methods but those have since been deprecated in 10.7.
What I've understood from my reading so far:
I should create a helper that somehow gets authenticated and have that helper do all of the moving tasks. I've taken a look at some of the sample code, including some involving XPC and one called Elevator but I'm a bit confused.
A lot of it seems to deal with setting up some sort of client / server model but I'm not sure how this would translate into me actually installing my files into the correct directories. Most of the examples are just passing strings.
My question simply: How can I create my folder in /Library programmatically and periodically write files to it while only prompting the user for a password ONCE and never again? I'm really not sure how to approach this and there doesn't seem to be much documentation.
You are correct that there isn't much documentation for this. You'll basically write another app, the helper app, which will get installed with SMJobBless(). Not surprisingly,
the tricky part here is the code signing. The least obvious part for me was that the SMAuthorizedClients and SMPrivilegedExecutables entries in the info plist files of each app are dependent on the identity/certificate that you used to sign the app with. There is also a trick with the compiler/linker to getting the info plist file compiled into the helper tool, which will be a single executable file, rather than a bundle.
Once you get the helper app up and running then you have to devise a way to communicate with it since these are two different processes. XPC is one option, perhaps the easiest. XPC is typically used with server processes, but what you are using here is the communication side of XPC only. Basically it passes dictionaries back and forth between the two apps. Create a standard format for the dictionary. I used #"action", #"source", and #"destination" with 3 different action values, #"filemove", #"filecopy", and #"makedirectory". Those are the 3 things that my helper app can do and I can easily add more if necessary.
The helper app will basically setup the XPC connection and event handler stuff and wait for a connection and commands. The commands will just be a dictionary so you check for the appropriate keys/values and do whatever.
I can provide more details and code if you need more help, but this question is 9 months old so I don't want to waste time giving you details you've already figured out.
We have a WCF service that needs to be deployed to 200 plus customers' servers. We would like to be able to make a portion of the web.config available for customization by using the configSource attribute like so:
<bindings configSource="bindings.config" />
This allows us to overwrite the main web.config file with future upgrades while not overwriting customers' own modifications to the sections that we decide to externalize this way. Unfortunately, there's a problem with this - according to this article, "When you use the configSource attribute, you must move the entire section to a separate file because there is no merging of element settings." This means that any section we put in an external file is now outside of our reach for upgrades and changes without having to mess with the external files that the customer may have made modifications to.
Is there any way around this? Can we have our cake and eat it too, or do we have to decide between having control ourselves and giving our customers flexibility?
Well it appears there's no way around this, you can only do it one way or the other. In the end the decision we made was to use configSource and externalize certain portions of the web.config, knowing that those would be outside of our control but that the vast majority of our web.config would still be available for future modifications.
I am looking for a method of storing Application Messages, such as
"You have logged in successfully"
"An error has occurred, please call the helpdesk on x100"
"You do not have the authority to reset all system passwords" etc
So that "when" the users decide they don't like the wording of messages I don't have to change the source code, recompile then redeploy - instead I just change the message store.
I really like the way that I can easily access strings in the web.config using keys and values.
ConfigurationManager.AppSettings("LOGINSUCCESS");
However as I could have a large number of application messages I didn't want to use the web.config directly. I was going to add a 2nd web config file and use that but of course you can only have one per virtual directory.
Does anyone have any suggestions on how to do this without writing much custom code?
In your Web.config, under appSettings, change it to:
<appSettings file="StringKeys.config">
Then, create your StringKeys.config file and have all your keys in it.
You can still use the AppSettings area in the main web.config for any real application related keys.
Put the strings in an xml file and use a filewatcher to check for updates to the file
Put the strings in a database, cache them and set a reasonable expiration policy
You can use ResourceManager class. See "ResourceManager and ASP.NET" article at http://msdn.microsoft.com/en-us/library/aa309419(VS.71).aspx