我想感谢Matt Corey对Web Beans的评论，并回应几个观点。
Web Beans不仅仅是关于网络的，正如许多人已经评论的那样（包括Gavin）...虽然我不一定需要它被引入JSE，但我认为名字的更改是必要的...
我认为目标平台的具体问题是更重要的。这两个平台都已经拥有强大的品牌，Web Beans只是平台的一部分，而不是一个平台本身。另一方面，如果SE开发者觉得这项技术对他们有用，那么我们（Web Beans团队）将不得不回到Sun和JCP，讨论如何满足他们的需求。
如果Web Beans成为通用的依赖注入机制，那么我们将在JEE中留下至少三个不同的DI系统 -- Web Beans DI、@EJB/@ResourceJEE 5的DI，以及JSF的托管Bean机制...
这确实是我们正在考虑的问题。但我们需要来自EE专家组的指导，以确定如何进行下一步。理论上，如果我们能够提供一些工具，允许@EJB和@Resource在Web Beans之上实现，如果这是EE专家组的决定。
@In注解显然来自Seam，但这里可能还有更合适的注解 -- 在Seam中，还有一个@Out注解，表示'注入'...到目前为止，Gavin还没有给我们任何关于这个将在Web Beans中出现的暗示，但如果不是的话，我认为@In应该变成类似于@Inject, @Bean, @Component等注解
我们启动了@Out超出规范，经过多次讨论。@Out在 Seam/JSF 命名变量的世界中非常方便。在 Guice/Web Beans 的世界中，静态检查更多，这就不那么有意义了。而且，使用解析方法也能实现非常类似的效果。
我愿意接受关于重命名的建议@In，我已经考虑过@DependsUpon, @Uses, @Contextual和@Injected.
Guice 的影响似乎已经取代了 Seam 中的基于字符串的命名（即 --@Name("myBean")) 并使用注解（@MyBean)... 虽然这需要更多的代码，但这似乎是一个明智的决定 -- 它应该有助于防止在String中输入错误导致在运行时抛出NullPointerException...
是的，这是 Guice 做得非常好的地方。Guice 方法优雅、类型安全且完全自然 - 比Spring或JSF（Seam基于JSF方法）的方法要好得多。
然而，在 Web Beans 中仍然可以通过名称进行注入，因为@Named被定义为绑定注解。你可以这样做
@In @Named("currentOrder") Order order;
（如果你真的想的话。）
各种组件类型对于为单个应用程序提供多个配置可能非常有用，但我想看到更多定义组件的方法 -- 例如，我喜欢将系统配置保存在应用服务器中，这样当我从测试部署到预发布再到生产时，我只需复制一个已通过质量保证的 EAR -- 如果我必须更改 web-beans.xml 文件，我就无法这样做（除非你可以在服务器中配置一个默认值）
你可以这样做的一种方式是在部署到生产时不要包含包含你的@Staging组件的存档。如果高优先级组件在部署时不在类路径上，它们将不会被部署。
我喜欢作用域，但 Gavin 提到@ConversionScoped将从 JSF 管理 bean 中可用，而请求、会话和应用程序将从 Servlets 中可用 -- 那么 JSF 的什么使得它成为唯一适合会话作用域的东西？有什么理由它不能对 Struts 等基于 Servlets 的框架可用吗？
完全没有理由。但这里我们正在进入关于
- Web Beans 规范应该定义哪些功能的问题？
- 应用程序或第三方框架可以提供哪些功能？
Web Beans 规范有一个可扩展的上下文模型。特别是，这意味着如果你想为Context作用域定义自己的@ConversationScoped对象，这对于任何 servlet 请求都有效，你可以做到。
到目前为止，我只能说“你们做得很好！”...哦，还有，请继续提供预览！
感谢你的反馈 Matt，非常感谢 :-)
