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)
Related
I've read several articles about the difference between #Service and #Component. Now I understand that #Component is user to annotate an object as an OSGi component and its lifecycle will then be managed by OSGi.
However, what is the need to declare an object as service with #Service is unknown. What happens if you write your business logic in a object that is declared as a component?
I also want to know what does the below statement means:
Components can refer/call (using container injection – #Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component.
Question 1:
What is the #Service annotation in Apache Felix?
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#service:
The #Service annotation defines whether and which service interfaces
are provided by the component.
You should understand that this is about the OSGi Service concept, not the Declarative Service (DS) concept described with #Component.
Avoid using annotations from Felix SCR (package org.apache.felix.scr.annotations).
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html :
The annotations itself do not support the new features from R6 or
above. It is suggested to use the official OSGi annotations for
Declarative Services instead.
Use #Component from package org.osgi.service.component.annotations, this annotation replaces both #Component and #Service from Felix.
Question 2
What happens if you write your business logic in
a object that is declared as a component?
Happens to work fine.
Question 3
I also want to know what does the below statement means:
Components can refer/call (using container injection – #Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component there.
This is how components share functionality in OSGi. They offer their features as OSGi services. But when OSGi injects the object into the reference, you get your component.
BONUS: Read this article: https://medium.com/adobetech/using-the-osgi-declarative-service-in-aem-6-4-21102f649d54
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'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 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.
We are using CXF 2.4.2 to create a RESTful interface. I have a bean resource class that is defined as follows:
#Path("/mypath")
public class MyResource {
#GET
#Path("/myget")
public final Response myGet() { ... }
Does anyone know why the method can't be final in order to access the resource?
Sometimes JAX-RS is implemented in such a way, that instead of original class (that we create) JAX-RS is using proxy class which inherits from our class. Since final method cannot be overriden, usage of final methods is prohibited.
Usage of proxy enables adding to JAX-RS framework various interceptors, providers, etc. Obviously the same functionality can be obtain without using proxy, so other providers might allow usage of final methods.
The specification does not say anything about final methods.
Side note: very often usage of final method is a bad idea. Sometimes even if we think that given method should not be overriden, it may appear that is necessary. Even Java creators made a few such mistakes. Obviously there are classes, which methods should not be overriden (String), but there are not a lot of them.