[MAGNOLIA-411] public instance in deployed war file Created: 26/May/05  Updated: 20/Jul/05  Resolved: 20/Jul/05

Status: Closed
Project: Magnolia
Component/s: build
Affects Version/s: 2.1 Final
Fix Version/s: 2.1 Final

Type: Improvement Priority: Blocker
Reporter: Pascal Mangold Assignee: Boris Kraft
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

We need to have not only an author instance in our dropable .war file, but a public instance too. This solves many issues on our mailinglist
Or in another case we need a clean description what to do to create a public instance



 Comments   
Comment by Boris Kraft [ 27/May/05 ]

I'd go with two bootstrap directories or the like

Comment by Philipp Bracher [ 14/Jul/05 ]

those files are also different

  • web.xml (log4j properties)
  • repositories.xml (other binding names for the repositories

we could make something like web.xml.public, repositories.xml.public

Is this a blocker for 2.1? don't think so.

Comment by Michael Aemisegger [ 14/Jul/05 ]

In my custom build process I solve this requirement with different instance specific property files for the ant tasks (e.g. author.env.properties and public.env.properties). Additionally, during the build process ant replaces filter tokens with instance specific values (e.g. port numbers, file paths and the like) which again are maintained in instance specific property files (e.g. author.filter.properties and public.filter.properties).

I guess, you could do the same with maven.

Comment by Philipp Bracher [ 18/Jul/05 ]

maven uses jelly and the ant tasks are an integral part of jelly. This means that we could use the same scripts as you do (or we could at least base on them).

If you like to share those scripts, you are welcome

Comment by Fabrizio Giustina [ 18/Jul/05 ]

I already have a working and production-tested solution for this, not sure if we want to commit it for 2.1.

  • step 1: a new initializer which reads properties from a magnolia.properties file instead of web.xml. This IHMO also makes magnolia easier to integrate in existing webapps, reducing the configuration that need to be merged in web.xml. This is ready and I can commit it to svn (without touching the existing initializer) if it's ok.
  • step 2: an extension to the property initializer which let you specify different set of configurations depending on the environment. I already use this to select different configuration files depending on the server name: I usually generate a single webapp, containing all the configuration, which can be deployed without any change to different servers (where I require a different, absolute path for repositories and a different repository configuration - cqfs for development, fs for test/production)
    In WEB-INF config I add a folder for any environment, eg:
    WEB/INF/CONFIG
    dev/
    magnolia.properties
    log4j.xml
    repositories.xml
    srvProd/
    magnolia.properties
    log4j.xml
    repositories.xml
    ...

At startup, the initializer looks for a folder with the same name of the server and, if available, loads the magnolia.properties contained in such folder. If not available the default configuration (in my situation the one in "config/dev") is loaded.

In order to handle different webapps loaded in the same server we can add another variable, so that at startup the initializer looks for:

  • config/servername/webappname (specific configuration for server and webapp name)
  • config/servername (unique configuration for the server)
  • config/webappname (default configuration for webappname)
  • config/default (standard safe configuration)

With this, adding a different configuration in config/magnoliaPublic and config/magnoliaAdmin will do the trick. Everithing will be included in the standard distribution and configuration will be changed on the fly by just renaming the war. Of course we should warn users about this "magic webapp name" stuff.

Comment by Philipp Bracher [ 18/Jul/05 ]

Sounds good

Some questions in advance:

  • which properties are in this mangolia.properties (the context parameters?)
  • what is about the different bootstrap (security entries, subscriibers, ..)

I made a method which loads properties from a propertyfile into the repository. I have done this for module developers but it could help in this context too?

See: info.magnolia.cms.module.ModuleUtil.registerProperties()

in the public propertyfile we would write things like:
server.secureURIList.0001.URI=./magnolia*

What do you think about?

Comment by Philipp Bracher [ 18/Jul/05 ]

After a short reflecation i think we should not introduce it for 2.1. This magic configuration could confuse a lot of users.

For the first step i will make an ant task replacing the importent stuff based on regexps.

Comment by Fabrizio Giustina [ 18/Jul/05 ]

Good for me, I will start adding the new initializer in svn just like an "advanced option for power users" Everything will be left unchanged if the initializer class is not changed in web.xml

> - which properties are in this mangolia.properties (the context parameters?)
yes, all the context parameter, this is a sample property file:

magnolia.cache.startdir=cache
magnolia.upload.tmpdir=tmp
magnolia.exchange.history=history
magnolia.repositories.config=WEB-INF/config/dev/repositories.xml
log4j.config=WEB-INF/config/dev/log4j.xml
magnolia.root.sysproperty=magnolia.root
magnolia.bootstrap.dir=WEB-INF/dev-bootstrap

> - what is about the different bootstrap (security entries, subscriibers, ..)
in the properties file you can set the magnolia.bootstrap.dir to a different directory and package multiple set of configurations in the same war.

Comment by Philipp Bracher [ 18/Jul/05 ]

>> - what is about the different bootstrap (security entries, subscriibers, ..)
> in the properties file you can set the magnolia.bootstrap.dir to a different
> directory and package multiple set of configurations in the same war.

I thought about something like a modification of the bootstrap (xml files), so that we don't have to make an extra export after each change in the configuration (having two directories).

How ever we can extend the property file and behavior later on.

From the usability point of view i would prefer a context parameter (web.xml) which defines the configuration directory. This would avoid this magic directory naming.

Comment by Fabrizio Giustina [ 18/Jul/05 ]

another proposal which should take the best of all:

  • add a configuration entry in web.xml for the name of the properties file (so you can add any no-magic static name and you only need to change this single entry)
  • allow 2 magic variables in the file name: ${servername} and ${webapp}, so you can still use the auto-changing configuration as described above
Comment by Philipp Bracher [ 18/Jul/05 ]

this is white magic and no voodoo then

+1

Comment by Philipp Bracher [ 18/Jul/05 ]

For the current release i made a postGoal for war:war-resources to manipulate the files depending on the magnolia.build.instance maven-property.

For the xml manipulating it would be nicer and saver to use xslt instead of the replace tag.

If someone knows how to change an attribute having the path to it, I would be glad to get the xsl file.

But having Fabrizios multi configuration still makes sence.

Comment by Philipp Bracher [ 19/Jul/05 ]

uses now xslt transformation for manipulating the bootstrap files.

I will add a new task: multi configuration

Comment by Boris Kraft [ 20/Jul/05 ]

Change fix version to RC2

Generated at Mon Feb 12 03:17:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.