| Summary: | www-servers/tomcat-5.5.17 - support j2se 1.5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alon Bar-Lev (RETIRED) <alonbl> |
| Component: | New packages | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | wltjr |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 129511, 139214 | ||
| Bug Blocks: | |||
| Attachments: |
tomcat-5.5.17.ebuild.diff
tomcat-5.5.17.ebuild.diff tomcat-5.5.17.ebuild.diff |
||
|
Description
Alon Bar-Lev (RETIRED)
2006-07-04 11:23:05 UTC
Created attachment 90873 [details, diff]
tomcat-5.5.17.ebuild.diff
struts is actually a dependency used by like the admin and manager interfaces iirc. I don't think so. Since: 1. It compiles... :) 2. It does not come with the binary distribution. When are you see it being used? I am sure it was being used at some point. Maybe that was with 5.0, and has since gone away with 5.5. If you migrate this patch to the new java build, I will learn and do it for other packages as well... :) Created attachment 90978 [details, diff]
tomcat-5.5.17.ebuild.diff
Hi!
This patch uses the new java build environment. It should be OK, please check it out.
I still don't know how to create dependencies based on the ACTIVE jvm...
It is not documented at the "Gentoo Java Packaging Guide", and I don't think portage supports this.
Regards.
We are going to hold off using the new Java system right off. We want to stabalize it as soon as possible, and using the new Java system may delay it. Hmmm.... I cannot say that I understand what you say... If you don't use it, how do you stabalize it? But before you do stop, am I wrong in not finding a way to modify package dependencies based on the active java version? When I said we're holding off using the Java system, I meant in regards to having tomcat and it's dependencies (specifically mx4j-3.0.1), use the new eclasses. With regards, to deps, no, there's not a way to change dependencies based on what version of Java is being used. This is because dependencies are determined before which VM is used at build time. Additionally, it would be undesirable to do so, because the builds would be nondetermininstic. By this, I mean different files get installed if you emerge with 1.4 or 1.5, without some way to control it. The preferred way would be to have a USE flag for it, likely java5. However, this needs to be considered a bit, because use flags with versions have been a touchy subject in the past. Created attachment 90991 [details, diff]
tomcat-5.5.17.ebuild.diff
OK.
Added java5 use flag. This should be a standard...
Notice that I cannot compile tomcat using java 1.5 and source 1.4... So if not use java5 must be java 1.4.
I am currently the unofficial maintainer of Tomcat on Gentoo till I become and official dev. With that said I will to address these issues in order. With regard to 1.5. Due to so many reason I will not go into here, research if you want to know, it's taken a while to get 1.5 into the tree. In that time, Tomcat 5.5 has been released, and upstream heavily deprecates usage of 5.0.x. Thus our main priority is getting a newer version of tomcat into the stable tree as soon as possible. Which means for now Tomcat 5.5 will not be ported to use 1.5. You are more than welcome to compile it with that if you like, or make your own ebuilds. I more recommend running it under 1.5 at this time, than compiling. Tomcat 5.5.17 is currently in ~arch. Hopefully within the month if we don't get any bug reports it will be into arch. At which time I will update Tomcat's ebuild to be a generation 2 ebuild. So it can be compiled with 1.4, 1.5, or 1.6 if one choose to do such. Since it's not likely for the new java system, required for 1.5, much less all of it's packages to stablize faster than Tomcat. Again the main priority is getting a newer version of Tomcat into portage. Also for the record, most of upstream is really against our compiling Tomcat on Gentoo. Due the amount of problems Gentoo Tomcat users have had in the past. Which I am trying to minimize and stabilize. Thus not trying to strip down or stream line Tomcat or it's compile time deps at this time. With regard to struts. I am not sure why you assume Tomcat 5.5 does not require struts at all during build? You can clearly see a Stuts revision bump to 1.2.7 here with 5.5.13. http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Furthermore if you look at the build.properties.default file, Core Optional Libraries, struts is one. However it's also mentoined before the Core Optional Library section. Now I have been slowly working with upstream to determine what role core optional libraries play. They will not prevent Tomcat from compiling, howevrer could prevent Tomcat from being complete. Or equivalent to the binary release. Which there have been already reported problems with versions compiled from source, vs binary. So not trying to make that any worse at this time. It's possible some of this stuff might be use flag dep in the future. However till I get further confirmation from upstream as to what it turns on or off. It's going to remain. Another example is log4j, despite Tomcat 5.5. using juli. At this time, struts is used for the admin web app. I have no plans to ever make the admin app optional via a use flag. Thus till upstream uses a different framework for the admin web app. That dep will remain. Second problem is either a generation issue, or something not related to Tomcat. So not going to address in this bug. You can seek information on that else where. Like https://svn.gentooexperimental.org/svn/java/migration/docs/java-devel.html I am not sure if the third one is referring to runtime or compile time. Please clarify. If compile time, see wiki. If runtime, see http://www.gentoo.org/proj/en/java/tomcat-guide.xml about /etc/conf.d/tomcat-5.5 Thank you for your patches, and I might take them into consideration when I go to migrate. However since research has not been done on the struts aspect. Those changes are incorrect in your patches. I will update the Tomcat docs future section to mention migrating the ebuild to generation 2. The reason for the delay, timeline, and etc. Till then I will request this bug be closed or at least marked as an enhancement. Since this is more of an enhacement request bug, than problem bug. Thank you for the detailed response. I hope you complete your research soon. How about adding a new ebuild (-r1) that is masked to allow people to use generation2/j2se 1.5? So you can go stable with current ebuild, but allow people to use (test) tomcat as commonly used in other platforms... Which download binaries and use it with the j2se 1.5? Regarding struts, add it if it is required. I trust you know much better than I what is needed, I agree that admin should always be provided. But I don't see its jar included in the official binary distribution... But I may missed it. Thank you again. I have no interest in maintaining or working with two ebuilds for Tomcat 5.5.x at the moment. We have other unresolved issues that must be resolved. Otherwise changes in one will have to be applied to both. I do not have time for all that. For the last time, there is nothing stoping you from running Tomcat 5.5.17 via JRE 1.5. Compiling it with 1.5 is a moot issue to me at this time. It will come, but it's not critical and no rush. 1.4 is not set to be EOL anytime soon. So long as Tomcat compiles, is complete and runs. Those are the main goals. If you are so bent on 1.5. Edit /etc/conf.d/tomcat-5.5 to a 1.5 jre. Done. No different than downloading an official binary and running it under 1.5. Now again. Struts is required to compile and make the admin web app. /usr/share/tomcat-5.5/server/webapps/admin/WEB-INF/lib/struts.jar Where it is in the offical binary I have no clue. Find the admin web app, and it will be in there. OK. I see I made you angry.
But still... not everyone see eye to eye.
You are in contact with upstream... Do they compile their official distribution using 1.4 or 1.5?
It just that using 1.5 require a MUCH LESS dependencies, so it can be MUCH MORE stable and MUCH faster.
The 1.4 stuff is forced by gentoo environment... Not by upstream, on the contrary, upstream recommends of using 1.5, right?
And for the admin stuff, I've looked again into the distribution, and this is what I've found:
Tomcat's administration web application is no longer installed by default.
Download and install the "admin" package to use it.
So I guess you should add an admin use flag, to be as closest to upstream as possible, no struts for default build.
That's it... I will continue to use my ebuild, I hope people that are interested will do the same. I won't bother you again.
Yes because I do not want to keep discussing this. Every minute I have to spend responding to these types of issues. Is more time taken away from pushing the package further. Moving to 1.5 is not going to effect deps at all. Not sure were you got that from. Probably based on similar assumptions of struts. FYI, upstream recommends running on 1.5. UPSTREAM DOES NOT RECOMMEND COMPILING TOMCAT FROM SOURCE, AT ALL. Regardless of the JDK. However they have provided a compat package so Tomcat could be compiled with 1.4. If they did not want people doing that. They would not have spent time making the compat package. I will see about a use flag for the admin app, but for it to accomplish what you are after, less deps. That will require NOT COMPILING the admin stuff, beyond the install aspect. FYI the examples use flag controls if examples/docs are installed, they are compiled either way. So initially adding a admin use flag would only effect install. Till I get time to work through compiling with or without. I don't see that in the near future. I might do that when I migrate the ebuild to gen 2 for compilation with 1.5. Has anyone tested the current version with Data sources?
I get the following error in the catalina.xx.log on startup:
Jul 19, 2006 4:36:59 PM org.apache.catalina.core.NamingContextListener addResource
WARNING: Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory]
This is using a context file as below
<?xml version='1.0' encoding='utf-8'?>
<Context debug="9" docBase="finance.war" path="/finance/" reloadable="true">
<Resource
name="jdbc/finance"
type="javax.sql.DataSource"
username="user"
password="password"
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://localhost/db"
scope="Unshareable"
maxActive="10"
maxIdle="100"
/>
</Context>
This works using a binary install of tomcat I have but not with the new source version. The missing class is in common/lib/naming-factory-dbcp.jar
Paul
Not really related to current topic of this bug. However that is a known problem and issue. Mentioned in the Tomcat Guide, http://www.gentoo.org/proj/en/java/tomcat-guide.xml also previously mentioned on this bug. Under usage section. tomcat-5.5.17-r2 has been migrated to generation 2 java ebuilds. Java 1.5 can now be used to compile Tomcat via the java5 USE flag. Hi!
I get many errors when compiling with jdk1.5...
build-catalina-cluster:
[javac] Compiling 73 source files to /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/build/build/classes
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/ClusterSession.java:21: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpSession;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/ClusterSession.java:23: cannot find symbol
[javac] symbol: class HttpSession
[javac] public interface ClusterSession extends Session, HttpSession {
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationValve.java:25: package javax.servlet does not exist
[javac] import javax.servlet.ServletException;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java:36: package javax.servlet does not exist
[javac] import javax.servlet.ServletContext;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java:38: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpSessionAttributeListener;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java:39: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpSessionBindingEvent;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java:40: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpSessionBindingListener;
[javac] ^
[javac] /var/tmp/portage/tomcat-5.5.17-r2/work/apache-tomcat-5.5.17-src/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java:41: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpSessionContext;
[javac] ^
[...more...]
This has already been fixed in cvs, should hit mirrors soon. There was more than one attempt at fixing. I recomend waiting a good 12-24 hours before syncing and attempting to emerge again. |