[
https://issues.apache.org/jira/browse/OOZIE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645863#comment-14645863
]
Arvind Jayaprakash commented on OOZIE-2317:
-------------------------------------------
Glad that this question is now out in wild. There are multiple interpretations
and the responses depends on it
*(a) The _only_ web-container on which Oozie is officially supported is
reaching EOL; what do we do for continuity?*
The obvious answer here is simply move to a newer version (of tomcat) and
follow the standard tomcat upgrade procedure
*(b) The _only_ web-container on which Oozie is officially supported is
reaching EOL; this seems like a good time to review our web container support
matrix. What should we certify on?*
The first thing to do is to call out which specifications is Oozie coded
against i.e. which servlet spec, jsp spec, etc. etc. The tomcat page referenced
in the ticket description calls out the capabilities of tomcat but having the
Oozie expectations spelt out should make it easier for people to run it on any
other web container such as JBoss AS, glassfish, jetty, etc. etc.
*(c) Should we use this opportunity to see if Oozie should be a webapp at all
or does it make sense to make it a standalone app?*
This is much more of a philosophical question that needs to be addressed
regardless of what is happening to tomcat 6. I believe that Oozie is primarily
not a webapp to begin with. Sure it has an administrative web console and a
HTTP REST API but those are just interfaces to the core functionality. I'd
prefer to have a standalone binary that could be launched as a daemon much like
how RM, NN, etc. etc. operate.
The easiest transition path is to start using embedded jetty. This would
immediately meet the _"works as a standalone app"_ need without causing any
significant redesign of the application lifecycle management as jetty would be
able to honour the standard servlet/web-app lifecycle management hooks. A more
involved and cleaner design would entail Oozie managing its own application
lifecycle which embedded jetty being just a module within the app that gets
activated to provide the web console and the REST gateway. These two styles of
refactoring Oozie as a standalone application could be almost indistinguishable
from each other thus giving us the time to reach the _clean_ state.
Hence, my preference would be to migrate as follows:
# Have an embedded jetty/standalone model for Oozie right away
# The same artifact can have a webapp style packaging to provide continuity in
style of operation for existing users. See how jenkins is packaged to get an
idea of how the same artifact can both be run as a standalone executable and
also be deployed into a container. We provide instructions on how to launch
this in a few popular web containers
# Retire the webapp model in the long run and have the application lifecycle be
a first class concern with embeddedjetty just being a convenient way to provide
the HTTP gateways into what is fundamentally not a webapp
> Figure out what to do about Tomcat 6 End of Life
> ------------------------------------------------
>
> Key: OOZIE-2317
> URL: https://issues.apache.org/jira/browse/OOZIE-2317
> Project: Oozie
> Issue Type: Bug
> Components: core
> Affects Versions: trunk
> Reporter: Robert Kanter
>
> [Tomcat 6 will be end of life on Dec 31
> 2016.|https://tomcat.apache.org/tomcat-60-eol.html]
> Even though that's a quite a while from now, it's best to stay ahead of
> things, so it would be good if we looked into a plan for this.
> Here are some options:
> # Upgrade to Tomcat 7
> # Upgrade to Tomcat 8
> # Switch to embedded Jetty 9
> I imagine upgrading to Tomcat 7/8 would be the easiest solution. I haven't
> looked into it much, but I imagine the build and deploy process could remain
> relatively the same; though we'd probably have to tweak some config files and
> things. As for which version, Tomcat has [this
> page|https://tomcat.apache.org/whichversion.html] to help.
> Switching to embedded Jetty 9 would require changing the build and deploy
> process, though that might be a good thing given how that can be
> complicated/confusing for users. And I know Tomcat makes things difficult
> for our packaging team in Cloudera. Many other Hadoop projects use embedded
> Jetty as well. We do know that Oozie runs properly in Jetty because our unit
> tests use Jetty.
> As part of this JIRA, the assignee should probably look into more specific
> pros/cons of the options and we should all reach a consensus before moving
> forward.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
