I am trying to set other services to be dependant on mine (in order to enforce mine to run first) using the Solaris SMF system.
I know I can use the tag in the other service manifest and make it depends on my service, but I would like to avoid editing the other services manifests for obvious reasons.
According to this link, under the "Dependencies" section, it is stated that it is possible but I couldn't figure out how.
Thanks
You do that in the manifest with the dependent XML element as opposed to the dependency element.
Suppose you want "serviceA" to depend on your fancy new service, called "serviceMine", but you cannot change the manifest for "serviceA".
Then in the manifest for "serviceMine" you would do something like
<dependent name='serviceMine_dependency'
grouping='require_all'
type='service'
restart_on='restart'>
<service_fmri value='svc:/application/foo/serviceA' />
</dependent>
Documentation
When the going gets tough I sometimes resort to the documentation which is in the DTD for SMF manifests. You can read it at: /usr/share/lib/xml/dtd/service_bundle.dtd.1 on your local system. It is quite useful as a reference.
Related
I'd like to configure the Adobe Cloud Manager production pipeline to invalidate the whole dispatcher cache. What paths do I have to give at the production pipeline dispatcher invalidation configuration to have that done? Is it possible to give a pattern here that matches everything? The page-invalidate description talks about a path-pattern, but doesn't describe what exactly that means.
We work with statfilelevel=2. It seems the .stat files are very important for that, though the description given here is unfortunately not precise enough, not sure I understand that right.
I tried to configure /content as path - that just touches /mnt/var/www/html/.stat (/mnt/var/www/html is the docroot), which seems to apply to nodes like /* but not like /content/* .
If I give /content/oursite, that touches /mnt/var/www/html/content/.stat , too, but that does seem to apply to nodes like /content/oursite or /content/othersite, but not to pages like /content/oursite/about - for which would /mnt/var/www/html/content/oursite/.stat be relevant, if I understand that right.
Do I seriously have to enumerate a page in each site that has a .stat file, or is there a more sensible way to get everything invalidated? After all, a deployment could easily change the HTML of every page if a component has changed.
If you have ACS commons installed then you can try to use this powerful feature
https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html
I have created some Autofac modules... Now I want to register some of them in my container using web.config... In my web.config I have written:
<autofac defaultAssembly="Autofac.Example">
<modules>
<module type="DebugModuleTest1"></module>
<module type="DebugModuleTest2"></module>
</modules>
</autofac>
Now I have to build my container. But the autofac documentation is not clear to me. I do not understand what I have to do to read my modules and build the container.
public class MyCustomContainer
{
public void Build(HttpConfiguration config)
{
var builder = new ContainerBuilder();
Microsoft.Extensions.Configuration.ConfigurationBuilder x = new Microsoft.Extensions.Configuration.ConfigurationBuilder();
//var sec = x.AddInMemoryCollection().Build().GetSection("autofac");
// var y = x.AddXmlFile("Web.config");
var y = new ConfigurationBuilder().SetBasePath(AppDomain.CurrentDomain.BaseDirectory);
var z = y.AddXmlFile("Web.Config");
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
}
}
I am using latest version of Autofac so I do not have the ConfigurationSettingsReader class available.
Can anyone help me please?
EDIT
I had found interesting saving configuration on web.config because in this way I could "change" web.config according to my solution configuration (you know, the classic web.debug.config, web.release.config, etc)...
That could me help to register the correct modules avoiding the use of directives (#if bla bla bla, ...) or simply conditions...
I am already using modules, but I do not think the correct solution is adding a property inside the module to choose the component to resolve according the selected environment where I want to deploy the project..
I just think of this solution reading this example (By the way, Flexibility to Override still refers to ConfigurationSettingsReader. Is it ok?)
In the 4.0 version of configuration you don't store anything in web.config. It's all in separate XML or JSON files. I'd recommend JSON. The documentation outlines that pretty well:
If you were using the app.config or web.config based configuration available before, you will need to migrate your configuration to the new format and update the way you set configuration with your application container.
We actually spent a lot of time trying to document as much as possible, so while there's definitely a lot there try not to "TL;DR" it. If you skip around, you're liable to end up in the "pre 4.0" section thinking that will still work with the 4.0 stuff. It won't. It sounds like from your comment on this other question that you may have missed a few things the first time through.
Spend some time in the quick start section. That section has both C# and JSON code showing how things work. Again, it's easy to skip past that.
If the docs don't show enough examples, look at the unit tests in the Autofac.Configuration repo, especially the folder full of test files that shows both XML and JSON formatted examples we use in testing.
Finally... three tips:
Configuration is not a feature-for-feature replacement for code. If you're looking to do amazing, crazy, logic-based stuff then stick to modules, possibly with some configuration to register the modules.
Be familiar with Autofac and DI terminology. If you're new to DI or Autofac, "components," "services," and other terms will be confusing. The configuration uses these terms, which means you may not get what you're looking at. Spend time with the docs. The getting started page includes an intro to some of the terminology.
Learn about the new Microsoft config system. There is separate doc about that maintained by Microsoft. Their docs explain everything from how to change config based on environment to creating custom config providers. Autofac is standing on the shoulders of config giants - we don't have to build in that flexibility anymore because it comes for free from the new config system.
I have my custom rule, let's say with AEM-1 key. So, as it is done here, I make my AEM-1.html resource file with some simple html content and it does not get's picked up by SonarQube 5.1. It refuses to start, because no description is provided for the rule.
I tried different packages names, tried to look for convention in source code etc. What's missing? Is there any documentation on that?
The naming convention is org/sonar/l10n/{plugin key}_{language}/rules/{repository key}/{rule key}.html.
It was documented in http://docs.sonarqube.org/display/DEV/Internationalization at the time rule descriptions supported localization. That's not the case anymore since version 4.2, but these HTML bundles are still supported.
The correct way since version 4.3 is to use the low-level API org.sonar.api.server.rule.RulesDefinition. It allows you to implement any kind over layer over it (xml, json, annotations, ...).
Could someone explain how or if namespaces can be used in Magento module setup resources? I see a lot of tutorials saying to use the <modulename_setup> format, but somehow, the mana_core module managed to use mana_core_setup instead of core_setup. I tried doing the same thing, but I couldn't get it to work. I'm trying to create a project module, but I'd like to namespace it with the company name to minimize collisions. Should this be possible? Or did Mana work some extra magic behind the scenes? (FYI, this is on Magento 1.7.0.2.)
<!-- recommended style
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources -->
<resources>
<weblog_setup>
<setup>
<module>Magentotutorial_Weblog</module>
<class>Magentotutorial_Weblog_Model_Resource_Setup</class>
</setup>
</weblog_setup>
</resources>
<!-- app/code/local/Mana/Core/etc/config.xml -->
<resources>
<mana_core_setup>
<setup>
<module>Mana_Core</module>
</setup>
</mana_core_setup>
</resources>
Any help would be great! Thanks!
The first link in the comment of your provided example explains that you can use pretty much any name you want - modulename_setup is merely a convention of how to make it easier for everyone involved to understand what and where it it. So you are entirely free to use vendor_module_setup format if you wish.
However it is worth a re-consideration why is it that you want a vendor-prefixed resource. In general resources should be something that is shared among modules in the system and should usually NOT be "owned" by a single module. This is, however, a rule of thumb, so if you have valid reasons (i.e. your resource is genuinely non-reusable in any way anywhere anyhow) then go on and create a prefixed one.
I am trying to figure out how to configure a ASP.NET MVC2 config file to have absolutely no caching. My current config file has this xml node...
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<add name="ZeroCacheProfile" duration="0" varyByParam="*" location="None" />
</outputCacheProfiles>
</outputCacheSettings>
</caching>
That would indicate to me, that no caching is going on with with this application. Am I missing something? Will continue to browse the internet searching for the most succinct answer. Thank you.
Defining a cache profile in web.config per se doesn't do anything useful other than defining a cache profile. There must be something using this cache profile otherwise it stays a simple definition. So that's half of the job.
The second half is to decorate all your controllers or actions that you would like to disable caching for with the [OutputCache] attribute:
[OutputCache(CacheProfile = "ZeroCacheProfile")]
or if you want to do this for all controllers of your site define a base controller that all your controllers derive from and then decorate this base controller with the aforementioned attribute.