> On Oct. 6, 2016, 11:04 p.m., Robert Kanter wrote:
> > distro/src/main/bin/oozie-jetty-server.sh, lines 40-61
> > <https://reviews.apache.org/r/52399/diff/5/?file=1525932#file1525932line40>
> >
> >     IMO, we should move as many of these as possible to oozie-default/site. 
> >  We had a bunch of these as JVM properties before because of Tomcat and 
> > other reasons, but it would be good to have them all in the same place as 
> > other config properties.  At the very least, the https/ssl ones (the other 
> > ones are probably out of scope for this JIRA).

Because the way Services and ConfigurationService classes are constructed we 
still need to pass some properties as system properties:

  jetty_opts="-Doozie.home.dir=${OOZIE_HOME}";
  jetty_opts="${jetty_opts} -Doozie.config.dir=${OOZIE_CONFIG}";
  jetty_opts="${jetty_opts} -Doozie.log.dir=${OOZIE_LOG}";
  jetty_opts="${jetty_opts} -Doozie.data.dir=${OOZIE_DATA}";
  jetty_opts="${jetty_opts} -Doozie.config.file=${OOZIE_CONFIG_FILE}";
  jetty_opts="${jetty_opts} -Doozie.log4j.file=${OOZIE_LOG4J_FILE}";
  jetty_opts="${jetty_opts} -Doozie.log4j.reload=${OOZIE_LOG4J_RELOAD}";

ConfigurationService is initialized by passing in a Services object (that is 
initialized)
However, oozie home needs to be known in Services init, so we cannot get it 
from ConfigurationService (that depends on Services).
Similarly Log4j properties are used in Services' init(). 

In my opinion, Services and ConfigurationService would benefit a lot from code 
clean up / refactoring. It is out of scope of this task I believe.


- Attila


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52399/#review151728
-----------------------------------------------------------


On Oct. 13, 2016, 2:17 p.m., Attila Sasvari wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52399/
> -----------------------------------------------------------
> 
> (Updated Oct. 13, 2016, 2:17 p.m.)
> 
> 
> Review request for oozie, András Piros, Peter Cseh, Peter Bacsko, and Robert 
> Kanter.
> 
> 
> Repository: oozie-git
> 
> 
> Description
> -------
> 
> Embedding jetty into Oozie so that it can run as a standalone application. 
> The changes also try to address OOZIE-2317 (i.e. Tomcat 6 is EOL).
> 
> New functionality
> - New module (server) is added that sets up an embedded Jetty server and 
> start Oozie services. Servlet mapping is done by reading web.xml of webapp at 
> runtime. JSP is handled with custom code. Server version is not revealed in 
> server repsonses.
> - SSL protocols and ciphers can be configured via system properties and 
> environment variables. Precedence: system properties, environment variables, 
> default values
>    
> Changes in existing code
> - Excluded jetty 6 dependencies from core and updated tests accordingly  
> 
> Packaging
> - oozie.sh is modified so that it starts Oozie with embedded jetty by 
> default. If someone would like to use tomcat for any reason, they can set an 
> environment variable (e.g. OOZIE_USE_TOMCAT=1).
> 
> TODO:
> - Add more tests
> - Add more documentation
> - Code cleanup + refactoring in packaging and core parts
> - Maven clean up
> - Allow to tune more Jetty settings (for example threadpool)
> - More security measures (e.g. protect against clickjacking, CSRF, etc.)
> - Update Oozie Documentation
> 
> 
> Diffs
> -----
> 
>   core/src/main/java/org/apache/oozie/util/Instrumentation.java 
> fa1e92a0f1fadfb66c5e66fea5f26f57579080e7 
>   core/src/main/resources/oozie-default.xml 
> e71ebe3b7a85e6b23176ef30713af63847144498 
>   distro/pom.xml c50572c57a376b28963d4e7da8ac7df777fe0480 
>   distro/src/main/bin/oozie-jetty-server.sh PRE-CREATION 
>   distro/src/main/bin/oozie-setup.sh 79b049bccceb2690f8a673a885a615c8d4d9578c 
>   distro/src/main/bin/oozied.sh a869c3da177c863a068f2af45c7bca9d5cb771ac 
>   pom.xml 704a2eeee9f4e4805e3e08c2a547b2a375f6b1b2 
>   server/pom.xml PRE-CREATION 
>   server/src/main/assemblies/empty.xml PRE-CREATION 
>   server/src/main/java/org/apache/oozie/server/EmbeddedOozieServer.java 
> PRE-CREATION 
>   server/src/main/java/org/apache/oozie/server/HttpConfigurationWrapper.java 
> PRE-CREATION 
>   server/src/main/java/org/apache/oozie/server/JspHandler.java PRE-CREATION 
>   server/src/main/java/org/apache/oozie/server/SSLServerConnectorFactory.java 
> PRE-CREATION 
>   server/src/main/resources/checkstyle-header.txt PRE-CREATION 
>   server/src/main/resources/checkstyle.xml PRE-CREATION 
>   server/src/test/java/org/apache/oozie/server/TestEmbeddedOozieServer.java 
> PRE-CREATION 
>   
> server/src/test/java/org/apache/oozie/server/TestSSLServerConnectorFactory.java
>  PRE-CREATION 
>   src/main/assemblies/distro.xml 1ffbfd6d2ba33b390999e9094cbb336fbce45c21 
> 
> Diff: https://reviews.apache.org/r/52399/diff/
> 
> 
> Testing
> -------
> 
> - Tested basic functionality by executing a workflow that uses the sample 
> JavaAction
>     - without SSL - on a 2.4.0 pseudo Hadoop cluster
>     - SSL with Kerberos is using a test CDH cluster 
> - Added new unit tests that check
>     - If oozie.ssl.enabled is not specified, server starts without SSL 
> settings 
>     - If oozie.ssl.enabled is specified, server starts with SSL settings
>     - SSL protocols and ciphers can be configured via system properties and 
> environment variables 
> - Ran subset of tests using Hadoop-2 profile
>     - mvn clean package assembly:single   -DjavaVersion=1.8 
> -DtargetVersion=1.7  -Dtest=TestJavaActionExecutor  -Phadoop-2 
> -Dhadoop.version=2.4.0
> 
> 
> Thanks,
> 
> Attila Sasvari
> 
>

Reply via email to