Here's a listing of the directory structure hadoop and similar bits
produce in their builds:
http://paste.fedoraproject.org/48849/13825327
There's a some stuff in there that's can obviously be paired down.
Here's the script used to start/stop the service:
http://paste.fedoraproject.org/48852/38253290
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.
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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
