Updated 2.4 highlights #4257
Updated 2.4 highlights #4257
Conversation
|
|
||
| ## Aggregated reverse routers | ||
|
|
||
| Play now supports aggregating reverse routers from multiple sub projects into a single shared project, with no dependency on the project the routes files came from. This allows a modular Play application to use the Play reverse router as an SPI between modules, allowing them to render URLs to each other without depending on each other. It also means a dependency free reverse router could be extracted out of a Play project, and published, for use by external projects that invoke the APIs provided by the project. |
There was a problem hiding this comment.
Did you mean API instead of SPI? All I can find when I google SPI is "Serial Peripheral Interface", which doesn't seem right
There was a problem hiding this comment.
I think it should be Service Provider Interfaces
There was a problem hiding this comment.
Better to have a link here, so it won't confuse users: http://en.wikipedia.org/wiki/Service_provider_interface
There was a problem hiding this comment.
That makes more sense. Though I'm not sure it's accurate. "Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party." But we're not re-implementing the reverse router - just calling it. So it's still just a regular API and not an SPI.
There was a problem hiding this comment.
The reverse router essentially describes an HTTP/REST API - it's not the reverse router Java/Scala API itself that I'm talking about, it's the HTTP/REST API that implements the URLs it generates that I'm referring to. When you pull the reverse router into a common module, that module does not provide the implementation for that API, it just provides that API itself so that you can invoke it. So, in that case it makes sense to describe it as an SPI, because it's implemented by a third party (in this case, another module in the project).
There was a problem hiding this comment.
Right, I agree with everything you said, but still think that it's not an SPI according to Wikipedia's definition. Let's say it's project A exporting the routes and project B consuming the routes. In this case project A has created the API and thus project B would be considered the third party. Wikipedia said an SPI "is an API intended to be implemented or extended by a third party". But we don't intend project B to implement or extend the API, so I don't think it's an accurate description.
But regardless of whether you could say SPI here, I think it's just too uncommon a term and will confuse people, so it would be better to use API, which is much more common and still accurate.
|
|
|
||
| ## Logging enhancements | ||
| * Applications become easier to test and components become easier to mock. | ||
| * More interesting deployment scenarios are possible, such as multiple Play instances in a single JVM, or embedding a lightweight Play application. |
There was a problem hiding this comment.
It is not yet possible to run multiple Play applications in a single JVM unless you use embeddable applications, right?
There was a problem hiding this comment.
I wouldn't expect you to be able to use multiple Play applications in a single JVM today whether or not it's embedded. I'd also expect that you could embed with or without DI (but again only a single instance).
There was a problem hiding this comment.
Whether we do actually support this is another question entirely. It's not a goal to support running multiple embeddable applications. But it's also not a bad thing to be able to do.
Technically, dev mode runs multiple applications in the one JVM (or multiple versions of the same application), just not concurrently. Removing global state actually does make dev mode simpler - currently there's all these things in Play that are defs that could be vals or lazy vals and would help performance if they were, but can't be because of dev mode.
No description provided.