[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: Text File ServletContext-attrib-env.patch    
Issue Links:
relation
is related to MAGNOLIA-2829 magnolia.properties should be loadabl... Closed
is related to MAGNOLIA-3094 Also use contextPath when resolving m... Closed
is related to MAGNOLIA-3516 Allow PropertyInitializer to also use... Closed
is related to MAGNOLIA-3521 PropertyInitializer should be pluggable. Closed
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.
This is mainly a WebSphere issue, because one of the "recommended" cluster configuration is to have multiple jvm instances on the same server. (I'm not trying to say this is a good or bad choice, I only found it on some servers) With the current property configurer there is no way to have a different configuration for each jvm, because the only difference is the "com.ibm.websphere.servlet.application.host" attribute in servlet context. This particular attribute obviously works only for WebSphere, but with the simple path I attached you could use any other servlet context attribute or parameter.



 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:

  • the part regarding servlet context params is almost redundant, because usually if something is injected in the web.xml (via maven or ant script) it can be injected as well in a property file or somewhere else. I added it just because it was clearer this way instead of having duplicate variables.
  • servlet context attributes are objects, and not strings. I was lucky enough that every attribute I needed was indeed a string, but to do this the right way I should have thought a way to state the object (as now) and also the method chain to call to get the string I need. But i didn't get a good idea on how to do such a thing, considering that attributes are accessed by string keys that can contain everything (chars, punctuation, separator...).

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.
Note that using a servlet context parameter can also be useful because you can define it in the context configuration (for example server.xml in tomcat), not only in web.xml.

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