More details. I like the ideas of JMS support for CDI. But where should it live. Can we release extensions like JMS in a separate jar file? Or somehow make it modular so as not to preclude CDI from being used in non-Java EE environments. Can we spin off other specifications for JMS CDI Extension? Should a CDI JMS extention be part of the JMS spec.?

There are already lots of EE specific things in the spec. But the entry section lists a possibility to run in a stripped down form if running on SE:

"An application that takes advantage of these services may be designed to execute in either the Java EE environment or the Java SE environment. If the application uses Java EE services such as transaction management and persistence in the Java SE environment, the services are usually restricted to, at most, the subset defined for embedded usage by the EJB specification."

The spec says that the container must know how to handle those EE resources/functionality. But the spec also allows to implement it via a lightweight modular plugin system (OWB is designed that way) where not all the functionality is always present in every deployment.

Yea, I know what you mean and we already discussed this in the past. Basically it's a matter of taste.

Gavins argument was that a certified CDI container (all TCK passes) needs to support the whole EE range. But every implementation is also free to define a stripped down variant on it's own - which is then not spec compliant.

We could of course try to define a minimum feature set of functionality for running in a SE environment. But then politics kick in! JSR-299 was originally EXPLICITLY defines as for Java ENTERPRISE! And extending this to SE was kind of a blasphemy already. For example: check the history of the CDI spec name
Just trust me, you don't like to know all the gory details ...

To address various comments:

• It's not up to the spec to dictate which jar files thing live
• We probably don't have the ability to spin off other specs for other extensions for EE 7 but can consider for the future (this is purely proceedural)
• We can definitely discuss CDI / JMS support living in JMS 2.0

Let's open a new issue for discussing how to demarcate EE from SE features in the spec and keep this one about JMS.

Assigning to John as he is man in the JMS 2.0 EG camp who is focusing on CDI integration for JMS 2.0.

This issue is now just a tracking issue, in place to ensure the CDI community is kept up to date with progress and make sure that whatever decisions the JMS EG make are clearly communicated to the CDI community. John, if you could update the issue whenever a draft of the JMS 2 spec which includes CDI becomes available that would be excellent!

I will keep you up to date.

JMS 2 has extensive CDI support.

JMS2 support is primarily on the sender side, the ability to inject a JMS client based on some configured data and properly send a message outbound. Injection is supported within this object realm under the "simplified API" docs. No changes at this time to the reception side of JMS.