我正在实施面试时分配给我的 JavaEE 作业。
我以前对 EJB 有一些经验，但与 JMS 和 MDB 没有任何关系。以下是我通过大量示例发现的内容：
- 应用程序服务器将其主题和队列绑定到不同的 JNDI 名称 - 例如
topic/queue, jms
- the
activationConfig该属性在 JBoss 上是必需的，而在 Sun 教程中则不是。
- 启动我的应用程序后，jboss警告我我的主题未绑定（实际上不是 - 我还没有绑定它，但我希望它自动绑定 - 事实上，在 JBoss 4.0 自动绑定的示例中似乎发生）。建议的解决方案是将其映射到一些 jboss 文件中，甚至使用 jboss 特定的注释。
这可能只是 JBoss，但由于它经过认证可以按照规范实施，因此规范似乎没有指定这些内容。所有所谓的可移植性都消失了。
所以我想知道 - 为什么有人声称 JavaEE 是可移植的，你可以把它部署在另一个应用程序服务器上，它会神奇地运行，如果这些极其基本的东西看起来根本不是可移植的。
附：抱歉，我的咆哮，但我想我可能做错了/做错了什么，所以请发表你的意见。
Java EE，就像（几乎？）任何标准一样，是实现者努力宣传遵守但又极力不想遵守的东西。
考虑这个问题：红帽如何赚钱？是通过赠送东西还是通过出售它们？如果您编写的代码可以轻松转移到另一个 Java EE 应用程序服务器，这将妨碍他们从您那里赚钱。解决这个问题的方法是古老的“拥抱和扩展”技术，该技术被归功于微软，但实际上自第一个标准发布以来一直是商业软件供应商选择的工具。
如果你坚持strictly到代码中的 Java EE API，然后 JBoss（或 Geronimo（或 JonAS（或 ...）））将运行它以及任何其他兼容的应用程序服务器，只需在特定于服务器的部署描述符中进行更改。这是拥抱阶段。
每台服务器——尤其是商业服务器（如 JBoss）！ -- 还倾向于向 API 添加额外的内容以“让事情变得更容易”。 （公平地说，这些通常确实会让事情变得更容易。）开发人员——尤其是那些不太熟悉标准 API 的开发人员——经常陷入依赖这些额外 API 而不以任何方式包装它们的陷阱，从而导致这些扩展被淹没如果您希望更改平台，则它们的代码很难删除。这是扩展阶段。
从软件历史上的任何时间点命名一个标准，你都会发现人们拥抱和扩展（以至于当人们谈论“致命拥抱”时，我必须强行将我的想法从供应商锁定问题转移到正确的术语上） 。您还会发现最终用户（开发人员或其他用户）会爱上它。在这方面，Java EE 与任何其他技术没有什么不同。
然后你考虑到大多数规范的措辞有多糟糕，然后......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
