0

I'm working on a Grails 2.4.2 app, and the same code base is used for a variety of customers. Each customer gets the GSP based web UI customized with their own icons, text strings, etc. I've made sure that the customizations are done in the GSP pages using Groovy variables defined in Config.groovy. I.e. something like this:

customerName = ''
favicon = ''

if (appName == 'foo') {
  customerName = 'Foo'
  favicon = "favicon_${appName}.ico"
}

These variables are then referenced from within the GSP pages. This works fine. The problem is that the app needs a separate war file for each customer. So the CI server builds a war for customer A, then runs grails clean, modifies the app name etc in the application.properties file, builds the war for customer B, etc. Each war file build takes about 4.5m, multiplied by 10 customer builds. So I thought that the better way would be to build the war file once, then have the CI server copy it N times, and modify the application.properties file with the customer name, servlet context path, etc. inside each of the war files. Someone pointed out to me that the GSP pages get compiled during the war file build, and that they end up with the context path as part of the class name. This seems a little odd to me. I.e. let's say I have Customer "Foo", and I decided to build a war file called foo.war, which will be deployed at the servlet context path /foo. The the compiled result for a page "bar.gsp" will be something like this:

WEB-INF/classes/gsp_foo_bar.class
WEB-INF/classes/gsp_foo_bar_gsp_html.data
WEB-INF/classes/gsp_foo_bar_gsp_linenumbers.data

I experimented with taking the already compiled war file for customer A, changing the app name and the context, and redeploying it as customer B. It works fine, and I see customer B's icons, etc. So, the summary of the question I guess boils down to whether or not the _foo_ part ties the page to the context path /foo, or if it's simply a cosmetic thing? I certainly don't want the performance hit of lazy compiling or recompiling at run time. And because the content of the GSP page in this case is basically static and doesn't change, it seems like it wouldn't have to be tied to the context or app name. Does anyone know if it's just a naming thing, or if I'll run into problems by not recompiling the war whenever I change the app name/context? Maybe there's a better way of accomplishing what I want? Thanks.

user2337270
  • 1,183
  • 2
  • 10
  • 27
  • The internal class name of your gsps is just a way to name them. What's your real problem? You can deploy the same war with differents context paths name in the same server without any problem. Have you tried? – albertovilches Jun 02 '15 at 10:56
  • Thanks albertovilches. Yes, I have tried, but wasn't sure if there was a downside to it such as the app not being able to use the compiled pages or something like that. Glad to hear that's not the case. – user2337270 Jun 03 '15 at 17:37

1 Answers1

0

What about using the external configuration and set the favicon dynamically in your layout/template?

Grails external configuration file

Community
  • 1
  • 1
defectus
  • 1,947
  • 2
  • 16
  • 21
  • I'm not sure I understand what you mean. The favicon is referenced through a variable in the GSP page as it is now. I guess maybe I wasn't formulating my question clearly. The issue is that I need a war file per customer, and I'd like to avoid rebuilding it for each customer. But seeing the context path show up in the class name for the compiled GSP made me think that it's somehow tied to the context path. – user2337270 May 29 '15 at 20:53
  • My idea is to have an external configuration and have all these customer specific information stored there. You'd then run the applications each with its own config. As for the context, most web containers allow you to define the context path of the app - see http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file – defectus May 30 '15 at 04:57
  • That's pretty much what I'm doing. And yes, the various customer deployments have their unique context path. I think I should have rephrased the question. It's not the configuration that I'm wondering about, it's why the context path becomes part of the compiled GSP page classes, and whether or not it actually is tied to the context path after the compilation. I.e. if I decide to change the context path after creating the war file, will it cause problems with the GSPs? I'm trying to avoid having to recreate the war file for each customer (including compiling all Groovy code and GSP pages). – user2337270 May 30 '15 at 16:48