[
https://issues.apache.org/jira/browse/BIGTOP-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701458#comment-13701458
]
Sean Mackrory commented on BIGTOP-939:
--------------------------------------
There's a couple of specific problems this was inspired by, but the more
general motivation is your 4th point: currently all the Tomcat configuration is
under /usr. This patch moves most of it to /etc so if you need to tweak it in
an unanticipated way, your changes are honored by the package manager. Now for
some specific use-cases:
BIGTOP-811. We can add /var/lib/bigtop/* to the classpath at build-time, but as
the original intent was to detect the MySQL Java connector if it was installed
by packages (in /usr/share/java) and the idea of detecting it and creating
symlinks in /var/lib/bigtop was -1'd, this is the only other way I see to
dynamically add it to the classpath. Because of Tomcat, Sqoop 1.99.x and Oozie
won't be able to pick additional classpath entries from the environment.
BIGTOP-881. In order to enable HTTPS/SSL, users would have had to make several
changes to the configuration under /usr. At the time the solution was to deploy
two independent pre-built configurations and have the user choose the one they
wanted Tomcat to use in the defaults file. With this patch, the configuration
can be edited, there's only a single of configs, and that feature is very easy
to turn on. I feel like SSL is a common enough feature that supporting the
relevant config changes out of the box would be nice, but I'm not 100% married
to the idea. At the very least we ought to move the configs to /etc and stop
shipping 2 pre-built configs, though.
There are already more examples of this kind of thing in a certain distribution
downstream of Bigtop, which leads me to believe these kinds of things will
likely continue to come up. In very general terms, I think having Tomcat
applications manage their configuration this way will allow Bigtop to continue
making the experience easier without having to get one's hands dirty in the
embedded Tomcat stuff.
> 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
>
>
> 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
