On Wed, Oct 23, 2013 at 1:57 PM, Robert Rati rrati@redhat.com wrote:
Here's a listing of the directory structure hadoop and similar bits produce in their builds:
Looks like tomcat is bundled, which itself is an issue.
There's a some stuff in there that's can obviously be paired down. Here's the script used to start/stop the service:
This whole script could be replaced by a in-house script just like /usr/sbin/tomcat, and it should be fairly easy.
A few things I've spotted: - PRG=$(readlink -f $0) could replace the whole while loop line 19 It's not portable, but we don't care since it'd work on Fedora - The so-called bug mentioned line 51 is actually documented [1] in catalina.sh It works like this by design, I'll notify upstream
It should be noted that upstream hadoop, and its ecosystem, use tomcat 6.x and as part of packaging it we've moved forward to tomcat 7.x.
Unless hadoop's code uses tomcat internals (a valve for instance) this should not be a problem. I don't have time right now do check that.
Dridi
[1] https://github.com/apache/tomcat/blob/d88ad9e/bin/catalina.sh#L36
Rob
On 10/22/2013 12:27 PM, Dridi Boukelmoune wrote:
I've installed tomcat 7 on my machine to take a quick look at how it's packaged:
- exploded FHS-compliant layout
- systemd-friendly equivalent to catalina.sh
- default configuration in /etc
Now if you want to run a tomcat instance (by instance I mean $CATALINA_BASE) /usr/sbin/tomcat seems to be the best candidate. Unlike catalina.sh, it expects a value for all the CATALINA_* variables in its environment, while catalina.sh has fall-backs relative to $CATALINA_HOME. Simply using /usr/sbin/tomcat as a substitute to catalina.sh wouldn't work of course.
Could you please post an example of what maven produces ? This would help see what could be done with simple maven configuration (eg. -Dsystem=properties) and what would require a patch (and help estimate the amount of work).
Dridi
On Tue, Oct 22, 2013 at 4:59 PM, Robert Rati rrati@redhat.com wrote:
The lack of the tomcat shell scripts is causing issue with hadoop and some of their ecosystem packages. Some are webapps with custom configuration. The maven builds all create a tomcat install area with their custom configurations. It's not too hard to take that and adapt to fedora's tomcat if the schell scripts were packaged. Then these services could be stopped/started with systemd like other services.
That's assuming catalina.sh and friends are present and functional. :)
Rob
On 10/21/2013 04:42 PM, Dridi Boukelmoune wrote:
Hi,
The catalina.sh script work with the $CATALINA_HOME (tomcat binaries) and $CATALINA_BASE (tomcat instances) directories. My guess is that tomcat is packaged as a native (previously sysvinit, and now systemd) service, and that instances wouldn't make sense. Other scripts like startup.sh are just sugar wrappers to the catalina.sh script.
When I say it wouldn't make sense, I mean that it was probably packaged to feel like any other server: sudo service tomcat start or sudo systemctl start tomcat
The package probably owns directories in /var (or somewhere else) that would make it multi-instance unfriendly.
The catalina.sh script also expects sub-directories in $CATALINA_HOME and $CATALINA_BASE. I suspect that tomcat explodes the directory layout (in /usr, /var, maybe /etc) in order to be FHS compliant, which would probably break catalina.sh and its friends.
I'll install tomcat and take a look at the package ASAP.
Dridi
On Mon, Oct 21, 2013 at 9:07 PM, Robert Rati rrati@redhat.com wrote:
I logged a bz (https://bugzilla.redhat.com/show_bug.cgi?id=990588) to request that the tomcat shell scripts (catalina.sh and the rest) be packaged. I've had some discussions with the person the bz is assigned to and few others, but no one knows why the scripts were not packaged. Nor, it seems, does anyone see a problem with them being packaged as far as I can tell.
Does anyone know some history here?
Rob
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel