For Example
class LoggingService [Inject] (protected val logger: Logger)
class LoggingService #Inject (protected val logger: Logger)
I haven't found anything in the official documentation.
The [Annotation] syntax was supported in early preview versions of Kotlin. It does not exist in Kotlin 1.0 or newer.
Annotation Use-site Targets documents this.
If you have multiple annotations with the same target, you can avoid repeating the target by adding brackets after the target and putting all the annotations inside the brackets
Of course you can do it with one annotation as well. But you need to make sure to have the target set. This it at least a #. So it would be #Inject or #[Inject], or with several annotations #[Inject SomeScope].
Related
I have updated Play Framework up to 2.7 and I got following warning:
method info in object Logger is deprecated (since 2.7.0): Create an instance of via Logger(...) and use the same-named method. Or use SLF4J directly.
So my questions are:
Should I create an instance of Logger and pass it to each component
when I want to use it?
P.S.:
In project not based on Play Framework, I used to use scala-logging that is a wrapper for SLF4J. Can this be a solution?
Play 2.7 provides a trait for Scala similar to scala-logging. It creates a val which you can use it in you class/object:
import play.api.Logging
class MyClass extends Logging {
// `logger` is automaticaly defined by the `Logging` trait:
logger.info("hello!")
}
So there is another way to log in Play now.
We are facing weird injection issues in Widfly due to CDI changes. We have interface
public interface Command<I, O> {
}
and many classes implement this interface like this
public class ApproveUserRequests implements Command<ApproveUserRequestsRequest, List<String>> {
}
Application listener classes likes to get list of all classes available and uses injection like this
#Inject
private Instance<Command<I, O>> mActions;
However instance returned by mActions were always null. After debugging source found that the only way to get list of all instances is to use
#Inject
private Instance<Command<?, ?>> mActions;
Also we faced injection issues while using generic types , however using wildcard type helped us.
- See more at: https://developer.jboss.org/thread/256783#sthash.1s6tuXsR.dpuf
The rules for parameterized types have been clarified in CDI 1.2. Have look at Section 5.2.4 Assignability of raw and parameterized types of the spec.
I'm working with Apache Isis, attempting to update to DN 4.x but have a question about the ReferentialJDOStateManager in DataNucleus.
The JDOStateManager extended this class in DN 3.x but it is not present in DN 4.x
Affected class in Isis -
public class JDOStateManagerForIsis extends ReferentialJDOStateManager implements StateManager, ObjectProvider
I do see this class -
org.datanucleus.state.ReferentialStateManagerImpl
I thought this might be the appropriate replacement, but if I extend ReferentialStateManagerImpl, there are problems...
The problem I encounter when extending the new class -
ReferentialStateManagerImpl extends StateManagerImpl. Which extends
AbstractStateManager<Persistable>
The current JDOStateManagerForIsis is setup to handle PersistenceCapable objects rather than Persistable objects.
I'm not sure where to go from here.
PersistenceCapable is not used by DataNucleus v4.x AFAIK; that was the old JDO-specific bytecode enhancement contract that they no longer use, now using DN-own Persistable.
I also see that each StoreManager can define which StateManager/ObjectProvider it is using, and the RDBMS plugin specifies ReferentialStateManagerImpl
I am trying to use the #Reference Felix SCR annotation in Scala
This is how it can be used in Java:
public class Foo {
#Reference
MyServiceInterface service;
// some code here
}
Here, MyService is ideally a Java Interface and not a concrete class (dependency injection)
I am using the same annotation in Scala, trying to depend on the same MyService (a Java Interface), like:
class Foo {
#Reference
val service = MyServiceInterface // ??
// some code here
}
How can I use this annotation in Scala, to refer to a Java Interface?
example:
#Reference
val MyServiceInterface service
or
#Reference
val service = MyServiceInterface
is not valid Scala code
Thank you
I know very little about Scala but I believe "val" means an immutable value, and thus it makes very little sense to bind it to a (mutable) service reference.
Shouldn't this member field be declared with "def" or "var" instead? In which case maybe the annotation will be allowed.
The reference annotation has a interfaceReference attribute.
This attribute can be used to specify the java interface.
I assume in scala it would look like (never used Felix Annotation in scala):
#Reference(interfaceReference = MyServiceInterface)
val MyServiceInterface service
It might be that you also have to specify the bind and unbind method in this case.
Please see also Felix Annotations documentation
Since 1.9.0 Felix Annotation are runtime annotations. The Annotation Felix Processor has an option scanClasses to use classes instead of source code to process the annotations. This works perfectly fine with groovy. I see no reason why that should not work with Scala.
If you use Intellij then please have a look at the Felix Annotation Plugin. The plugin uses by default scan classes
I was able to solve this problem by specifying the type of the variable correctly like:
#Reference
var service: MyServiceInterface = null
#Neil is right, we must use a var instead of a val as the service binding happens at runtime.
Secondly, I had to add the following configuration to the maven-scr-plugin:
<configuration>
<scanClasses>true</scanClasses>
</configuration>
Then, I had to specifically instruct the Maven Bundle plugin to NOT import the org.apache.felix.scr.annotations package as follows:
<Import-Package>!org.apache.felix.scr.annotations, *</Import-Package>
because the manifest would otherwise include an entry for this package as something that the bundle depends on.
Once this was done, the mvn-scr-plugin would generate the XML file correctly and the mvn-bundle-plugin would generate the bundle, manifest correctly.
I am attempting to update a legacy Guice application, and I was wondering if there is any sort of preferred way of doing things when taking Servlet 3.0 annotations into consideration. For example, my application has a filter, FooFilter, which is defined in the Guice Module Factory method configureServlets(), as follows:
Map<String, String> fooParams = new HashMap<String, String>();
fooParams.put("someParam", "parameter information");
filter("/foo.jsp","/foo/*").through(com.example.filter.FooFilter.class, fooParams);
Is the above binding still necessary, or will it interfere with the following using the #WebFilter Servlet 3.0 annotation:
#Singleton
#WebFilter(
filterName="FooFilter",
urlPatterns={"/foo.jsp", "/foo/*"},
initParams = {
#WebInitParam(name="foo", value="Hello "),
#WebInitParam(name="bar", value=" World!")
})
public class FooFilter implements Filter {
etc....
Which method is now preferred? Will they mess with each other?
I just made quick draft how could a Servlet 3.0 support looks like. There could be a more elegant way to just call filter(Filter Class with WebFilter annotation) in configureServlet method, but that requires updated right to guice-servlet module, which is quite hard to distribute.
Well, what I did is a project at Github: https://github.com/xbaran/guice-servlet3
all you need to do is download and build. It is created on top of Guice 3.0 and works like this:
new Servlet3Module() {
#Override
protected void configureServlets3() {
scanFilters(FooFilter.class.getPackage());
}
};
The Servlet3Module extends ServletModule and contains a scanFilters method with package argument. This method will scan provided package from your classpath and try to register all classes with annotation WebFilter via filter() method.
This scan idea is based on Sitebricks (guice web framework created by Dhanji R. Prasanna) configuration system.
Honestly, I just make a draft, never try if it works. But hopefully it will. If you have any problem or question, just let me know.
PS: The support for servlets, listeners and so on could be added to, if you wish.