我正在实施面试时分配给我的 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(使用前将#替换为@)