[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23886#action_23886
]
Danilo Ghirardelli commented on MAGNOLIA-2644:
----------------------------------------------
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. :-)
> Allow property initializer to use also servlet context attributes.
> ------------------------------------------------------------------
>
> Key: MAGNOLIA-2644
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2644
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.6.3, 4.0
> Reporter: Danilo Ghirardelli
> Assignee: Philipp Bärfuss
> Attachments: ServletContext-attrib-env.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
