[Bug 435829] Review Request: tomcat6 - Apache Servlet/JSP Engine, RI for Servlet 2.5/JSP 2.1 API

bugzilla at redhat.com bugzilla at redhat.com
Wed Apr 2 18:44:55 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: tomcat6 -  Apache Servlet/JSP Engine, RI for Servlet 2.5/JSP 2.1 API


https://bugzilla.redhat.com/show_bug.cgi?id=435829





------- Additional Comments From pcheung at redhat.com  2008-04-02 14:44 EST -------

(In reply to comment #22)
> Jason Corley suggested in comment #20 doing something with the unversioned jsp
> and servlet provides. Are these backwards compatible or not? Otherwise, why even
> keep them at all. I am not sure that we can version the other provides since the
> version is the tomcat version, which would not be the case with some other API
> provider, presumably.
> 
It seems Jason Corley suggested versioning of provides/obsoletes, unversioned
will match any versioned provides/obsoletes. For the ones that are the tomcat
version, should the version be the same as the tomcat version then?

> The license was ASL 2.0 in the past rpms. I changed it back to what JPackage
> had. This seems correct according to the Fedora wiki. I think rpmlint is just
> wrong here.
> 
I think rpmlint has been updated with the new license format.

> I will fix the coreutils BuildRequires.
> 
Great!
> I don't think we can mark the doc webapp as doc. We can't mark any content
> needed to run as doc. Docs must be 100% optional.
> 
OK.
> We usually check for the existence of /usr/share/java-utils/java-functions
> first. I can do this, but why? We already Requires: jpackage-utils, so it must
> exist.
> 
I saw it in the other scripts, and this one is missing, so I thought that should
be here too.

> /srv is fixed
> 
> The other two are more complicated. I find java using java-functions, but I left
> most of the script the same as JPackage. It is probably fine, but it could use
> java-functions more.
> 
> About the initscript, I changed most of what I could. The reason we can't
> necessarily use the built-in killproc function is that: (1) we had to call
> "stop" to stop the server---but Jason Brittain told me that tomcat should do the
> right thing when it receives a KILL signal (I haven't verified this) (2) if the
> PID file is missing, it will try to find the tomcat6 process (clearly wrong,
> it's some java process), and I don't know how the PID file will go missing in
> practice.
> 
> For startup, maybe we could use the daemon function? Right now it's hardcoded to
> call runuser if it exists and su if not.
> 
> The main issue is that the initscript is not using the standard functions making
> the code large and difficult to maintain. For example, the initscript output was
> broken because it was overriding some built-in functions from
> /etc/init.d/functions. Jason Corley told me that most of this was due to
> incompatibilities in the Fedora and RHEL functions, but I would rather write the
> script in the standard way and deal with this problem if/when it arises for us.
> 
Sounds good.


-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the package-review mailing list