Tomcat中常见的JNDI资源
我正在 Tomcat (5.5) 中运行几个 servlet 应用程序。所有 servlet 都使用通过 JNDI 共享的公共工厂资源。目前，我可以通过将工厂资源作为 GlobalNamingResource 包含在 /conf/server.xml 文件中，然后让每个 servlet 的 META-INF/context.xml 文件包含指向该资源的 ResourceLink 来使一切正常工作。下面包含 XML 文件的片段。注意：我对tomcat不太熟悉，所以我并不是说这是一个很好的配置！
然而，我现在希望能够使用 RPM 自动将这些 servlet 安装到多个 tomcat 实例中。 RPM 首先会将 WAR 复制到 webapps 目录，并将工厂的 jar 复制到 common/lib 目录（这很好）。但还需要确保将工厂资源作为所有 servlet 的资源包含在内。
全局添加资源的最佳方式是什么？我不太热衷于编写一个进入 server.xml 文件并以这种方式添加资源的脚本。 有什么方法可以添加多个 server.xml 文件，以便我可以编写一个新的 server-app.xml 文件并将我的设置连接到 server.xml？或者，最好将此 JNDI 资源添加到所有 servlet，而不使用 server.xml？
ps 重新启动服务器不会成为问题，所以我不介意更改是否不会自动生效。
感谢
server.xml 中的片段
<!-- Global JNDI resources -->
<GlobalNamingResources>
<Resource name="bean/MyFactory"
auth="Container"
type="com.somewhere.Connection"
factory="com.somewhere.MyFactory"/>
</GlobalNamingResources>
整个 servlet 的 META-INF/context.xml 文件
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<ResourceLink global="bean/MyFactory"
name="bean/MyFactory"
type="com.somewhere.MyFactory"/>
</Context>
I’m running a couple of servlet applications in Tomcat (5.5). All of the servlets use a common factory resource that is shared out using JNDI. At the moment, I can get everything working by including the factory resource as a GlobalNamingResource in the /conf/server.xml file, and then having each servlet’s META-INF/context.xml file include a ResourceLink to the resource. Snippets from the XML files are included below. NOTE: I’m not that familiar with tomcat, so I’m not saying that this is a good configuration!!!
However, I now want to be able install these servlets into multiple tomcat instances automatically using an RPM. The RPM will firstly copy the WARs to the webapps directory, and the jars for the factory into the common/lib directory (which is fine). But it will also need to make sure that the factory resource is included as a resource for all of the servlets.
What is the best way add the resource globally? I’m not too keen on writing a script that goes into the server.xml file and adds in the resource that way.
Is there any way for me to add in multiple server.xml files so that I can write a new server-app.xml file and it will concatenate my settings to server.xml? Or, better still to add this JNDI resource to all the servlets without using server.xml at all?
p.s. Restarting the server will not be an issue, so I don’t mind if the changes don’t get picked up automatically.
Thanks
Snippet from server.xml
<!-- Global JNDI resources -->
<GlobalNamingResources>
<Resource name="bean/MyFactory"
auth="Container"
type="com.somewhere.Connection"
factory="com.somewhere.MyFactory"/>
</GlobalNamingResources>
The entire servlet’s META-INF/context.xml file
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<ResourceLink global="bean/MyFactory"
name="bean/MyFactory"
type="com.somewhere.MyFactory"/>
</Context>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从 Tomcat 4 开始，建议不要将任何 JNDI 信息放入 server.xml 文件中。查看 Tomcat 5.5 的文档：
我知道您声称不关心这个，但相信我，您的部署团队会关心，维护团队稍后会感谢您。即使这意味着你最终会感谢自己。
如果您需要在服务器上的所有 Web 应用程序之间共享 JNDI 设置，则应将其放入文件 $CATALINA_HOME/conf/context.xml 中。很可能，该位置已经存在一个现有的 context.xml，但您应该能够编写一个简单的应用程序，通过您最喜欢的语言以及与之捆绑的任何 DOM 构建器来添加资源节点。或者，如果您想坚持使用命令行，请查看这篇文章，它提供了一些 XML 处理 shell 脚本来帮助您。
祝你好运！
Since Tomcat 4, the recommendation has been not to put any JNDI information in the server.xml file. Check Tomcat 5.5's documentation:
I know you claim not to care about this, but trust me, your deployment team does, and the maintenance team will thank you later. Even if this means you end up thanking yourself.
If you need a JNDI setting to be shared among all webapps on a server, you should put it into the file $CATALINA_HOME/conf/context.xml. In all likelihood, there will be an existing context.xml already in that location, but you should be able to write a simple app to add your resource nodes via your favorite language and whatever DOM builder comes bundled with it. Or, if you want to stick with the command line, check out this article, which gives a few XML-processing shell scripts to help you out.
Good luck!
实际上，我们有一种情况，我们不能将（例如）jdbc 配置放入战争中：客户永远不会让我们知道生产服务器的用户名和密码，因此我们必须在全局服务器配置中定义数据源并在其中放置一个链接应用程序的 context.xml，就像操作一样。
全局配置可以放在server.xml中，也可以放在tomcat的context.xml中（似乎windows平台上更喜欢第二种方法）。
actually we have a case where we cannot put (for example) jdbc configuration in the war: the customer will never let us know username and password for the production server, so we had to define the datasource in global server configuration and put a link in the context.xml of the app, like the op did.
The global configuration can be put either in server.xml or in tomcat's context.xml (it seems that the second approach is the one preferend on windows platform).
这并没有直接回答您的问题，但是您是否考虑将所有配置放入 context.xml 文件中，而不是 server.xml 中？这使得您的 Web 应用程序更加完全独立，这对于您的部署要求来说听起来很重要。
我想说的是，如果目前无法做到这一点，那么可能值得考虑任何必要的重构，以确保您的应用程序可以完全独立。
我曾参与过部署 /common/lib JAR 和公共资源的项目，并以令人困惑和微妙的方式被它们所困扰（顺便说一句，我最终发现这些总是我自己的错，而不是在这里责怪 Tomcat），我现在更喜欢完全我的网络应用程序的保护方法：让它们完全独立。
当然我并不完全了解你的情况，只是提供一些建议。
This doesn't directly answer your question, but have you instead considered putting all your config inside your context.xml file, instead of in server.xml? This makes your web-app more fully self-contained, which sounds important to your deployment requirements.
I'd go as far to say it might be worth considering any refactoring necessary to ensure your apps can be fully self-contained if this can't be done at present.
Having worked on projects where I deployed /common/lib JARs and common resources, and been bitten by them in confusing and subtle ways (I eventually found out these were invariably my own fault btw, not blaming Tomcat here), I now favour a completely protective approach to my webapps: keep 'em completely independent.
But of course I don't fully know your circumstances, just some suggestions.
这就是我要做的，我使用的是 Maven 3，我会将
server.xml放在我的resources目录或其他一些我可以运行filter< 的目录中当我打包时，/code> 上并动态替换并生成适当的server.xml。然后，您可以使用 maven-rpm-plugin 并自动生成 rpm。This what I would do, I am using Maven 3, I would put the
server.xmlin myresourcesdirectory or some other directory I can run afilteron and dynamically replace and generate an appropriateserver.xmlwhen I do a package. You could then use the maven-rpm-plugin and automate the rpm generation as well.