Support for CDI 2.0 (Contexts and Dependency Injection) / JSR 365

[Michael Slinn]

I posted this on the play-framework ML and got no answer. Perhaps this ML is more appropriate?

CDI 2.0 (Contexts and Dependency Injection) / JSR 365 now supports Java SE.
Will a future version of Play Framework conform to CDI 2+ or JSR 365?

Thanks,

Mike

ps follow @cdispec for news on CDI

[Rich Dougherty]

The plan is for Play to provide a fairly generic dependency injection abstraction which should be compatible with most DI frameworks and approaches. Out of the box Play supports one runtime dependency injection framework (Guice) and provides helpers to make Scala compile-time dependency injection possible.

I haven't heard anyone talking about CDI but I imagine that Play would be compatible with it, like it is compatible with most runtime dependency injection frameworks. However someone would need to write bindings. I don't think any of the core Play developers are planning on writing bindings, but it shouldn't be hard for a third party to write an add-on that brings CDI support to Play.

If you think that Play needs deeper changes to support CDI, perhaps you could elaborate on what you mean.

Cheers

Rich

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Typesafe, Inc

@richdougherty

[Michael Slinn]

OK, thanks for clarifying that until now there was no awareness of this standard.

[Dominik Dorn]

Hi Michael,

I cannot speak on behalf of the Play Team, but I think the very nature on 

how CDI handles the contexts will prevent that Play will _fully_ support it. 

E.g. the Contexts/Scopes "SessionScoped" and "ConversationScope" will not work, 

as Play is a stateless web framework, meaning there is no user session stored
in between requests on the server, thus preventing something like the SessionScope
without a general change in the architecture.
Another thing: Afaik some contexts in the current CDI impls I know of (weld, openwebbeans) are implemented through ThreadLocals... Play tries to get
rid of all of them.

Cheers,
Dominik

--

You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

[James Roper]

To further what Dominik has said, the fundamental assumption that CDI's implementation hangs on is that there is a well defined and simple mapping between context and threads.  This assumption goes out the window in an asynchronous environment, which makes it near impossible to implement this in an asynchronous framework like Play.  Now, there are things that can be done to address this, such as implementing support into the APIs of executors to capture context so that it can be propagated to an asynchronous operation - Scala's ExecutionContext actually currently supports this (but Java's ExecutorService does not). However, if we have a look at other parts of the JDK that are embracing asynchronous and parallel behaviour, such as Java 8 streams, CompletableFuture, and even in JEE like the asynchronous features of the Servlet 3.1 spec, we see very little to no attempt to address or even think about the consequences that these new ways of doing things have on apps and frameworks that rely on ThreadLocals - if the JDK's in built asynchronous mechanisms don't attempt to address it, then what hope have we got to try and give users a great CDI experience in Play?

In CDI I think we're seeing a split brain on the JDK, on the one hand, parts of the JDK are attempting to embrace reactive and asynchronous programming models, on the other hand, we have things like CDI whose implementation is fundamentally at odds with asynchronous programming models.  There is a universe between these two ways of doing things.  Since Play is firmly in the asynchronous camp, I think we would be best off steering well clear of CDI.

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Michael Slinn]

Sounds like a definitive answer. I imagine that CDI would play nicely with Java servlets.

I wonder if there is anything about CDI that could be adopted - something that might provide familiarity to Java programmers. That would lower the barrier to adoption of Play and encourage 3rd party developers who have (or will) develop something that uses CDI with servlets, for example. If Play DI seemed somewhat familiar then there might be a greater chance that they think of supporting Play as well.

Thank you,

Mike

[Dominik Dorn]

IMO it would be great if we could have the @Interceptor and @Decorator stuff (not sure if that already works with the guice integration alone) 
Also the @Alternative/@Specializes stuff would be great, especially for testing.

I know that there are producers in guice, not sure about if we also support the @Disposes stuff. 

Also the @Priority annotation might come in handy combined with the @Alternative/@Specializes. 

The Event-Mechanism would be nice, although its probably better if users just use akka for that... especially as it provides a distinction between fire() and fireAsync()

The Decorator stuff would be cool especially for controllers. Right now people would need to create a filter, and check in the filter if the request matches against that particular route... a decorator for a controller would be nice here and people could selectively enhance certain actions in this way. 

Support for the "Application/Container lifecycle Events" like with extensions would also be handy.. not sure if something like that already works with guice or not. 

Cheers,
Dominik

[James Roper]

Guice has limited built in AOP support, which can be used for decoration:

https://github.com/google/guice/wiki/AOP

Also writing your own bindings interceptor to decorate things is not very hard.

--

You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Slinn]

Then it should be easy to provide a binding interceptor to users :)