On Wed, Oct 23, 2013 at 1:57 PM, Robert Rati <rrati(a)redhat.com> wrote:
Here's a listing of the directory structure hadoop and similar
bits produce
in their builds:
http://paste.fedoraproject.org/48849/13825327
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:
http://paste.fedoraproject.org/48852/38253290
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(a)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(a)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(a)lists.fedoraproject.org
>>>>
https://admin.fedoraproject.org/mailman/listinfo/java-devel