oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Laidlaw (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OODT-649) Add PathUtils.replaceEnvVariables() wrapper around retrieved context parameters
Date Thu, 01 Aug 2013 14:55:50 GMT

    [ https://issues.apache.org/jira/browse/OODT-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726492#comment-13726492

Ross Laidlaw commented on OODT-649:

Hi Rishi,

Many thanks for your great advice and guidance as always.  Here are my thoughts/questions:

RE suggestion #2:

I see exactly what you mean and I'll raise an issue and attach a patch to add more validation
and logging to the setups.

RE suggestion #1:

I was aiming to improve the flexibility of the webapp, but I probably misunderstood how the
context.xml configuration is processed by webservers (e.g. Tomcat).  During development and
testing I found that when I made updates to the context.xml file, these weren't always automatically
picked up by my Tomcat setup (my understanding was that Tomcat should redeploy the webapp
automatically and include the changes, but instead I'd have to restart Tomcat for the changes
to take effect - e.g. for the original Data, RDF and RSS servlets).  So I thought that by
moving some parameter retrieving (e.g. XmlRpcFileMgrClient instantiation with the file manager
URL context parameter) into the REST end-point methods this would ensure that any property
changes (e.g. file manager URL or working directory) would always be picked up without the
need for manual restarts/redeployment.

But looking over my code, I think that even though I used this approach, I still could have
moved the setup code to an initializer or constructor anyway, because I tried to set up the
service classes to have a per-request lifecycle (briefly explained in [1]), using the following
servlet parameter in web.xml:


Either way, I appreciate that the disadvantage of doing this (for both of the above methods)
is that the instantiation and additional setup code will slow down response times, as it will
be executed for each request.  Plus it would be unnecessary if Tomcat (and other webservers)
pick up any context changes automatically.

I'll try to learn more about contexts so I can fix my setup to pick up context changes without
having to read them in on every request.  Moreover, I'll raise a JIRA issue and attach a patch
ASAP to follow your suggestions.  


> Add PathUtils.replaceEnvVariables() wrapper around retrieved context parameters
> -------------------------------------------------------------------------------
>                 Key: OODT-649
>                 URL: https://issues.apache.org/jira/browse/OODT-649
>             Project: OODT
>          Issue Type: Sub-task
>          Components: product server
>    Affects Versions: 0.7
>            Reporter: Ross Laidlaw
>            Assignee: Ross Laidlaw
>            Priority: Minor
>              Labels: gsoc
>             Fix For: 0.7
>         Attachments: OODT-649.rlaidlaw.2013-07-27.patch.txt
> Methods in several classes in the cas.product.service.resources package retrieve parameters
from the servlet context using the context.getInitParameter(String parameterName) method call,
for example as follows:
> {code}
> setWorkingDirPath(context.getInitParameter("filemgr.working.dir"));
> {code}
> But these parameters may contain environment variables such as [HOME] or [FMPROD_HOME],
etc.  Currently, these aren't processed properly and the getInitParameter call needs to be
wrapped in a call to PathUtils.replaceEnvVariables() (from the cas-metadata module) to process
the environment variables, for example as follows:
> {code}
> setWorkingDirPath(PathUtils.replaceEnvVariables(
>   context.getInitParameter("filemgr.working.dir")));
> {code}
> This is already done in the original Data, RDF and RSS servlets but was accidentally
omitted from the new resource classes in the cas.product.service.resources package.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message