different WAR files, shared resources

后端 未结 6 1558
醉话见心
醉话见心 2021-01-02 13:36

Suppose you have several applications which share the same code and most of the other resources, but have a somewhat different look and feel, some labels change, etc. (thin

相关标签:
6条回答
  • 2021-01-02 14:16

    A strategy that I have seen used for such product-line like configurations is using WAR overlays when building with maven. You define a common WAR that contains the common stuff and overlay it with those other WARs that contain the specific stuff to generate different WARs for every application. This method is probably most useful if you deploy the WAR-variants on different machines. But I'm not sure whether I can actually recommend this.

    Remember to specify the overlays configuration if you actually override stuff, since otherwise the overriding order is not deterministic. It might even change with a maven-war-plugin upgrade. (It did in our case.)

    0 讨论(0)
  • 2021-01-02 14:16

    If you don't want to go the EAR route, using tomcat, etc; there are a few other ways to achieve the consistency you want.

    If you want to share just js and css, look into pack:tag. You could host the .js and css from an apache server, set up your httpd.conf so your webapps can call it, then use pack:tag from your application wars - DRY and compression in one step.

    0 讨论(0)
  • 2021-01-02 14:19

    How about putting your css and js in the classpath and serve them with a servlet? Then you can build the common resources as a jar and that jar can even contain the servlet (resource dispatcher if you like) and the war files can contain the jar file in the WEB-INF/lib folder.

    0 讨论(0)
  • 2021-01-02 14:34

    You can deploy both WARs in the same EAR and put common resources in the EAR. Then put the appropriate dependencies in the manifest of the web apps to link to the jar files in the ear.

    0 讨论(0)
  • 2021-01-02 14:35

    Thanks for the replies so far, but I'm afraid I forgot to mention that the WARs will be deployed in different environments that are completely isolated from each other.

    So maybe having a common WAR deployed next to the actual application is the only option. I think I'll go with the following:

    • WAR1, WAR2 containing app-specific stuff
    • CommonWAR containg common stuff (no kidding)
    • EAR1: WAR1 + CommonWAR, to be deployed in env1
    • EAR2: WAR2 + CommonWAR, to be deployed in env2
    0 讨论(0)
  • 2021-01-02 14:36

    Update

    Yes, me again. I have actually changed my mind (again :) ). I am currently trying (being more prudent here):

    • (Common)WAR: containing the application, common (most part) + some specific stuff
    • EAR1: CommonWAR + specific configuration file for env1
    • EAR2: CommonWAR + specific configuration file for env2

    The configuration file is picked up by the WAR. It is on the the EAR classpath and only contains one property 'application' with a value. The single WAR will then use this information where appropriate to distinguish between the two apps (config, style sheets, ...).

    With my solution of EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, it was too difficult or impossible to lookup static resources in the CommonWAR without using a web url (e.g. images in PDF documents generated with iText).

    0 讨论(0)
提交回复
热议问题