| Summary: | www-servers/tomcat-5.5.23-r6 doesn't support JDK-1.4 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jiri Tyr <jiri.tyr> |
| Component: | New packages | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 191611 | ||
| Bug Blocks: | |||
| Attachments: |
package.env
emerge.info dep.txt |
||
|
Description
Jiri Tyr
2007-09-17 09:11:37 UTC
Looking into this, seems to be a problem or bug with gjl. Since it's what does a java bytecode version check or etc on the package before trying to run it with an improper vm version. You should not see or get that error, without the java5 USE flag set. You should be able to run tomcat with a 1.4 vm if the java5 USE flag is not set. Works just fine here. pena kde # grep sun-jdk /etc/conf.d/tomcat-5.5 # Example: GENTOO_VM="sun-jdk-1.5" GENTOO_VM="sun-jdk-1.4" # JSSE_HOME="/opt/sun-jdk-1.4.1.02/jre/lib/" pena kde # /etc/init.d/tomcat-5.5 start tomcat-5.5 | * Caching service dependencies ... [ ok ] tomcat-5.5 | * Starting Tomcat ... [ ok ] betelgeuse@pena /var/tmp/portage/x11-apps/grandr-0.1/work/grandr-0.1 $ qdepends -k USE tomcat-6 | grep java5 betelgeuse@pena /var/tmp/portage/x11-apps/grandr-0.1/work/grandr-0.1 $ You need to give output of: qdepends -k USE tomcat-6 | grep java5 grep GENTOO_VM /etc/conf.d/tomcat-5.5 eselect java-vm list (In reply to comment #3) > You need to give output of: > qdepends -k USE tomcat-6 | grep java5 aaa ~ # qdepends -k USE tomcat-5 | grep java5 aaa ~ # > grep GENTOO_VM /etc/conf.d/tomcat-5.5 aaa ~ # grep GENTOO_VM /etc/conf.d/tomcat-5.5 # Example: export GENTOO_VM="sun-jdk-1.5" export GENTOO_VM="blackdown-jdk-1.4.2" aaa ~ # grep JSSE_HOME= /etc/conf.d/tomcat-5.5 JSSE_HOME="/opt/blackdown-jdk-1.4.2.03/jre/lib/" > eselect java-vm list aaa ~ # eselect java-vm list Available Java Virtual Machines: [1] blackdown-jdk-1.4.2 system-vm [2] sun-jdk-1.5 And forgot to add: gjl -p tomcat-5.5 --get-vm GENTOO_VM=blackdown-jdk-1.4.2 gjl -p tomcat-5.5 --get-vm (In reply to comment #5) > And forgot to add: > gjl -p tomcat-5.5 --get-vm aaa ~ $ gjl -p tomcat-5.5 --get-vm gjl_vm="sun-jdk-1.5" > GENTOO_VM=blackdown-jdk-1.4.2 gjl -p tomcat-5.5 --get-vm aaa ~ $ GENTOO_VM="blackdown-jdk-1.4.2" gjl -p tomcat-5.5 --get-vm gjl_vm="sun-jdk-1.5" So where are we at with this? Did we find a global bug, or ruling it out as a local issue? (In reply to comment #7) > So where are we at with this? Did we find a global bug, or ruling it out as a > local issue? > Well for some reason gjl thinks his Tomcat needs >=1.5 but it does not seem to be compiled with java5 support. I also noticed that emerge --info is missing and also please attach /usr/share/tomcat-5.5/package.env Created attachment 131541 [details]
package.env
Created attachment 131543 [details]
emerge.info
I'm having the same issue. However it doesn't seem to bother tomcat, it starts and works properly. It's just annoying There is not much I can do here to resolve this. I can't replicate the problem. Furthermore I really didn't want to add the check to the init script in the first place. Others felt it would be a fail safe for users who did IMHO dumb stuff like emerge tomcat with java5 flag and leave the system vm as 1.4 or etc. One of the main reasons I did not want to add such fail safes. Was because it allowed users to be lazy and not pay attention by relying on a failsafe. Another reason was potential bugs that could arise from it like this one. So if we can't track down and resolve. Others continue to be effected by it and etc. I will just remove the fail safe check from the init script. Those that relied on it as a fail safe, will just have to pay more attention :) Ok, let me take a newb stance. If I do patch this and etc. Will we then be looking to rush stabilize it, to address the security issue? That seems like the logical steps if we are acting on a security issue no? Likely will just go ahead and just patch to make all happy and move on with this. Just sucks, because Tomcat 5.5.25 was just stabilized. So will have to get others involved there again. Was just hoping to limit extra work for all, unless it was absolutely necessary. Damit commented on wrong bug, sry for spam. I got an idea about this bug. gjl would report that 1.4 can't run Tomcat even if USE="java5" is not on if you have something in the deptree that is 1.5 binary. Could you please run the following: for jar in $(java-config -dp tomcat-5.5 | tr ":" " "); do class-version-verify.py -t 1.4 $jar >/dev/null || echo $jar; done (In reply to comment #15) > for jar in $(java-config -dp tomcat-5.5 | tr ":" " "); do > class-version-verify.py -t 1.4 $jar >/dev/null || echo $jar; done Here is the result of the command: $ for jar in $(java-config -dp tomcat-5.5 | tr ":" " "); do class-version-verify.py -t 1.4 $jar >/dev/null || echo $jar; done $ It didn't print any line. It means that all packages are compiled with Java 1.4 right? It should be, because I have set 1.4 VM as the system VM: $ java-config -L The following VMs are available for generation-2: *) Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2] 2) Sun JDK 1.5.0.13 [sun-jdk-1.5] What about this. Make sure the java5 use flag is disabled globally. Do an explicit -java5 in make.conf USE flags. Then do a emerge -DNpv world to see if anything is picked up as having it's use flag change. If nothing shows up there, and the other suggestion doesn't return any jars. Then it's really hard to determine what is causing this. At the moment we are leaning toward it coming from some dep that was compiled with java5 USE flag, and/or compiled to 1.5 bytecode. Thus gjl or etc is picking it up there and spitting out error/warning. Created attachment 137376 [details]
dep.txt
There are couple of packages which need jdk >= 1.5. Maybe this case the error. What do you think?
(In reply to comment #17) > What about this. Make sure the java5 use flag is disabled globally. Do an > explicit -java5 in make.conf USE flags. Then do a emerge -DNpv world to see if > anything is picked up as having it's use flag change. I tried it but it didn't give me any java package with USE="-java5" to recompile. (In reply to comment #19) > > I tried it but it didn't give me any java package with USE="-java5" to > recompile. > It's probably best for us to write some debug info into gjl and get the answer straight from the horse's mouth. Please post the output of: betelgeuse@pena ~ $ grep 'TARGET="1.5"' /usr/share/*/package.env (In reply to comment #21) > Please post the output of: > betelgeuse@pena ~ $ grep 'TARGET="1.5"' /usr/share/*/package.env $ grep 'TARGET="1.5"' /usr/share/*/package.env /usr/share/sun-javamail/package.env:TARGET="1.5" (In reply to comment #22) > (In reply to comment #21) > > Please post the output of: > > betelgeuse@pena ~ $ grep 'TARGET="1.5"' /usr/share/*/package.env > > $ grep 'TARGET="1.5"' /usr/share/*/package.env > /usr/share/sun-javamail/package.env:TARGET="1.5" > Does this go away when you re-emerge sun-javamail? If so please post the output of qlop -l sun-javamail and qdepends -k repository sun-javamail. (In reply to comment #23) > Does this go away when you re-emerge sun-javamail? If so please post the output > of qlop -l sun-javamail and qdepends -k repository sun-javamail. I reemerged the sun-javamail and I executed the commands: $ qlop -l sun-javamail Wed Dec 5 10:36:59 2007 >>> dev-java/sun-javamail-1.4 $ qdepends -k repository sun-javamail dev-java/sun-javamail-1.4: gentoo During the emerge -av1 sun-javamail, I have got this messages: >>> Emerging (1 of 1) dev-java/sun-javamail-1.4 to / * sun-javamail-1.4.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking sun-javamail-1.4.tar.bz2 ;-) ... [ ok ] * Using: sun-jdk-1.5 >>> Unpacking source... >>> Unpacking sun-javamail-1.4.tar.bz2 to /var/tmp/portage/dev-java/sun-javamail-1.4/work >>> Source unpacked. ... I said that it use sun-jdk-1.5 instead of 1.4. Couldn't it be the problem? (In reply to comment #24) > * Using: sun-jdk-1.5 > >>> Unpacking source... > >>> Unpacking sun-javamail-1.4.tar.bz2 to /var/tmp/portage/dev-java/sun-javamail-1.4/work > >>> Source unpacked. > ... > > I said that it use sun-jdk-1.5 instead of 1.4. Couldn't it be the problem? > No. That's expected and wanted. I am guessing that this bug existed in sun-javamail at some point in distant past and most people have since re-emerged it and as such fixed the problem. How come you only have one entry for sun-javamail? Have you been a paludis user or something? paludis is known to have had problems with our eclasses. You also didn't answer whether re-emerging fixed the problem or not. (In reply to comment #25) > You also didn't answer whether re-emerging fixed the problem or not. I'm sorry I forgot to restart tomcat ;o) Now it works for me: /etc/init.d/tomcat-5.5 restart * Stopping Tomcat ... [ ok ] * Starting Tomcat ... [ ok ] Thank you for your collaboration. |
