oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rishi Verma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OODT-649) Add PathUtils.replaceEnvVariables() wrapper around retrieved context parameters
Date Wed, 07 Aug 2013 18:57:56 GMT

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

Rishi Verma commented on OODT-649:

Hey Ross,

Couple responses:

Regarding initialization, how about from a concurrency/multiple-user point of view? Is it
ok for simultaneous requests to use the same XmlRpcFileMgrClient? If so, could we have a single
XmlRpcFileMgrClient instance for the whole JAX-RS service (to be used by all resources/responders)?


Perhaps we could extend the default servlet we're currently using (org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet)
and perform some initialization in the init() method of our new class. For example, we could
set up the XmlRpcFileMgrClient (if we only need one) and also read in all of the configuration
files there.
class ProductServlet extends CXFNonSpringJaxrsServlet
  public void init(ServletConfig configuration) throws ServletException
    // get context parameters
    // initialize XmlRpcFileMgrClient
    // read XML configuration files, set up configuration instances
If this seems like a good approach, the next thing for me to work out would be a good way
of making this information (client and configs) accessible from the service/resource classes.

After taking a look at the JAX-RS spec (see [1] below), it seems that the instantiation of
a single XmlRpcFileMgrClient for ALL request end-point instances may not be possible within
the confines of a Resource class. Looks like each resource request instantiates a new Resource
class instance, and invokes the associated constructor. In other words, placing the XmlRpcFileMgrClient
instance within an individual request end-point versus the Resource class' constructor may
be functionally identical.

Given the above, I think it makes sense to have a single XmlRpcFileMgrClient instance for
the each Resource class you define, but with the knowledge that each HTTP request is going
to instantiate a new class instance. Also, in terms of concurrency, I think we are OK, because
JAX-RS is based on Servlets, and typically a new Thread is generated per HTTP session with
the user.


Regarding context parameters, I noticed that there are also some defined in the (src/main/webapp/WEB-INF/)web.xml



Would it make sense to transfer all of these to the context.xml file and have them all in
one place there? Or is it preferable to have some defaults specified in web.xml?

Interesting. I'm wondering if these take precedence over the context.xml? If so, is the context.xml
ever being read and used? In any case, following the DRY principle [2], its best to declare
resources in a single place. So, yeah, I think it makes sense to move everything to the context.xml
if possible. 

Great work work Ross! We're both learning something from this discussion, this is absolutely
great. Send me more questions when you have them!


[1] https://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-190003.1
[2] http://en.wikipedia.org/wiki/Don't_repeat_yourself

> 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