[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 |
| 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
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.
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:
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:
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: 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 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" > - which properties are in this mangolia.properties (the context parameters?) magnolia.cache.startdir=cache > - what is about the different bootstrap (security entries, subscriibers, ..) |
| Comment by Philipp Bracher [ 18/Jul/05 ] |
|
>> - what is about the different bootstrap (security entries, subscriibers, ..) 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:
|
| 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 |