针对一个 Web 容器的 jar 构建 Java 程序并将其部署到另一个 Web 容器中的含义
针对一个 Web 容器（例如 Jetty）的 jar 构建 Java 程序并在另一个 Web 容器（例如 Tomcat）中运行它有何含义？
我有一个应用程序，在开发过程中在 Jetty 中运行，但它被部署到 tomcat 服务器中进行生产（为什么？因为它似乎更容易开发，而无需运行整个 tomcat 服务器。）
What are the implications of building a java program against the jars of one web container (say Jetty) and running it in another (say Tomcat)?
I have an application which I run in Jetty durring development but which is deployed into a tomcat server for production (Why? because it seems easier to develop without having to run a whole tomcat server.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于任何非开发人员构建，您应该仅针对您的目标级别的官方 Java EE API 进行编译。最好是通过构建引擎。最好是在与您开发时不同的操作系统上。
对于 Web 应用程序，这意味着从 Oracle 下载适当的 servlet API。与企业应用程序类似。
根据我的经验，这是保持直线的最佳方法。
编辑：Java EE SDK 可从 http://www.oracle.com 获取/technetwork/java/javaee/downloads/index.html。如果您需要 Java EE 6 之前的版本，请点击“早期版本”链接。
You should compile against only the official Java EE API's for the level you target, for any non-developer builds. Preferably by a build engine. Preferably on a different operating system than you develop on.
For a web application this mean the appropriate servlet API as downloaded from Oracle. Similar for an enterprise application.
In my experience this is the best way to keep it straight.
Edit: Java EE SDK is available from http://www.oracle.com/technetwork/java/javaee/downloads/index.html. If you need an older version than Java EE 6, then follow the "Previous Releases" link.
您可能会遇到诸如 MethodNotFoundError 之类的问题。您通常可以通过确保服务器上安装的 jar 版本匹配来解决这些问题。
You can get issues such as MethodNotFoundError. You can usually resolve these by making sure versions of jars installed on the servers match.
您通常希望在部署的地方进行开发。使用 tomcat 与 jetty 进行开发可能稍微困难，但是您已经发现了 jar 冲突的潜在混乱问题，因此使用 tomcat 进行开发似乎不值得，因为您部署到雄猫？
此外，通常通过花时间编写 ant（或其他）任务来将代码部署到开发容器，可以减轻针对 tomcat/您选择的容器进行开发的痛苦。工作周期为
1) 编写新代码
2）确保测试通过
3) 运行“重新部署”脚本
4) 在正在运行的实例中查看
您可能想要这样做。
最后，本着松散耦合的精神，如果可以避免的话，您可能不想依赖特定于容器的库；仅将其作为绝对的最后手段。
you typically want to develop where you deploy. It might be slightly harder to develop with tomcat vs jetty, but you have identified a potential mess of a problem with jar conflicts, so doesn't it seem worth it to develop with tomcat, since you deploy to tomcat?
Also, typically the pain of developing against tomcat/your container of choice is mitigated by putting in the time to write a ant (or other) task that will deploy your code to your development container. The work cycle bemoes
1) Write new code
2) make sure tests pass
3) run your 'redeploy' script
4) poke around in the running instance
You probably want to do that.
Finally, in the spirit of loose coupling, you probably do not want to depend on a container-specific libraries if you can avoid it; only do that as an absolute last resort.