I am injecting HttpContextBase into a caching class. HttpContextBase is registered as PerWebRequest. I interact with the caching class on each web request and this works fine, but I also need to initialise the cache at application start.
I understand that PerWebRequest does not work in Application_Start though:
castle PerRequestLifestyle not recognize
What is the best way to resolve this in my situation?
Not use stuff that depends on per-web-request stuff outside of web request.
If you need to depend on a class you registered as PWR I'd suggest getting another component for that service with different lifestyle and using it in Application_Start and using IHandlerSelector to return PWR one when you're within a web request, and the other one otherwise
Try using an hybrid webrequest/transient lifestyle.
To warmup caches when the container starts I usually use the Startable Facility.
Here is an example on how to use it:
http://blog.bittercoder.com/PermaLink,guid,a621ddda-acb5-4afd-84ff-faafb96a2fa1.aspx
Related
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'm After several days learning angularJS through converting my standart JS app to a ng one.
I was wondering about this simple scenario:
I have a global function called fb_connect(),
it can be used from any page (or any controller if you like) to make a facebook-based login.
This function makes a simple http call and receives a JSON object contain data to move on (display a pop up, login, etc...)
I read that I can define a Factory or a Service for my app and use it in any controller, which works fine.
So, I created a fb_connect factory function.
The problem is that now, in every page (every controller), I have to define that fb_connect in the constructor of every controller - for example :
function welcome($scope,fb_connect){});
What is the proper way to do this kind of actions using Angular without having to define these functions each and every time in every controller?
Thanks
Setting up factories and services is all part of the dependency injection system of Angular. Using that system is great when you need to create things that depend on other injected things. It's a big tree of dependencies. It's also nice for creating singletons, such that everywhere in your code end up using the same instance of some object.
It sounds to me like neither of these benefits apply in your case. I'd suggest just not using Angular's DI for it. You have some function defined globally, just call it directly and skip the DI. There's nothing wrong with that.
Of course you say it makes an Ajax call, so doesn't depend on the Angular $http service?
Your two options are:
Declare the function on the $rootScope
Inject it as a service
My advice is to go with making it a service. The whole purpose of services is explained in the Angular.js docs, just like this quote:
Angular services are singletons that carry out specific tasks common to web apps... To use an Angular service, you identify it as a dependency for the dependent (a controller, or another service) that depends on the service.
As you mentioned in your question, you'd prefer to not define the service in every controller you wish to use it in. With $rootScope you'll be injecting that also in every controller. So really it's a question of which you prefer, although to answer your question, the proper way of using a factory or service is to inject it into the controller you wish to use it in.
You can always put it in the $rootScope
myApp.run(function($rootScope, fb_connect){
$rootScope.welcome = function(){
};
});
So I ran into this issue with the Windsor bootstrapper for Nancy. I managed to whip together a small test project where I can reproduce what is going wrong. You can find the project here.
What seems to go wrong is this: DynamicProxy only seems to catch the invocation of the void Handle(Action<string> oncomplete) method and not the string Handle(string input) method that is called on another thread. As if the Engine is no longer proxied after it had been sent to another thread. Scratch that: It's just the call to another method on the same class that is not proxied.
This means the output of the program is only
Handled Handle with return type System.Void
test
and not
Handled Handle with return type System.Void
Handled Handle with return type System.String
test
Is this the expected behaviour of Dynamic Proxy? That proxies on another thread are not longer, well, proxied? Or is there something wrong with the code?
EDIT: Just RTFM'd Dynamic Proxy, and it seems like it Works As Intended. Now how do I configure my IEngine Instance to use the correct kind of Proxy?
Try changing :
Component.For<MyEngine>().Forward<IEngine>().Interceptors<ScopeInterceptor>());
into
Component.For<MyEngine>().Forward<IEngine>().Forward<MyEngine>().Interceptors<ScopeInterceptor>());
I don't have the time to actually try it but this should force windsor into creating a class proxy, which should solve your issue
Kind regards,
Marwijn.
-- edit --
for the current link try replacing :
Component.For<IEngine>().ImplementedBy<Engine>()
with:
Component.For<IEngine, Engine>().ImplementedBy<Engine>()
My problem is every time after changing the Liferay portal-properties (and this is frequent especially at beginning of a new portal project) I need to restart the whole portal.
Some properties I can set over hook and these values will be changed after redeployment. Also that must be possible to change most portal properties at run time.
However, do you know some approach to reflect changes in portal-ext.properties without restarting Liferay portal?
As stoldark mentioned, this is not possible in a production environment at all. Since portal.properties's properties are loaded at portal start-up.
But for development you can use a tool like JRebel, some steps to configure it here. The only issue you would get with this tool is that it is paid ;-).
I know it is a very old thread but it may be helpful for someone who is looking for some type of work around
As we know there is no straight forward way for this but I did this by using java reflection and class loader.
Liferay Version : 6.x
//Loading the PropsUtil class by using PortalClassLoader
Class<?> prospsUtilClass = PortalClassLoaderUtil.getClassLoader().loadClass("com.liferay.portal.util.PropsUtil");
//getting the reload method of PropsUtil class
Method reloadMethod = prospsUtilClass.getMethod("reload", null);
//Invoking the static reload method
reloadMethod.invoke(null, null);
Reload method (re)loads the portal-ext properties to the portal so we can use new properties without restarting Liferay server.
This has also been asked in Liferay forums:
https://www.liferay.com/community/forums/-/message_boards/message/800954
But I am afraid that most properties are only read once during portal startup.
Usually, the use of a properties file as in this case has this drawback.
There's even an issue open at Liferay about this, but is still unresolved:
http://issues.liferay.com/browse/LEP-5579
If you create a hook to override portal properties, you will be able to change properties with just deploying the hook without restarting the Portal.
Be aware that you cannot modify all properties with a hook. For a list of the ones that you can modify, check out: https://docs.liferay.com/portal/6.2/definitions/.
I've just searched for reloading portal-ext.properties and landed here.
Ok - not a feature in Liferay.
So I'll use an old trick I like:
place custom properties in (liferay-tomcat-home)/conf/filename.properties
reload them whenever you want by
Properties customProperties = new Properties();
customProperties.load(new FileInputStream(new File(System.getProperty("catalina.base"), "conf/filename.properties")));
I must confess I haven't tried this in a Liferay-Portlet-Environment, but this system property ("catalina.base") should be available in this context, at least by using some Liferay-Helper-Class.
Some of the Liferay classes read their properties when initialising static field constants. E.g.:
public static final boolean ENABLED = GetterUtil.getBoolean(
PropsUtil.get(DynamicCSSFilter.class.getName()));
Basically, it is possible to reload the properties (eg via script in control-panel), but all those static constants will remain.
I'm trying to implement automatic registration of my listeners to a singleton event aggregator when listeners are created by the IoC container - basically what Jeremy D. Miller is doing, but with Castle instead of StructureMap.
So I want to be able to "intercept" Windsor's object creation mechanism and, if the object supports the marker interface (let's say IListener), call the Subscribe method to an EventAggregator (which is also registered in the container) to make the newly created object a subscriber to events. Also, before the object instance has been released by the container, I want to be able to unsubscribe it.
I'm a little bit confused about what mechanism in Windsor Castle I should use to achieve something like this? I started looking at IInterceptor interface, but it seems to intercept all calls to the object, which is not what I really need (and want to avoid for performance reasons).
IKernel exposes various events like ComponentCreated and ComponentDestroyed which you can use to build that. There are many samples on the web.
Otherwise you could just use the event wiring facility, but it's not convention based.
You could also use OnCreate like this:
container.Register(
Component.For(typeof (Foo)).OnCreate(
(k, c) => {
// ...
eventAggregator.Subscribe(c);
// ...
}));