FirstSpirit environment specific module configurations in web apps

[king]

Dear FirstSpirit community,

according to best practices many software solution providers do offer specific infrastructure environments for:

• D (development)
• Q (quality)
• P (production)

In case where you want to follow FirstSpirit best practices and want to generate the live web application for FirstSpirit projects based on the FirstSpirit Administration Console (see screenshots enclosed), you can get separate WARs for D,Q,P that just differ in their configurations they contain. The generated WAR (D/Q/P) depends on the FirstSpirit environment you use.

A JAVA framework, that allows integrating different environment specific configurations in applications and dynamically selecting them depending on a JVM variable, can be found here:

http://easyconf.sourceforge.net/

The problem: from our point of view it is not possible, to provide just ONE single WAR having all environment specific configurations inside. Are we wrong?

We just wonder:

- which possibilities might exist to get rid of that problem?

- is there already a FirstSpirit solution existing that we do not see?

[jpee]

Hallo Mr. King,

as if I understood correctly you want to download a war file from the FirstSpirit admin view containing 3 configurations. I have no clue how to consolidate this with the 3 FirstSpirit-tabs preview, qa and production on firstspirit-side because they are running in 3 different webapps. Maybe you could use a service in the store event of the configuration of the actual webapp downloading the property-files of the other 2 webapps in preview and staging.

But what about having three different configuration forms inside of the configuration panel of one e.g. production, which map on different kinds config files e.g. dev.properties, qa.properties, prod.properties or maybe in one with different variables.

How is easy conf usually used? Inside of the webapp, so the webapp manages a reload of configfiles by itself? If yes then the explained way could be a solution.

Greetings

Johannes Perlet

[king]

Hi Johannes,

it's clear, that for each tab, a separate WAR file is generated. Because, as you said, each tab within the FirstSpirit Admin Console offers an individual web application for custom "/fs4preview","/fs4staging", "/fs4webedit" and content delivery web applications (where custom application logic is implemented).

What we want to realize is, that each application get's all environment specific configuration files, In consequence we would like to have:

• /fs4preview_<project_id>
  • D/Q/P environment configuration included
• /fs4staging_<project_id>:
  • D/Q/P environment configuration included
• /fs4webedit_<project_id>:
  • D/Q/P environment configuration included
• live web application:
  • D/Q/P environment configuration included

The problem: if we want to follow your suggestion, where the configuration offers environment specific configuration forms, all FirstSpirit components that allow a GUI configuration have to be adapted in their implementation. Even the one, that FirstSpirit offers in FirstSpirit standard modules.

Am I right?

It might be better, if no GUI implementation changes might be necessary. To reach that, it might help to offer the Administrator the opportunity to add external configuration files within the GUI. They follow a naming convention like:

- bgn_d.conf

- bgn_q.conf

- bgn.conf

These configuration files are just referenced in the GUI using a variable that is being set dependent on the environment. Then each generated FirstSpirit web application should contain EasyConf to resolve the variable at runtime and load the correct file.

To my understanding this is a feature request for the core FirstSpirit product. Correct?

[jpee]

Hi Holger,

ok that seems to be complicated. Ad hoc I have no idea how to solve that problem by FirstSpirit standard methods.

I'm no expert to aspectj, but what I did was implementing caching inputs and outputs of some methods which compute complex algorithms. With it you can extend java code where you don't have the source and can inject code which will perform pre and post different methods.

If all modules extend the FirstSpirit WebApp-Config class, maybe that could be an approach to extend all module configurations without recompiling them.

But then there is still the issue if EasyConf can inject it's funcionality to the FirstSpirit modules.

Have a nice weekend

Johannes Perlet

[feddersen]

If you're looking for a solution for your custom modules, I'd recommend to use external configuration files. Use EasyConf to read a system property that contains the path to the configuration file for your module. In many companies the "ops" team is in control of the configuration files and system properties. The developer just provides the application artifact, which can be deployed to any system as is.

That wouldn't work for the FirstSpirit modules, they all expect their configuration within the war file.