You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Sean Mackrory (JIRA)" <ji...@apache.org> on 2013/08/01 01:23:49 UTC

[jira] [Updated] (BIGTOP-939) Make usage of bigtop-tomcat more dynamic

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

Sean Mackrory updated BIGTOP-939:
---------------------------------

    Attachment: 0001-BIGTOP-939.-Make-usage-of-bigtop-tomcat-more-dynamic.patch

So what do you think of this approach? Because I quite like it. As you suggested, it uses an alternatives symlink to switch between the "default" configuration and the "secure" configuration. Also, there were still some configuration files under /usr/lib/oozie/webapps.../WEB-INF, but I've also moved that to be stored under /etc and found at runtime under /var.

I will still do a bit more testing and cleanup of this, and probably relocate WEB-INF files for other services, but I think what I've done for Oozie addresses all of Bruno's concerns, so I wanted to see if there were any other thoughts on the approach.
                
> Make usage of bigtop-tomcat more dynamic
> ----------------------------------------
>
>                 Key: BIGTOP-939
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-939
>             Project: Bigtop
>          Issue Type: Task
>            Reporter: Sean Mackrory
>            Assignee: Sean Mackrory
>            Priority: Blocker
>             Fix For: 0.7.0
>
>         Attachments: 0001-BIGTOP-939.-Make-usage-of-bigtop-tomcat-more-dynamic.patch, 0001-BIGTOP-939.-Make-usage-of-bigtop-tomcat-more-dynamic.patch, 0001-BIGTOP-939.-Make-usage-of-bigtop-tomcat-more-dynamic.patch
>
>
> Projects like Oozie and Sqoop present some configuration challenges compared to other components because they use Tomcat. Sometimes small tweaks to the configuration or classpath have to be done in a very component-specific way as opposed to tweaking files in /etc/<comp>/conf or /etc/default. In one case, we even have redundant Tomcat deployments for common configurations (Oozie's SSL vs.  non-SSL).
> If the environment for Tomcat was generated more dynamically, we could avoid this redundancy and could allow common features to be configured in more "standard" ways.

--
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