When I try to inject a class via constructor in a Kotlin class I am getting this exception.
I have been reading about ways to solve it in Java by adding an empty constructor to the class that gets the injection.
However, it does not seem to be possible (or I do not how) to do it in Kotlin.
The code that throws the exception has nothing out of normal...just a simple injection.
Here it is a piece of the code with the injection that throws exception:
class RemoteService #Inject constructor(
#SongListRepo private val songListRepo: SongListRepo): MainBaseService() {
...
...
...
}
And of course the SongListRepo is provided by a module in the usual Dagger 2 way.
-------- EDIT: ---------
After some help and comments from #Demigod the code looks like this
class RemoteService (): MainBaseService() {
lateinit var songLR : SongListRepo
#Inject constructor(#SongListRepo songListRepo: SongListRepo) : this(
{
this.songLR = songListRepo
}
Problem now is that secondary constructor never gets initialized
Is it possible that the error you're getting is related to this Service (I think like Fragment they must have a zero argument constructor, so that the platform would be able to re create them)? If yes than you might use an on demand injection, like:
class RemoteService: MainBaseService() {
#Inject
#SongListRepo
private lateinit var songListRepo: SongListRepo
init {
// Something like this
AndroidInjection.inject(this)
}
}
Or, anyway you can add additional constructors like:
class RemoteService constructor(): MainBaseService() {
private lateinit var songListRepo: SongListRepo? = null
#Inject constructor(#SongListRepo songListRepo: SongListRepo):this() {
this.songListRepo = songListRepo
}
}
More about constructors here
Related
I'm writing a JavaFX application in Kotlin with the following controller definition:
class MainController {
#Inject private lateinit var componentDescriptors: List<ComponentDescriptor>
/* More code goes here */
}
I'm using Guice for Dependency management. And I'm trying to inject the list of class instances loaded via java.util.ServiceLoader. My problem is to define a binding that will inject the list of loaded object instances into the declared field. I tried annotation based provisioning:
internal class MyModule: AbstractModule() {
override fun configure() { }
#Provides #Singleton
fun bindComponentDescriptors(): List<ComponentDescriptor> =
ServiceLoader.load(ComponentDescriptor::class.java).toList()
}
and multibinding extension (switched List to Set in field definition of corse):
internal class MyModule: AbstractModule() {
override fun configure() {
val componentDescriptorBinder = Multibinder.newSetBinder(binder(), ComponentDescriptor::class.java)
ServiceLoader.load(ComponentDescriptor::class.java).forEach {
componentDescriptorBinder.addBinding().toInstance(it)
}
}
}
but both of these approaches leads to the same error:
No implementation for java.util.List<? extends simpleApp.ComponentDescriptor> was bound.
while locating java.util.List<? extends simpleApp.ComponentDescriptor>
for field at simpleApp.MainController.componentDescryptors(MainController.kt:6)
while locating simpleApp.MainController
1 error
at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1042)
at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at com.gluonhq.ignite.guice.GuiceContext.getInstance(GuiceContext.java:46)
at javafx.fxml.FXMLLoader$ValueElement.processAttribute(FXMLLoader.java:929)
at javafx.fxml.FXMLLoader$InstanceDeclarationElement.processAttribute(FXMLLoader.java:971)
at javafx.fxml.FXMLLoader$Element.processStartElement(FXMLLoader.java:220)
at javafx.fxml.FXMLLoader$ValueElement.processStartElement(FXMLLoader.java:744)
at javafx.fxml.FXMLLoader.processStartElement(FXMLLoader.java:2707)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2527)
... 12 more
I'm starting to suspect that it somehow related to Kotlin gerenic variance and Guice strict type checking. But I don't know how to declare the binding so Guice will know what to inject into this field.
Yes, it happens because of variance but there's a way to make it work.
class MainController {
#JvmSuppressWildcards
#Inject
private lateinit var componentDescriptors: List<ComponentDescriptor>
}
By default Kotlin generates List<? extends ComponentDescriptor> signature for the componentDescriptors field. The #JvmSuppressWildcards makes it generate a simple parameterized signature List<ComponentDescriptor>.
#Michael gives the correct answer and explanation. Here's an example of one strategy for unit testing a Set multibinding for those that like to test their modules:
class MyModuleTest {
#JvmSuppressWildcards
#Inject
private lateinit var myTypes: Set<MyType>
#Before fun before() {
val injector = Guice.createInjector(MyModule())
injector.injectMembers(this)
}
#Test fun multibindings() {
assertNotNull(myTypes)
assertTrue(myTypes.iterator().next() is MyType)
}
}
#Michael comment is working. If you want to do the injection in constructor, you need do something like
class MainController #Inject consturctor(
private var componentDescriptors: List<#JvmSuppressWildcards ComponentDescriptor>
) {}
I use Weld SE in an application, in my application I have an interface for which I have 3 implementations but this causes an ambiguity for Weld. As far as I can see Weld ambiguity resolution technics are static, this can be done by mean of: #specialize, #alternative, #Named or using Qualifier. but this doesn't help me. I need to be able specify a given class implementation of the interface for each case.
I couldn't figure out a solution for my requirement.
Here is a code that illustrates my point
public class Foo {
#Inject
MyInterface target;
public void doSomething() {
target.doIt();
}
}
public class Bar1 implements MyInterface {
public void doIt() {
System.out.println("Hello");
}
}
public class Bar2 implements MyInterface {
public void doIt() {
System.out.println("Goodbye");
}
}
public class FooMain {
public static void main(String[] args) {
Weld weld = new Weld();
final WeldContainer container = weld.initialize();
Foo foo1 = container.instance().select(Foo.class).get();
Foo foo2 = container.instance().select(Foo.class).get();
}
}
This code causes this exception :
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type MyInterface with qualifiers #Default
at injection point [BackedAnnotatedField] #Inject com.lodh.arte.test.cdi.Foo.target
at com.lodh.arte.test.cdi.Foo.target(Foo.java:0)
Possible dependencies:
- Managed Bean [class com.lodh.arte.test.cdi.Bar2] with qualifiers [#Any #Default],
- Managed Bean [class com.lodh.arte.test.cdi.Bar1] with qualifiers [#Any #Default]
I need to dynamically tell Weld which implementation to use for injection, just like in this imaginary method Weld.use:
Weld.use ( MyInterface.class, Bar1.class);
Foo foo1 = container.instance().select(Foo.class).get();
Weld.use ( MyInterface.class, Bar2.class);
Foo foo2 = container.instance().select(Foo.class).get();
Thank you for your help
Regards
Nader
First you have two implementations of MyInterface. Bar1 and Bar2. Weld does not know which implementation to choose when injecting MyInterface, so it throws this "Ambiguous dependencies" error.
To avoid this error you should give your implementation different qualifiers.
You have to Qualify your implementations first:
#MyQualifier1
public class Bar1 implements MyInterface {
(...)
}
#MyQualifier2
public class Bar2 implements MyInterface {
(...)
}
This will allow to inject a specific implementation like this:
#Inject
#MyQualifier1
MyInterface target;
Now you're injecting an MyInterface qualified with #MyQualifier1. At runtime its Type will be Bar1 in this case.
Another approach if you want to decide at runtime which implementation you need would be the use of Instance:
#Inject
Instance<MyInterface> unqualifiedInstance;
void do(){
/// first attach the qualifier, we missed at the injection-point:
Instance qualifiedInstance = instance.select(new AnnotationLiteral<MyQualifier2>(){})
/// Now you have a qualified Instance, which is a new Object without touching the unqualifiedInstance!
MyInterface target = qualifiedInstance.get();
/// so you can decide which implementation you need by passing the qualifier per select-method. in this case its bar2
target.doIt();
}
If you need further help with qualifiers you may find the weld documentation and especially chapter 4.3 and the following helpful.
http://docs.jboss.org/weld/reference/latest/en-US/html/injection.html
I would like to have a static instance method with Guice for one of the components (non-managed bean should be able to access this class). I created something like this:
public class LookupService {
#Inject
private static Provider<Injector> injector = null;
private final ILookup<IWS> lookup;
#Inject
public LookupService(ILookup<IWS> lookup) {
this.lookup = lookup;
}
public static LookupService instance() {
return injector.get().getInstance(LookupService.class);
}
public <T extends IWS> T lookup(Class<T> localInterface) {
return lookup.lookup(localInterface);
}
}
What do you think about this design ? Any other ideas on this ? (accessing managed beans from non-managed objects)
Basically, the pattern you're looking for is called "requesting static injection" and there's a Binder method dedicated to it. Once you have that down, your code looks a lot like this example from the Guice docs.
public class MainModule extends AbstractModule {
#Override public void configure() {
requestStaticInjection(LookupService.class);
}
}
public class LookupService {
/** This will be set as soon as the injector is created. */
#Inject
static Provider<LookupService> provider = null;
private final ILookup<IWS> lookup;
#Inject
public LookupService(ILookup<IWS> lookup) {
this.lookup = lookup;
}
public static LookupService instance() {
return provider.get();
}
public <T extends IWS> T lookup(Class<T> localInterface) {
return lookup.lookup(localInterface);
}
}
A few notes:
While you can still set your field to be private, remember that this means you cannot set it in tests (or in future non-Guice usage) without Guice's private-field-access magic. When using injected fields, we often make them package-private and then put the tests in the same package.
Static injection is generally seen as something to endorse only when migrating to Guice, or when you use other code you can't change. When possible, try to avoid global state--even if this means making FooBean data-only and creating an injected FooBeanService.
Even though you can inject an Injector wherever you'd like, you might find it easier to test if you simply inject a Provider<LookupService> instead. Only inject an Injector if you don't know what type you're going to need until runtime--for example, if you implement LookupService.lookup(...) using an Injector by passing the class literal to the injector to get an instance.
In fact, it's hard to say from here, but ILookup seems to act a lot like the Service Locator pattern, which solves the exact type of problem that Guice solves with dependency injection! If that's the case, you might as well rewrite ILookup to use Guice: Just remove calls to LookupService.instance().lookup(Foo.class) and instead create a matching pair of #Inject static Provider<Foo> fooProvider and requestStaticInjection(FooUser.class).
Hope that helps!
Preliminaries
I'm using Ninject.MVC3 2.2.2.0 Nuget Package for injecting into my controller an implementation of a IDomain Interface that separates my Business Logic (BL) using an Factory approach.
I'm registering my Ninject Modules in the preconfigured NinjectMVC3.cs using:
private static void RegisterServices(IKernel kernel)
{
var modules = new INinjectModule[]
{
new DomainBLModule(),
new ADOModule()
};
kernel.Load(modules);
}
I'm trying to avoid the fatal curse of the diabolic Service Locator anti-pattern.
The Domain Class uses a DBContext that i'm trying to inject an interface implementation too, via an IDBContext, with the following scenario:
IDomainBLFactory:
public interface IDomainBLFactory
{
DomainBL CreateNew();
}
DomainBLFactory:
public class DomainBLFactory : IDomainBLFactory
{
public DomainBL CreateNew()
{
return new DomainBL();
}
}
In the controller's namespace:
public class DomainBLModule : NinjectModule
{
public override void Load()
{
Bind<IDomainBLFactory>().To<DomainBLFactory>().InRequestScope();
}
}
At this point i can inject the IDomainBLFactory implementation into my controller using Ninject Constructor Injection without any problem:
public class MyController : Controller
{
private readonly IDomainBLFactory DomainBLFactory;
// Default Injected Constructor
public MyController(IDomainBLFactory DomainBLFactory)
{
this.DomainBLFactory = DomainBLFactory;
}
... (use the Domain for performing tasks/commands with the Database Context)
}
Now my central problem.
In the DomainBL implementation, i will inject the dependency to a particular DBContext, in this case ADO DBContext from Entity Framework, again, using a IDBContextFactory:
IDbDataContextFactory
public interface IDbDataContextFactory
{
myADOEntities CreateNew();
}
DbDataContextFactory
public class DbDataContextFactory : IDbDataContextFactory
{
public myADOEntities CreateNew()
{
return new myADOEntities ();
}
}
ADOModule
public class ADOModule : NinjectModule
{
public override void Load()
{
Bind<IDbDataContextFactory>().To<DbDataContextFactory>().InRequestScope();
}
}
Now in the DomainBL implementation I faced the problem of injecting the necessary interface for the DBContext Object Factory:
public class DomainBL
{
private readonly IDbDataContextFactory contextFactory;
**** OPS, i tried to understand about 10+ Stackoverflow articles ***
...
}
What have I tried?
To Use the constructor Injection. But I don't know what to inject in the call for the Factory CreateNew() in the IDBContextFactory. For clear:
public class DomainBLFactory: IDomainBLFactory
{
// Here the constructor requires one argument for passing the factory impl.
public DomainBL CreateNew()
{
return new DomainBL(?????) // I need a IDBContextFactory impl to resolve.
//It's not like in the MVC Controller where injection takes place internally
//for the controller constructor. I'm outside a controller
}
}
In this Useful Post, our unique true friend Remo Gloor describes in a comment a possible solution for me, citing: "Create an interface that has a CreateSomething method that takes everything you need to create the instance and have it return the instance. Then in your configuration you implement this interface and add an IResolutionRoot to its constructor and use this instace to Get the required object."
Questions: How do I implement this in a proper way using Ninject.MVC3 and my modest Domain Class approach? How do I Resolve the IResolutionRoot without be punished for relaying in the Service Locator anti-pattern?
To Use the property injection for an IDBContexFactory. In the course of learning and reading all the contradictory points of view plus the theoretical explanations about it, I can deduce it's not a proper way of doing the injection for my DBContexFactory class code. Nevermind. It doesn't work anyway.
public class DomainBL
{
[Inject]
public IDbDataContextFactory contextFactory
{
get;
set;
}
//Doesn't works, contextFactory is null with or without parameterless constructor
.... (methods that uses contextFactory.CreateNew()....
}
Question: What am I missing? Even if this approach is wrong the property is not injecting.
Be cursed. Use a DependencyResolver and live with the stigmata. This works and I will remain in this approach until a proper solution appears for me. And this is really frustrating because the lack of knowledge in my last 10 days effort trying to understand and do things right.
public class DomainBL
{
private readonly IDbDataContextFactory contextFactory;
this.contextFactory = DependencyResolver.Current.GetService<IDbDataContextFactory>();
//So sweet, it works.. but i'm a sinner.
}
Question: Is there a big mistake in my understanding of the Factory Approach for the injection of interfaced implementations and using a Domain Driven Approach for taking apart the Business Logic? In the case I'm wrong, what stack of patterns should I implement with confidence?
I saw before a really big quantity of articles and blogs that does not ask this important question in a open a clear way.
Remo Gloor introduces the Ninject.Extensions.Factory for the Ninject 3.0.0 RC in www.planetgeek.ch/2011/12/31/ninject-extensions-factory-introduction.
Question: Will this extension work coupled with Ninject.MVC3 for general porpouse?. In such case it should be my hope for the near future.
Thank you all in advance for your guidance and remember we appreciate your kind help. I think a lot of people will find this scenario useful too.
I don't really get the purpose of your factories. Normally, you have exactly one ObjectContext instance for one request. This means you don't need the factory and can simply bind myADOEntities in Request scope and inject it into your DomainBL without adding the factories:
Bind<myADOEntities>().ToSelf().InRequestScope();
Bind<DomainBL>().ToSelf().InRequestScope();
And Yes the factory and mvc extrensions work together.
Here's an implementation of a generic IFactory to solve the problem without resorting to the ServiceLocator anti-pattern.
First you define a nice generic factory interface
public interface IFactory<T>
{
T CreateNew();
}
And define the implementation which uses ninject kernel to create the objects requested
class NinjectFactory<T> : IFactory<T>
{
private IKernel Kernel;
public NinjectFactory( IKernel Kernel )
{
this.Kernel = Kernel;
}
public T CreateNew()
{
return Kernel.Get<T>();
}
}
Binding to your factory using the following
private static void RegisterServices(IKernel kernel)
{
kernel.Bind<myADOEntities>().ToSelf();
kernel.Bind<DomainBL>().ToSelf();
kernel.Bind(typeof(IFactory<>)).To(typeof(NinjectFactory<>));
}
You can now do the following in your controller.
public class MyController : Controller
{
private readonly IFactory<DomainBL> DomainBLFactory;
public MyController( IFactory<DomainBL> DomainBLFactory )
{
this.DomainBLFactory = DomainBLFactory;
}
// ... (use the Domain for performing tasks/commands with the Database Context)
}
And in your DomainBL
public class DomainBL
{
IFactory<myADOEntities> EntitiesFactory;
public DomainBL( IFactory<myADOEntities> EntitiesFactory )
{
this.EntitiesFactory = EntitiesFactory;
}
// ... (use the Entities factory whenever you need to create a Domain Context)
}
Please forgive my ignorance, but I am very new to IOC and NinJect. I have searched for high and low for easily understandable solutions but so far they have eluded me.
So far I have the following and all works as expected:
private class StandardModule : NinjectModule
{
public override void Load()
{
Bind<ILog>().To<NLogLogger>(); // Use NLog
Bind<IMyEntityFrameWorkRepository().To<MyEntityFrameWorkRepository>();
}
}
MyEntityFrameWorkRepository then creates its own EF DbContext via a connection string declared in app/web.config:
public class MyDbContext : DbContext
{
public MyDbContext() : base("MyAppConfig")
{
}
........
}
HOWEVER!! My goal is something like this - I realise this syntax is "nonsense" (and I think I may have to IOC MyDbConext too) , but I hope the "pseudo-code" conveys my desire:
private class StandardModule : NinjectModule
{
public override void Load()
{
Bind<ILog>().To<NLogLogger>(); // Use NLog
string mySqlConnectionString = MyApp.GetCommandLineArgument("sqlconn"); // "Data Source=..."
Bind<IMyEntityFrameWorkRepository().To<MyEntityFrameWorkRepository>(mySqlConnectionString);
}
}
.................
public class MyDbContext : DbContext
{
public MyDbContext( string sqlConnectionString) :
base(sqlConnectionString) // will accept a standard SQL connection string
{
}
........
}
I would truly appreciate some feedback from IOC / NinJect experts, since I am sure any "pattern" can be very useful in other scenarios.
You can use the .WithConstructorArgument() method to specify constructor arguments. The first argument should be the name of the constructor parameter.
public class StandardModule : NinjectModule
{
public override void Load()
{
string connectionString = "...";
Bind<IMyEntityFrameWorkRepository().To<MyEntityFrameWorkRepository>()
.WithConstructorArgument("sqlConnectionString", connectionString);
}
}
Newer versions of Ninject allow to get rid of magic strings in the binding definition. Something like this:
public class StandardModule : NinjectModule
{
public override void Load()
{
string connectionString = "...";
Bind<IMyEntityFrameWorkRepository()
.ToConstructor(_ => new MyEntityFrameWorkRepository(connectionString);
}
}
For bindings involving generic types (e.g. bind ISomeService<T> to SomeService<T> and binding should be performed for all possible types at once), ToConstructor cannot be used (a new expression is required), so WithConstructorArgument remains the simplest approach. E.g.:
Bind(typeof(ISomeService<>))
.To(typeof(SomeService<>))
.WithConstructorArgument("someParam", "someValue");