XPPWS Tomcat init.d startup script (RHEL 5) to systemd startup (RHEL 7)

RWS front-line support has told me that a Linux startup script (i.e. in /etc/init.d for older versions of Red Hat EL) was never something that was included/delivered with XPPWS Tomcat.

Why do I have one? I didn't invent this; it was delivered, probably around 10-11 years ago on Red Hat EL 5.3 with XPP 8.something and XPPWS 1.2. I did personally tweak it to work on a newer Red  Hat server (EL 5.5?) with XPPWS 1.3, maybe 6 years ago. 

I am seeking an updated one to work with Red Hat EL 7.x (where init.d is obsolete and everything is now a service under systemd/systemctl). We've *almost* got it figured out all on our own, but I thought I'd ask support about a current systemd startup on reboot. So I was surprised to get the, "nope, never delivered anything like that." 

What say you, XPP hive mind?

Old server:

/etc/rc.d/rc5.d/S81SDL_License -> ../init.d/SDL_License
/etc/rc.d/rc5.d/S90xyenterprise -> ../init.d/xyenterprise
/etc/rc.d/rc5.d/S92xppws -> ../init.d/xppws
/etc/rc.d/rc5.d/s99contenta -> ../init.d/contenta

Parents
  • I don't like it when I cannot give a "complete" answer, so I did a bit more research. This time I did that using the documentation.

    It's not posted on the docs.rws.com web site any more, but I found a source document for XPP Web Services 1.2 Installation and Release Notes. In that document it does talk about the init.d S92xppws startup script that gets delivered and installed into the init.d services on Linux for automatically starting Tomcat.

    However, in the latest "install" document for XPP Web Services 1.3 I see that all of the discussions of the delivered and installed init.d service file on Linux was (consciously) removed.

    I cannot say for sure (this goes back to 2013), but I'd guess that with the change to using an InstallAnywhere-based installer that the decision was made to no longer have the XPP WS installer do anything to deliver or install a startup script for Tomcat.

    Or perhaps the change in "policy" wasn't really related to the change in how the installer worked, but it was just changed at the same time as changing the installer technology.

    Perhaps more likely is that we found that with new versions of Tomcat that it became a "moving target" to try to keep up with how to correctly set up the init.d startup script, and/or that it didn't make sense for the XPP WS installer to be setting up a startup script for Tomcat since it is not an XPP-delivered product. After all, I believe that XPP WS is really just an "add on" to Tomcat in that we deliver files that then are used by the Tomcat "engine". Or maybe there was a "conflict" because the Tomcat installer was itself setting up a startup script.

    Whereas AFAIK that is not true for XPP RESTful WS, where we deliver the "engine" as well as all the "helper" files and so the installer does deliver and install an init.d startup script (and this installer also is InstallAnywhere-based so the change for the XPP WS installer was not due to just that).

    In any case, what I think we really missed doing was to add an explicit statement into the XPP Web Services 1.3 "install" document that the responsibility for setting up a startup script for Tomcat was (now) the user's responsibility (as the XPP WS installer would no longer do that), rather than only leaving it implied by having removed all the stuff about the startup script from it.

    Anyway, hopefully that's a more "complete" answer.  Slight smile

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • Jonathan, I love the "why" answer, and I completely relate to not being able to let go of things like this. I am legendary within Tweddle for sending explanations like yours in emails to people who will never read them (TL;DR). 

    Anyway, it is the most helpful to know that I'm not going crazy. And I do understand from firsthand experience that S92xppws is a "moving target" ... the fickle nature of Java requirements and installations (and 32-bit vs 64-bit) being one of the bigger annoyances. It does need to start as a service in our environment; it is a conundrum for both of us that Tomcat is not a delivered product, but XPPWS as a Tomcat webapp is (requiring Tomcat to inherit certain XPP environment settings). We will figure it out now that we know more about what doesn't work, and why.

    I would love to transition to RESTful WS, but we have so much invested in legacy code in Tridion Docs "publish to XPP" tools that we'd have to go through a major rewrite. Probably not going to happen on my watch (I am 64 and toying with the "R word").

Reply
  • Jonathan, I love the "why" answer, and I completely relate to not being able to let go of things like this. I am legendary within Tweddle for sending explanations like yours in emails to people who will never read them (TL;DR). 

    Anyway, it is the most helpful to know that I'm not going crazy. And I do understand from firsthand experience that S92xppws is a "moving target" ... the fickle nature of Java requirements and installations (and 32-bit vs 64-bit) being one of the bigger annoyances. It does need to start as a service in our environment; it is a conundrum for both of us that Tomcat is not a delivered product, but XPPWS as a Tomcat webapp is (requiring Tomcat to inherit certain XPP environment settings). We will figure it out now that we know more about what doesn't work, and why.

    I would love to transition to RESTful WS, but we have so much invested in legacy code in Tridion Docs "publish to XPP" tools that we'd have to go through a major rewrite. Probably not going to happen on my watch (I am 64 and toying with the "R word").

Children
No Data