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 13:53:48 GMT

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

Ross Laidlaw commented on OODT-649:
-----------------------------------

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

Mime
View raw message