General discussion of Play: https://www.playframework.com/ | Code of Conduct: https://www.lightbend.com/conduct | Forums: https://discuss.playframework.com | Commercial support from https://www.lightbend.com/
@quanghieple Play uses Guice by default for dependency injection. And Guice recommends constructor injection over field injection. (see https://github.com/google/guice/wiki/Injections#field-injection). I guess it's ok if you have no other choice. I don't know if field injections work when the field is declared in a trait, but that can be found out easily. :)
let me know if it works, I'm curious
what exactly you want to be explained in the code? why conf is null in the constructor?
and if field injection does not work in a trait you have two options:
- find out why, it could be due to the way scala compiles traits (if you are on play 2.4, you are on a very old scala version, 2.10), or it may be because guice does not support it (though I don't see why that would be the case)
- programatically ask guice for an instance, instead of the
@Injectannotation.
7 replies
I'm setting up a new Play project as of recent that would interact with Azure using few libraries (e.g. servicebus, cosmos). It seems the newest version of Play is depending on Jackson 2.10, while most Azure client libraries depend on 2.11, which was released last April. I'm just wondering about options I have for an approach, and what I might be missing, for instance
- Use older com.azure.cosmos/servicebus libraries that depend on 2.10., and migrate to newer with Play 2.9 (?) release and Jackson 2.11. (?) support when it comes. It seems that Akka is depending on that Jackson 2.10 version though, and Akka hasn't released Jackson 2.11. support
- Fork Azure libraries and downgrade the Jackson on core, then build custom versions and use those as dependencies (if even possible)
- Try with dependencyOverrides in build.sbt to force Jackson 2.10, hope there won't be any incompatibilities or NoClassDefFounds later
- Skip using Azure libraries altogether, try some REST-based solution where applicable
- Skip using Play for this project altogether, use some other Framework and Azure libraries with Jackson 2.11.
- Something else I'm not thinking about? :)
2 replies
@mpartan dependency resolution in most platforms (Scala and Java included) is a mess. I guarantee you in many cases, if not most cases, you are not using the library version you think you use. This problem is controllable only in small projects. Once you reach a certain size, it's really more of a "click and pray" approach. The good news is that it works most of the time (in my experience), and problems tend not to occur that often (but when they do, it's a nightmare). My approach has always been to pay attention to my own dependencies (either align the versions to the ones used by the framework, or use the latest ones), and worry about such conflicts only when a problem occurs.
In your case it's actually quite easy. First jackson 2.11 is very likely to be compatible with 2.10, and it's also easy to find out.
I would go for dependencyOverrides or letting the build system to select a Jackson version (preferring the latter, because dependencyOverrides introduces manual maintenance of library versions). And in the worst case scenario, if it really doesn't work, you can always compile play with the desired Jackson version.
Build compiles with different dependencies, but ScalaModule in throws explicit error: https://github.com/FasterXML/jackson-module-scala
[error] com.fasterxml.jackson.databind.JsonMappingException: Scala module 2.10.5 requires Jackson Databind version >= 2.10.0 and < 2.11.0
[error] at com.fasterxml.jackson.module.scala.JacksonModule.setupModule(JacksonModule.scala:61)
So probably has to be explicit dependencyOverride
I am upgrading from play 2.6 to 2.7.8, and I get this error
ControllerComponents not set! Call setControllerComponents or create the instance with dependency injection.Even though my controller is extending InjectedController and in 2.6 it works fine. With Base-/AbstractController it works, but I rather not have the boilerplate. I couldn't find any existing issues about this
i'm also just seen sentry-logback which might be a good path to go down
@henricook instead of calling sentry manually, just use the sentry-logback integration, this project uses that (just do
git log | grep sentry)
I'm running play 2.8.7
AFAIK, play should support this case: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
I updated play from 2.5.9 to 2.7 and need to convert classes to work with DI. I am having trouble migrating the custom logback appender that sends logs to external service with wsclient. I get this error when starting the server:ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type service.logging.LogstashAppender
And this is the signature of that class:
@Singleton
class LogstashAppender @Inject()(ws: WSClient) {Back in play 2.5 it worked without DI as I just sent the logs with play.current.WS
But the play.api.current was removed since everything needs to be DI. How can I work around this?
a proxy in the middle which removed the header
thanks!
(specifically swagger doesn't seem to pick up scala enumerations)
play.logger.includeConfigProperties=true
play.logger.includeConfigProperties=true
play.logger.includeConfigProperties=true will do it
Seed project announcement: Our seed project for simple, self contained sites (PSPS) has been updated (Play 2.8, Scala 2.13, Bootstrap5, and many other nice things). All are invited to use, fork, pull-request, comment, etc. https://github.com/codeworth-gh/PSPS :-)
Hey firends! I'm trying to mock a response from a 3rd party API and I'm running into a problem generating the output this api generates. Specifically, it stringifies json 2 times. so instead of
{"omg:":"json"} we are trying to create "{\"omg\":\"json\"}". Any thoughts on how to do that since Json.stringify wants a JsValue?