I have a set of parameters that should be configured by the user. But they are just too much to send them through RESTful services or something similar. Besides there may be another set of configurations of same parameters.
Assume that my configurations are: p1, p2, p3, ... p10
I want to make possible having more than set of initialization of these configurations such as:
(p1=x, p2=y, ... p10=1)
(p1=a, p2=b, ... p10=10)
To do that I currently implement my OSGI component with metatype=true and configurationFactory = true options so that each instance of my component will have a set of configurations initialized. Then, I process the instances in a manager component.
So the question what do you suggest for passing configurations to OSGI components from user?
Thanks
If this is really about configurations you should use the OSGi ConfigurationAdmin service. A console like the Apache Felix WebConsole can then be used to edit configurations.
If the values (or some values) can be different for each RESTful call to your application and they don't fit in a URL, you can make a POST request instead of a GET, and pass the values in the body of the request, in a suitable format.
Related
Im trying to get a definition of our AppSettings and ConnectionStrings.
I would like to be able to "fetch" the following:
Key (Name of setting)
Value (The value of the setting)
Provider/builder (From which provider the setting were "picked from", since we use configuraiton builders, such as the UserSecrets and Environment config builders).
The problem is that the application that "requires" this is using ASP.net 4.8.
If this would have been ASP.net core 3+, I could simply use IConfigurationRoot.GetDebugView, or well.. I could simply have a look at the source code of that method and recreate what I need.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration.configurationrootextensions.getdebugview?view=dotnet-plat-ext-6.0
https://andrewlock.net/debugging-configuration-values-in-aspnetcore/
But I cant find anything simulair in .Net Framework.
I have tried to find a way to eaither get all Config Builders and then use the keys from ConfigurationManager.AppSettings.AllKeys and ConfigurationManager.ConnectionStrings.AllKeys
and then for each ConfigBuilder call their GetValue-methods which takes a key.. this could work, but Im still unable to get all my configured Configuration Builders. Any ideas?
We're using Spring Cloud Contract for testing our services. I was wondering if there is some way to set the stubsMode at runtime, as opposed to being an option on the annotation:
#AutoConfigureStubRunner(ids = {...}, stubsMode = StubRunnerProperties.StubsMode.LOCAL)
If the annotation is the only way to set this option, we'll need to have two separate classes, one for local and one for remote.
You can use the properties. We describe it in the docs. Just pass the system prop stubrunner.stubs-mode=local or an env var STUBRUNNER_STUBS_MODE=LOCAL
I've been running into endless problems attempting to use Windsor with Web API and injecting HttpRequestMessage into downstream dependencies of a controller. Since I've tried all the matching answers on Stackoverflow, I'd like to ask the question in a different way:
In Castle Windsor, how can I resolve a component instance while supplying a value for a downstream dependency? That is, the supplied value is required by a component that is required by the component being resolved.
For context, I'm trying to inject HttpRequestMessage so that I can use it to resolve the request context (primarily to resolve an absolute URL).
Edit I'd also like to point out that I don't currently have a dependency on Web Host / System.Web and I'd rather not change that.
A proper approach is to
Create IMyDesiredRouteParameterProvider
Implement it. Get the current request inside it and get the url
Register it and inject it in the desired dependent class via constructor.
I made myself such an implementation and I can say that this way it works fine. You can make Web.Infrastructure assembly and put the implementation there. Or put both the interface and the implementation there if you are going to reference it from another web module.
using System;
using System.Web;
namespace RouteParameterProvider
{
interface IMyRouteParameterProvider
{
string GetRouteParameter();
}
public class ControllerActionMethodRouteParameterProvider : IMyRouteParameterProvider
{
public string GetRouteParameter()
{
string Parameter = HttpContext.Current.Request.RequestContext.RouteData.Values["controller"] as string;
if (string.IsNullOrEmpty(Parameter))
{
throw new InvalidOperationException();
}
return Parameter;
}
}
}
You can get every possible thing that the Request Context contains from :
HttpContext.Current.Request.RequestContext
And it will be better if you rethink your design decision :
I need HttpRequestMessage to be regstered prior to creating each
instance of SomethingController so that it will be available down at
the LinkGenerator layer.
Containers are to be initialized at runtime and then used to resolve.
I need HttpRequestMessage to be regstered prior to creating each
instance of SomethingController so that it will be available down at
the LinkGenerator layer.
It sounds like you want to register an item with the container at runtime, post-startup. In general, this is not a good practice--registration should be a discrete event that happens when the app is fired up, and the container's state should not be changed during runtime.
Dependency Injection is about resolving service components, not runtime state--state is generally passed via methods (method injection). In this case it sounds like your LinkGenerator component needs access to the ambient state of the request.
I'm not that familiar with HttpRequestMessage, but this answer seems to show that it is possible to retreive it from HttpContext.Current. You could make this a method on your LinkGenerator class, or wrap this call in a separate component that gets injected into LinkGenerator (HttpRequestMessageProvider?). The latter would be my preferred method, as it allows LinkGenerator to be more testable.
Given the lack of a clean way of doing this and Web API not providing information as to the hosted endpoint beyond per-request context objects, I ended up injecting the base url from configuration.
Is this library by Mark Seemann the answer? In the description he writes explicitly :
This approach enables the use of Dependency Injection (DI) because the
request can be injected into the services which require it.
Then gives an example :
// Inside an ApiController
var uri = this.Url.GetLink(a=> a.GetById(1337));
By which you can then pass the URL down the road in the service that you have injected in the controller.
UPDATE :
Mark Seemann wrote about the same exact problem here:
"Because HttpRequestMessage provides the context you may need to
compose dependency graphs, the best extensibility point is the
extensibility point which provides an HttpRequestMessage every time a
graph should be composed. This extensibility point is the
IHttpControllerActivator interface:..."
This way you can pass request context information to a component deep in the object graph by getting from the HttpRequestMessage and passing it to the DI container.
Just take a look at the interface of IHttpControllerActivator.
The WEB API framework gets the IHttpControllerActivator through DependencyResolver. You probably already replaced it by your CastleWindsorDependencyResolver. Now you have to implement and register your HttpControllerActivator and register it.
When the WEB API framework gets IHttpControllerActivator from DependencyResolver (your Castle Windsor DR) and calls IHttpControllerActivator.Create() it will pass you the HttpRequestMessage. You can get your info from there and pass it to the your CastleDR before you call Resolve(typeof(MyController)) which will resolve the whole object graph - that means you will have MyHttpContextInfo to inject in your XYZComponent deep in the resolution stack.
This way tou are passing the arguments in the last possible moment but it is still possible. In Castle Windsor I make such passing of arguments though CreationContext.AdditionalArguments["myArgument"];.
I have an configuration error with Unity.
I am trying to implement http://unitymvc3.codeplex.com/, but i am stucked right now, because of this:
In my unity configuration I have this settings:
<register type="IMainDbContext" mapTo="WorkflowContext">
<lifetime type="hierarchical" />
<constructor></constructor>
</register>
But at the time of creating unity, (my simple code is here:)
UnityConfigurationSection section = ConfigurationManager.GetSection("unity") as UnityConfigurationSection;
if (section != null)
{
section.Configure(container);
}
this.container = container;
everything is configured great, except of registration "IManDbContext" which has LifetimeManagerType = {Name = "TransientLifetimeManager" FullName = "Microsoft.Practices.Unity.TransientLifetimeManager"}, but it should be hierarchical lifetime manager
Have you got any ideas how tell unity (in configuration, not in code) i want hierarchical lifetime manager?
Thanks for any tips.
My error was caused by this error:
I have multiple DbContext, but they was badly configured:
<register type="IMainDbContext" mapTo="WorkflowContext">
<lifetime type="hierarchical" />
<constructor></constructor>
</register>
<register type="IReportDbContext" mapTo="SomeBadContext">
<lifetime type="hierarchical" />
<constructor></constructor>
</register>
When I was using this configuration, which was bad, unity simple don`t configure any lifetime manager. After I set these context right, unity used my lifetime manager configurations just right.
I don't think you can. If you're specifying the lifetime type you need to either supply "singleton" or "external" (external being a custom lifetime).
Link to Unity Schema Documentation
In fairness, unless you're using multiple Unity containers I don't see the value of having a hierarchical lifetime manager, as this is designed to ensure that you only have one instance of your type instantiated in the main unity container and any child containers you generate from it.
So, unless you're planning on generating child containers and want a separate instance of your IMainDbContext inplmenting object, you might as well just using "singleton" lifetime manager.
I'm creating a flash campaign which will be loaded into a client's framework, which I have no control over. The framework will already have loaded a few things such as locale, fonts and copy, and will pass these things to my swf upon initialization.
Since the size of my swf (let's call it the shell) is restricted it will in turn display a campaign-specific preloader and then load another swf (let's call this the campaign) with the rest of the site.
The shell and the campaign will both be PureMVC modules. The shell will create a few proxies and populate these with data passed from the framework (locale constants, fonts etc), before loading in the campaign.
When the campaign is loaded it too will need locale and fonts etc. so my question is, what is the best way to pass this data along to the campaign module from the shell module?
I could create the same proxies in the campaign module and load the data again, which will be cached, but this obviously feels like the wrong way to go.
I've investigated the use of the pipes utility but this seems like a bit of an overkill in my case since the communication will be one-way and will just happen once during the initialization of the campaign.
Would it be "ok" from a design pattern point of view to pass the proxies to an init method of the campaign module and then register these proxies in the campaign module startup command? This seems wrong since these proxies have references to my shell application facade through notification names. Would it be ok if I move the notification names to some "NotificationConstants" class which both modules can use?
I could create similar proxies in the campaign module but this time populate them with the data objects from my old proxies passed to the previously mentioned init method? Spontaneously this feels like the best way to do it since the data objects don't have any references to my shell module but the "old" proxies do..
The solution I usually use is to create an interface:
interface Campaign {
function set campaignDetails(value:CampaignDetails):void;
//...
}
The campaign-module should implement this interface - in the implementation I recommend you to use a different proxy in the module, so that you would avoid having duplicated notifications and references.
When the shell is ready with the loading of the module it just has to:
if (module is Campaign)
{
(module as Campaign).campaignDetails = ...;
}
I'm sure I'm telling you nothing new. You just need to make sure to keep the acquaintance between the shell and the module only on an interface level. Then you just pass the data and leave the module MVC core to deal with it independently from the shell.