I'm building an extension in Extbase (latest version, latest typo3) and am having repositories injected into my models.
This simply does not work. No errors, no clues, nothing. The inject* Method simply does not get called. The exact same Injection works in the controller.
Is it possible to inject Repositories into models in Extbase? In general, injection to models is possible since 1.4.
How can I debug this? Where do I have to look?
This is a common misconception:
Not every class you use in TYPO3 CMS uses dependency injection by default - and it's a good thing.
What is true, is that every object that has been instantiated by the ObjectManager can benefit from it.
In short: if you new Thing() some object, it won't benefit from dependency injection. If you use the ObjectManager to get an instance of something, the whole dependency injection gallore will rain down on your new instance:
constructor injection [Example: How can I use an injected object in the constructor?
annotations are read and field injections are done
setter injection was done in the past (Remark: I think it's deprecated)
public method (if existent) initializeObject is called
Note that injected objects are being instantiated by the objectManager as well-so recursion is possible if injected ServiceA needs an injected ServiceB.
Singletons are possible as well if you implement the marker interface SingletonInterface.
Dependency injection only works if you get an instance of the object via the ObjectManager. If you are using the good ol'
t3lib_div::makeInstance('Tx_yourextension_domain_model_thing')
inject* methods are not being called.
There is a german blog entry explaining how it works.
Related
I am new to Dagger (version 2.16 on Android) and based on my reading so far, I understand that for a component, there should be a provider (#Provides or #Binds) encapsulated in a module (#Module). Going through a lot of samples, I see code which has some objects which are not offered in any Module, nor are they being instantiated using new.
It is also my understanding that in order to access the dependencies in a module, a consumer class needs to inject itself in the component graph (components usually offer a method to inject classes). The code examples are not doing this either.
Here's some code demonstrating both my concerns. RecipePresenter is not being provided in any module, but still RecipeActivity is using it.
A possible explanation I could think of is that #Inject, in addition to requesting the dependency also adds/injects the requesting class (RecipePresenter in the linked code) into the component graph. But assuming there are multiple components/subcomponents, which component does the class using #Inject constructor gets attached to? If my understanding is correct, why do activities and fragments have to inject themselves manually in the component - shouldn't they be auto-injected if they declare a variable annotated with #Inject?
RecipePresenter has an #Inject-annotated constructor, which allows it to be provided. The #Inject annotation on the recipePresenter field within RecipeActivity does not help, just the #Inject-annotated constructor.
class RecipePresenter #Inject constructor(
private val useCase: RecipeUseCase,
private val res: StringRetriever) :
RecipeUseCase.Callback {
From the Dagger User's Guide:
Use #Inject to annotate the constructor that Dagger should use to create instances of a class. When a new instance is requested, Dagger will obtain the required parameters values and invoke this constructor.
If the class with the #Inject-annotated constructor also has a defined scope, then the binding will only affect components with the same scope annotation: An #ActivityScope class wouldn't be accessible from a #Singleton component, for instance. If the class has no scope defined, then the binding could appear on any and all components where it is needed, which is fine: The implementation is always the same, defined by the constructor itself.
#Inject has different meanings based on what it's annotating:
When you annotate a field with #Inject, it indicates that the DI system should set that field based on values from the DI system when it injects that object.
When you annotate a method with #Inject, it indicates that the DI system should call that method with parameters based on values from the DI system when it injects that object.
When you annotate a constructor with #Inject, it indicates that the DI system is allowed to call that constructor in order to create that object (which triggers the field and method injection above). In that sense it does act like a built-in Provider.
In Dagger specifically, #Provides methods take precedence over #Inject constructors (if they both exist for the same class), and unlike in the JSR-330 spec Dagger requires an #Inject-annotated constructor even when no other constructors are present. From the Dagger User's Guide:
If your class has #Inject-annotated fields but no #Inject-annotated constructor, Dagger will inject those fields if requested, but will not create new instances. Add a no-argument constructor with the #Inject annotation to indicate that Dagger may create instances as well.
Classes that lack #Inject annotations cannot be constructed by Dagger.
Finally, to answer your question about why activities and fragments need to inject themselves: Android is allowed to reflectively create Activity/Fragment/View objects without Dagger's help or participation. This means that nothing triggers the field and method injection described above, until you call a members-injection method on the component that instructs Dagger to populate those fields and call those methods. Consequently, you should never see an #Inject-annotated constructor on Application, Activity, Service, Fragment, View, ContentProvider, and BroadcastReceiver subclasses in Android: Android will ignore the #Inject annotation, so you might as well take control over injection yourself, manually or through dagger.android.
I am using J2EE with WASLiberty & Apache Wink (REST Impl).
I would need in some cases to have api class to be singleton, however private constructor probably wont work with REST. Has anyone used api to be singleton ? any hints ?
As per Wink doc
The #Scope annotation
According to the JAX-RS specification, by default, provider and resource classes are instantiated once for each JAX-RS application. This instantiation involves the default constructor for the class being called, with the injection of dependencies happening afterwards.
Since the instantiation of your resource class (in your words, API class) will be carried out by injection, I don't think the default ctor visibility will be an issue (In the worst case, make it public)
I have a JAX-RS web service that was generated by Netbeans. There are non-abstract facade classes for the service's endpoints. The persistence context is being injected into the non-abstract facade. Everything is working well and I see my data being returned to Fiddler.
We are using DTOs and I am implementing an assembler pattern. So, in the non-abstract facade's constructor, I am creating an instance of the assembler, and am passing the facade's entity manager instance into it. Unfortunately, it seems that the injection of the persistence context has not happened before the facade's constructor has been called, so I cannot pass the entity manager instance into the assembler for its to use in mapping operations. Kind of a chicken-before-the-end situation... I cannot figure out how to make this work... Is there some kind of post-constructor method that I can override and perform the initialization of the assembler and pass in the entity manager to it? I'd really appreciate your help and suggestions.
Thank you for your time and ideas,
Mike
Use method marked with #PostConstruct annotation. Like this:
#PostConstruct
private void init() {
// I'm called after all injections have been resolved
// initialize some object variables here
...
}
In that method you can use both, object fields initialized in the constructor and passed by injection.
I'd like to know what the best practices are for Eclipse 4 dependency injection.
After reading about this subject on the internet, I came up with the following strategy.
requirements
Share the data model of the application (e.g. company, employee, customer, ...) so that framework objects (view parts, handlers, listeners, ...) can access it with as little coupling as possible.
proposed strategy
I've used the lifeCycleURI plugin property to register a handler which is triggered at application startup. Such handler creates an "empty" top-level data model container object and place it into the EclipseContext. It is also discarded when application stops.
All Eclipse framework classes (view parts, handlers) use the classic DI to get such data model object injected.
Button listeners created with the class constructor can't have the data model object injected in them. So I thought they could be created with ContextInjectionFactory.make() to have injection performed. This would couple the class which creates the listener with CIF, but the great advantage is that injection works out of the box.
This is the best solution I've found yet to leverage E4 DI with as little coupling as possible. The weak spot is in my opinion this coupling with CIF. My question would be whether any strategy exist to remove even this coupling, or alternate solutions for the same requirements.
You can create a service class in your project, let's say ModelService.
Add #creatable and #singleton annotations to that class :
#creatable
#singleton
class ModelService{
}
And let DI do its job using following syntax in your parts/handlers/etc ..
#Inject ModelService modelService;
Then you can implement methods in your service like 'createBaseModel()', updateModel() and so on.
This creates a low coupling solution : you can also implement ModelService in a separate plugin and define it as a OSGi service.
for that solution, you can read this Lars Vogel article.
I'm in the process of teaching myself the MVVM pattern by dividing the pattern into its core facets and learning those facets one by one.
My question is related to dependency injection. What is it, and why/when should I use it? I've looked at Jason Dolinger's excellent MVVM intro video and I see he uses Unity. This might be strange to ask but how would I implement dependency injection WITHOUT using Unity? I basically want to understand the concept of dependency injection and how to use it without having to implement other frameworks/tools (for now).
Thanks.
I think it's good that you want to understand DI without using a framework, the concept is not terribly difficult to wrap your head around.
Let's say you want to use some form of transportation.
interface ITransportation
{
Transport();
}
An initial implementation of a method that uses a form of transportation might look like this:
public void Move()
{
ITransportation car = new Car();
car.Transport();
}
The problem with that method is that it is now dependent on a Car class. We should pass our transportation object in for added flexibility. This is inversion of control and is closely related to DI.
public void Move(ITransportation tr)
{
tr.Transport();
}
As you can see, we don't need to know anything about a specific DI framework. You might also want to check out the ninject DI by hand tutorial.
Just to extend #Andy's answer
Dependency Injection is one of the forms of the Dependency Inversion Principle
To achieve the decoupling of dependencies (as typically found in layered architecture),
DI is commonly used for instantiation scenarios such as basic new() and patterns like Factory method. In addition to being able to inject a new dependency instance every time (e.g. like factory), containers can also be set up to inject named instances, singleton instances, etc - i.e. IoC containers usually also take on the responsibility of managing the lifespans of objects as well.
One potential 'mindset shift' is that dependencies now potentially become publicly visible on concrete classes, since DI typically injects via constructors or public Get / Set properties. This may seem strange if you are used to using OO encapsulation, where dependencies of a class are seen as implementation and should be hidden from the 'outside' i.e. class method signatures.
However, by implementing Interface / Concrete class separation (as you should, not only for decoupling but also for testing / mocking purposes), the injection constructors / property injection methods will not be on the interface, so encapsulation is again in place.
Re : "Doing DI by hand" without Unity etc
What you would need to do is to code your own IoC container, which then is responsible for 'building up' instances of classes - during each 'build up', you would scan the class for dependencies (which are configured in the container, e.g. by config, by attributes, or simply just by convention, e.g. all public settable properties, or any class parameters on a constructor will be assumed to be dependencies). You would then create (if necessary) and inject this 'dependency' instance onto the object (e.g. by using reflection). And then recursively, all dependencies of these dependencies need to be built up etc. You would then also need to provide lifespan management for each of the objects, e.g. Singletons etc.