[jira] [Issue Comment Deleted] (OODT-649) Add PathUtils.replaceEnvVariables() wrapper around retrieved context parameters

["Ross Laidlaw (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OODT-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ross Laidlaw updated OODT-649:
------------------------------

    Comment: was deleted

(was: Hi Rishi,


Thanks for your great advice and guidance as always.  Here are my thoughts:



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 thinking about flexibility vs speed.  I was hoping to make the webapp configuration more flexible, so it could be updated on the fly, i.e. changing properties without having to restart the webserver or redeploy the webapp.  That was my thinking when moving the XmlRpcFileMgrClient instantiation and other setups into the REST end-point methods.  I thought that in this way, if properties (e.g. the file manager URL and/or working directory) were changed, these changes would then be picked up without having to reinitialize/restart anything.

But looking over my code I think this could still be moved to an initializer or constructor, because I've attempted to set up the service classes to have a per-request lifecycle (briefly explained in [1]), using the following servlet parameter in web.xml:

{code}
<init-param>
  <param-name>jaxrs.scope</param-name>
  <param-value>prototype</param-value>
</init-param>
{code}


In either case, the disadvantage is slower response times, because having the extra setup code in the REST end-point methods (or per-request instances with the setup code in constructors/initializers) increases the time between sending requests and receiving responses.  While the flexibility is handy during development, perhaps many users would have stable configuration files that wouldn't need to be updated very often.  For those cases, singleton service classes with initial setups might give faster responses and might be better if speed is a key requirement.



Ross



[1] http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-ConfiguringJAXRSservicesincontainerwithoutSpring)
    
> 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