使用Maven在Tomcat中动态运行WAR,如何添加类路径条目,以便只有Tomcat可以看到它们? [英] Using Maven to run a WAR dynamically in Tomcat, how does one add classpath entries so only Tomcat sees them?

查看:63
本文介绍了使用Maven在Tomcat中动态运行WAR,如何添加类路径条目,以便只有Tomcat可以看到它们?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

场景是这样的:我有一个Web应用程序,我想与tomcat-maven-plugin的解决方案

我可能遗漏了一些东西,但是为什么不在配置文件中声明所需的依赖项并在运行Tomcat时使用此配置文件呢?我不明白为什么您需要将这些资源放在Tomcat的类路径级别.

更新:我正在编辑我的答案,以涵盖OP回答上述问题的评论.

您是正确的,文件确实需要在webapp类路径中,而不是tomcat的文件中.那么,如何制作一个可以自动激活tomcat:run但没有其他cmd行参数的配置文件?

我不知道如何将配置文件声明为<activeByDefault>或将其列出在<activeProfiles>下(但这不是我的初衷,我宁愿使用属性激活并调用类似mvn tomcat:run -Denv=test,不确定为什么会出现问题.

我应该如何在配置文件中声明依赖项",同时确保后续调用永远不会通过香草mvn程序包将其允许进入WAR程序包

如果默认情况下上述配置文件处于活动状态,那么如果您不希望使用它,则需要通过调用mvn package -P !profile-1之类的方法将其排除.不能出于某个特定目的而神奇地停用个人资料(至少,据我所知).

实际上,我的理解是,您在这里确实有两个不同的上下文:测试"上下文(要在WAR中包含更多内容)和正常"上下文(不希望这些内容存在)被包括在内).坦白地说,我不知道如何在不指定任何其他参数的情况下(根据情况激活配置文件或停用配置文件)来区分这两种情况.您必须有正当的理由,但是,正如我所说,我并不真正理解为什么这是一个问题.因此,配置文件可能无法解决您的情况.但是我真的很想理解为什么,因为这似乎是配置文件的典型用例:)

UPDATE2:在阅读了您对另一个答案和更新的评论后,我意识到我的最初理解是错误的(尽管您在谈论Maven方面的依赖).但是,我仍然认为配置文件可以为您提供帮助,例如按tomcat:run goal. The wrinkle is that I have numerous classpath resources that need to differ between the packaged artifact and the one run off a local workstation.

Failed Attempts:

1.) My first attempt was to use the builder-helper-maven-plugin, but it won't work because the target configuration files will (inconsistently!) work their way into the packaged WAR archive.

<plugin>    
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>build-helper-maven-plugin</artifactId>
 <version>1.3</version>
 <executions>

  <execution>     
   <id>add-resource</id>
   <phase>generate-resources</phase>
   <goals>
    <goal>add-resource</goal>
   </goals>
   <configuration>
    <resources>
     <resource>
      <directory>${basedir}/src/main/resources-env/${testEnv}</directory>
      <targetPath>${basedir}/target/classes</targetPath>
     </resource>
    </resources>
   </configuration>
  </execution>
 </executions>
</plugin>

2.) My second attempt was to add the folder (since the files-to-be-deployed aren't present in Tomcat's classpath yet either) to -Djava.ext.dirs, but it has no effect (I actually suspect that this systemProperties element is misconfigured or otherwise not working at all). See:

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>tomcat-maven-plugin</artifactId>
 <version>1.0-beta-1</version>
 <configuration>
  <tomcatWebXml>${basedir}/src/main/mock/web.xml</tomcatWebXml>

  <systemProperties>
   <property>
    <name>java.ext.dirs</name>
    <value>${basedir}/src/main/resources-env/${testEnv}</value>
   </property>      
  </systemProperties>      
  <path>/licensing</path>
 </configuration>
</plugin>

I'm not sure what to attempt next. The heart of the problem seems to be that missing in this plugin is something like Surefire's <additionalClasspathElement> element.

Would the next step be to create a custom catalina.properties and add it to a <configurationDir>? If so, what would catalina.properties need to look like?

Edit: More thorough explanation follows

I understand this question reads somewhat vaguely, so I'll try to elaborate a bit.

My POM uses the webResources functionality of the WAR plugin to copy some environment-specific config files and without using a profile to do it, by copying in a resource named /src/main/resources-env/${env} like so:

...
<plugin>    
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
        ...
    <configuration>
            ...
        <webResources>
            <!-- Copy Environment-specific resources to classes -->
            <resource>
                <directory>${basedir}/src/main/resources-env/${env}</directory>
                <targetPath>WEB-INF/classes</targetPath>
            </resource>
        </webResources>
    </configuration>
</plugin>

This will copy the (default, DEV) environment resources into the package and currently works fine. Note also that b/c these occur as part of packaging, the tomcat:run goal is never privy to them (which is desired, as the environments differ).

So the problem is this: when the dynamic tomcat:run is executed, the application will fail because its classpath (it looks at target/classes) will lack the needed local workstation environmental config files. All I need to do is get those on the path for tomcat, but would like to do so without adding anything to the command line and definitely without breaking the build's integrity if someone follows up with a mvn package and doesn't clean first.

I hope this is more clear.

解决方案

I may be missing something but why don't you declare the required dependencies in a profile and use this profile when running Tomcat? I don't get why you would need to put these resources at Tomcat's classpath level.

UPDATE: I'm editing my answer to cover the comment from the OP itself answering my question above.

You're correct, the files really need to be in the webapp classpath, not tomcat's. So how could I make a profile that activate automatically for tomcat:run but without additional cmd line args?

I don't know how to do this without declaring the profile as <activeByDefault> or listing it under the <activeProfiles> (but this is not what I had in mind, I would rather use property activation and call something like mvn tomcat:run -Denv=test, not sure to understand why this is a problem).

And how should I "declare the dependencies" in the profile while ensuring that subsequent invocations never let them into the package WAR via a vanilla mvn package

If the previously mentioned profile is active by default, then you'll need to exclude it if you don't want it, by calling something like mvn package -P !profile-1. A profile can't be magically deactivated for one particular goal (at least, not to my knowledge).

Actually, my understanding is that you really have two different context here: the "testing" context (where you want to include more things in the WAR) and the "normal" context (where you don't want these things to be included). To be honest, I don't know how you could distinguish these two situations without specifying any additional parameter (either to activate a profile or to deactivate it depending on the context). You must have valid reasons but, as I said, I don't really understand why this is a problem. So maybe profiles are not a solution for your situation. But I'd really like to understand why because this seems to be a typical use case for profiles :)

UPDATE2: Having read your comment to the other answer and your update, I realize that my initial understanding was wrong (I though you were talking about dependencies in the maven sense). But, I still think that profiles could help you, for example to customize the <resources> as in this blog post (this is just one way to do, using a property like src/main/resources/${env} in the path is another way to go). But this won't solve all your concerns (like not specifying additional command line params or automagically cleaning the target directory). I don't have any solutions for that.

这篇关于使用Maven在Tomcat中动态运行WAR,如何添加类路径条目,以便只有Tomcat可以看到它们?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆