[MAGNOLIA-2644] Allow property initializer to use also servlet context attributes. Created: 25/Feb/09 Updated: 23/Jan/13 Resolved: 17/Aug/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 3.6.3, 4.0 |
| Fix Version/s: | 4.1.1 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Danilo Ghirardelli | Assignee: | Fabrizio Giustina |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||||||
| 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 |
|
On some application servers is very useful to have the property configurer use also servlet context attributes and/or parameters to choose what configuration file should be loaded. |
| Comments |
| Comment by Magnolia International [ 04/Aug/09 ] |
|
This seems quite interesting; eventhough I'd rather implement this sort of thing after some refactoring though. If you could provide a couple of testcases, I'd feel more comfortable applying the patch. (i.e this would ensure refactoring will not break these new features) I had something else in mind, with basically the same goal - using an environment variable (i.e define/override magnolia.initialization.file at webapp-level in the container, much like you define a datasource) and also allow usage of OS environment variables (either by injecting their values in the value of magnolia.initialization.file, or by getting the value of magnolia.initialization.file list from the ENV) By the way, at least with Tomcat, you can already use a variable such as ${user.home} in magnolia.initialization.file; have you tried using ${com.ibm.websphere.servlet.application.host} in there directly ? |
| Comment by Danilo Ghirardelli [ 06/Aug/09 ] |
|
I tried using ${com.ibm.websphere.servlet.application.host}, but it didn't work, so I wrote the patch. I don't know if newer versions of Websphere allows something like this but I doubt, this is something really application server-dependent. Given this, I doubt that any test case will have any real meaning, if not done on the real application server. But I'll try anyway to write some. The patch I proposed needs two remarks:
Also I think having properties depending on OS vars is quite dangerous, expecially in production where I usually have little or no access to the OS and some OS maintainer guy can change something (i.e. a system update) leaving the application broken without any apparent reason. Honestly both my and your patch seems really specific to some non-standard environment. If there is a refactoring scheduled, it would be nice to have the PropertyInitializer class set (optionally) in the web.xml just like the magnolia.initialization.file. Something like magnolia.property.initialization.class = ServletContextAttributesPropertyInitializer. So Magnolia will delegate to the given class the property init. I don't know if it should be better to have the given class doing it after or instead the standard PropertyInitializer, but I think it'll cover easyly all the non-standard environment discussed above, without bothering the majority of users that uses only the default PropertyInitializer. Unfortunately opening this kind of possibility may lead to the horrible "Why don't we put our properties in the database?"-Initializer, but that's another story. |
| Comment by Fabrizio Giustina [ 17/Aug/09 ] |
|
Added a few testcases and committed. |