The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.

If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.

For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues

Actually it's not only JavaSE projects which have this problem. In my case I have a clean 3 tier architecture where my backend.jars have NO whatever servlet specific dependency! Just to prevent that some funny guy implements frontend parts in my backend.jar. So in a cleanly setup environment JNDI just entirely doesn't exist for 80% of of the code.

So I would not really care about JNDI names for non EE environments, because most people will not be able to retrieve it anyway.

CODI and Seam3 both already provide nice Classes to access the BeanManager in a portable way. (for CODI see: https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/core/api/src/main/java/org/apache/myfaces/extensions/cdi/core/api/provider/BeanManagerProvider.java)

The only thing that I think we can really do with this is set up a java:global binding that follows a similar format to ejb portable JNDI syntax:

java:global:appname/moduleName/BeanManager

The CDI spec does not really have the scope to expand the java:comp namespace.

This is very hard to address as Java EE doesn't provide for a JNDI environment in non Java EE components.

I believe this is better addressed by CDI-14.

Deferring as TBD.