We're actually trying to inject different Controller-Classes to implement a trimmed version and a full version.
we take a look on spring and guice and all the documentation is just about to inject variables like
#inject
static MyBean bean;
but is it possible to make the inject-declaration for a class like this
#Inject
public class MyRealBean implement MyBean
?
i think not, but perhaps... ;)
So the question is, where to put the inject-annotion for the controller in the play framework.
i figure out kind of a hack, but I'm not lucky with that.
i created a wrapper controller, who owns the bean-controller and send all message to it.
public Wrapper extends Controller {
#Inject
static MyBean bean;
public static void index() {
bean.index();
}
perhaps somebody knows a better way or we're on the wrong way...
thanks
Put the #Inject annotation before constructor.
Related
I am not sure whether I understood the exact way of how these two does the injection using #Inject,but I recently developed an app where during the first phase of development I used Dependency Injection using #inject of HK2 and binded the resources using abstract binder,it worked fine.Then I wanted to inject one more value. I needed to inject a basic String values using #Inject and the value for this was got form a method annotated with #Produces.But when I do that I get this error.
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=String
I read in many places and many suggest CDI and HK2 have some issues working together.I am not able to resolve the issue.
When I try the above scenario in two different standalone programs they run fine.But when I integrate them I get the above error message.
This is what I found in java's jira:
https://java.net/jira/browse/GLASSFISH-20597
My example is:
public ClassA{
#Inject
ClassBInter b;
}
I binded the class b in the abstract binder
new AbstractBinder(){
#Override
protected void configure() {
//Binding the implementation to the interface
bind(ClassBImpl.class).to(ClassBInter.class);
}
}
this worked fine.
but when I tried the below concept of adding an #Inject to a String in the same system,it crashes with the above exception
public ClassC{
#Inject
String name;
}
Producer Class
public ProducerClass{
#Produces
public String getName(){
return "henry Ford";
}
}
String injection is generally not supported, across the board. You can use qualifiers, which should help with resolution.
Do you have a beans.xml file in your deployment?
To begin with two things.
I am trying to achieve an action filter that logs when and action begins and when it end
I am well aware of the .AsActionFilter() method in Autofac 3.0 BUT...
The project that this is using is based in Orchard 1.6 which is known to be compatible with autofac 2.6.xxx. We do not want to go through a potentially lengthy process of upgrading to Autofac 3.0 at this time so the .AsActionFilter() option is not available to us.
The other option is to set the filter (which extends ActionFilterAttribute) as an attribute on our base controller (from which all other inherit btw). The problem is that the filter itself has two dependencies:
A service of our own that holds information on the context
An implementation of an ILoggingService
What I cannot find is a way to inject these into the actual property at the head of the class. Does anyone know a way in which to achieve this either through the [Attribute] line itself of some function of Autofac during registation?
The ActionFilterAttribute:
public class GRMSActionLoggingFilter : ActionFilterAttribute {
private readonly IGRMSCoreServices _grmsCoreServices;
private readonly ILoggingService _loggingService;
public GRMSActionLoggingFilter(IGRMSCoreServices grmsCoreServices, ILoggingService loggingService) {
_grmsCoreServices = grmsCoreServices;
_loggingService = loggingService;
}
public GRMSActionLoggingFilter() { }
public override void OnActionExecuting(ActionExecutingContext actionContext) {...}
public override void OnActionExecuted(ActionExecutedContext actionContext) {...}
}
Assigning the attribute to the base controller:
// This currently compiles but will fail during run time as the IGRMSCoreSerivces and ILoggingService will both be null. Need to property inject these services somehow.
[GRMSActionLoggingFilter]
Anyone have any idea to achieve this?
You cannot (easily) inject runtime values to attributes.
This is how attributes work in C# - you can only pass constant values of certain types. You can read more about it here.
In order to achieve desired functionality in Orchard you need to split your code into two components:
a marker attribute class you put on your action
an action filter class inheriting from FilterProvider and implementing IActionFilter
The way it works is that you put an attribute on some action and then use the action filter to check existence of that attribute (using filterContext.ActionDescriptor.GetCustomAttributes(...)). If an attribute exists, do your stuff.
There are lots of examples of this technique in Orchard core. Check eg. the ThemedAttribute and ThemeFilter action filter classes.
I did my research and I can’t find any specific example of what I want to do.
I successfully implement Ninject into me MVC project. Everything works perfect. However, I want to do a last step.
Until now, I have been working like this (normal DI pattern):
public class myController : Controller
{
private iMyInterface myRepository;
public myController(iMyInterface myRepository)
{
this.myRepository = myRepository;
}
public ActionResult list(){
return view(myRepository.getMyList())
}
// rest o the code ...
}
My Question is; there is a way to do something like this? (Repository “Generator”)
public class myController : Controller
{
private iMyInterface myRepository = specialClass.GetMyRepository();
public ActionResult list(){
return view(myRepository.getMyList()) }
// rest o the code ...
}
I aware I’m writing a nonsense code, but the idea is to be able to do something similar.
Any recommendation?
I don't know what specialClass is supposed to be, but this looks a lot like the Service Locator anti-pattern in action.
The first option where the repository is injected through the constructor is better, because it gives you more options, including using specialClass:
var controller = new myController(specialClass.GetMyRepository());
I don't know Ninject, but most DI Containers give you an option to map an interface to a method call that returns an instance of the interface.
I would rather take a repository "Generator" in a constructor. That would give you the same result, but with a correct injection.
I'm developing my first project using Ninject (an MVC web application) and have a question regarding the correct/best use on Ninject.
I have set up a NinjectModule that binds an interface to a concrete class, but now I want to create instances of the interface object within my code. To achieve this I have written the following method:
public class NinjectControllerFactory : DefaultControllerFactory {
private class MyServices : NinjectModule {
...
}
public static IMyRepository GetMyRepository()
{
IKernel kernel = new StandardKernel(new MyServices());
return kernel.Get<IMyRepository>();
}
}
and this seems to work fine...
IMyRepository tempDB = ControllerFactory.GetRoomarRepository();
My question is, this the right/best way to achieve the result I'm looking for? I'm guess I'm concerned about the overhead of creating the Kernel instance.
Read the documentation: https://github.com/ninject/ninject.web.mvc/wiki/MVC3 and look at the sample project.
If you don't know what I'm talking about either go through the tutorial and try to add dependency Injection yourself or try your luck with my explanation of the problem.
Note: This problem isn't within the scope of the original tutorial on ASP.NET. The tutorial only suggests that the patterns used are dependency injection friendly.
The problem is basically that there is a dependency loop between the Controller, the ModelStateWrapper and the ContactManagerService.
The ContactController constuctor takes an IContactManagerService.
The ContactManagerService constructor takes an IContactManagerRepository (not important) and an IValidationDictionary (which ModelStateWrapper implements).
The ModelStateWrapper constructor takes a ModelStateDictionary (which is a property called "ModelState" on the controller).
So the dependency cycle goes like this: Controller > Service > ModelStateWrapper > Controller
If you try to add dependency injection to this, it will fail. So my question is; what should I do about it? Others have posted this question, but the answers are few, different, and all seem kinda "hack-ish".
My current solution is to remove the IModelStateWrapper from the IService constructor and add an Initialize method instead like this:
public class ContactController : Controller
{
private readonly IContactService _contactService;
public ContactController(IContactService contactService)
{
_contactService = contactService;
contactService.Initialize(new ModelStateWrapper(ModelState));
}
//Class implementation...
}
public class ContactService : IContactService
{
private IValidationDictionary _validationDictionary;
private readonly IContactRepository _contactRepository;
public ContactService(IContactRepository contactRepository)
{
_contactRepository = contactRepository;
}
private void Initialize(IValidationDictionary validationDictionary)
{
if(validationDictionary == null)
throw new ArgumentNullException("validationDictionary");
_validationDictionary = validationDictionary;
}
//Class implementation...
}
public class ModelStateWrapper : IValidationDictionary
{
private readonly ModelStateDictionary _modelState;
public ModelStateWrapper(ModelStateDictionary modelState)
{
_modelState = modelState;
}
//Class implementation...
}
With this construct I can configure my unity container like this:
public static void ConfigureUnityContainer()
{
IUnityContainer container = new UnityContainer();
// Registrations
container.RegisterTypeInHttpRequestLifetime<IContactRepository, EntityContactRepository>();
container.RegisterTypeInHttpRequestLifetime<IContactService, ContactService>();
ControllerBuilder.Current.SetControllerFactory(new UnityControllerFactory(container));
}
Unfortunately this means that the "Initialize" method on the service has to be called manually by the controller constructor. Is there a better way? Maybe where I somehow include the IValidationDictionary in my unity configuration? Should I switch to another DI container? Am I missing something?
As a general consideration, circular dependencies indicate a design flaw - I think I can safely say this since you are not the original author of the code :)
I wouldn't consider an Initialize method a good solution. Unless you are dealing with an add-in scenario (which you aren't), Method Injection is not the right solution. You have almost already figured that out, since you find it unsatisfactory that you need to manually invoke it because your DI Container can't.
Unless I am entirely mistaken, the ContactController doesn't need the IValidationDictionary instance before its Action methods are being invoked?
If this is true, the easiest solution would probably be to define an IValidationDictionaryFactory interface and make the ContactController constructor take an instance of this interface.
This interface could be defined like this:
public interface IValidationDictionaryFactory
{
IValidationDictionary Create(Controller controller);
}
Any Action method on the controller that needs an IValidationDictionary instance can then invoke the Create method to get the instance.
The default implementation would look something like this:
public class DefaultValidationDictionaryFactory : IValidationDictionaryFactory
{
public IValidationDictionary Create(Controller controller)
{
return controller.ModelState;
}
}
How about slightly changing/improving the design to something like this: http://forums.asp.net/t/1486130.aspx
Each controller has a virtual method Initialize to do stuff like that.
I think there is no better way because the IValidationDictionary is an abstraction layer between you current request/controller/modelstate and the IContactService. Injecting controllers modelstate into the service and then injecting the service into the controller is simply impossible using constructor injection. One has to be first.
May be there is a way using property injection? But I think this will be complicated too.