Recently I updated from tomcat-5.5.25-r1 to 5.5.26, and some files seemed not to be accessible by Tomcat any longer. Concretely, I got errors on SAXParsers stating that an null InputStream was given, apparently because it wasn't able to locate/open the XML file; an extract of the error message follows: ** An error has been detected. Click here for more details. Error parsing pattern finder file skins/CustomSilvano/jsp/patternFinderConfiguration.xml: java.lang.IllegalArgumentException: InputStream cannot be null at javax.xml.parsers.SAXParser.parse(SAXParser.java:172) at com.transtools.tt.export.xml.HandledSaxParser.parse(SourceFile:128) at [goes on] ** At the beginning I thought it to be some config problem or similar, but when I realised the problem gets solved just reverting to tomcat-5.5.25-r1 I wondered whether it was a legitimate bug. I hope I won't miss my judgement. Reproducible: Always Steps to Reproduce: 1. Upgrade to tomcat-5.5.26 2. /etc/init.d/tomcat-5.5 restart 3. See how web-app fails. emerge --info: Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r9 i686) ================================================================= System uname: 2.6.23-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Timestamp of tree: Sat, 01 Mar 2008 22:16:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/webapps/mantisbt/1.0.8-r1/htdocs/lang" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict stricter unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.udc.es/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ http://darkstar.ist.utl.pt/gentoo/ http://distfiles.gentoo.org" LANG="es_ES.UTF-8" LC_ALL="es_ES.UTF-8" LINGUAS="es en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl apache2 bash-completion berkdb bitmap-fonts bzip2 caps cli cracklib crypt doc dri fortran gdbm iconv isdnlog java5 midi mudflap ncurses nls nptl nptlonly openmp pam pcre pppd python readline reflection session spl sse2 ssl tcpd threads truetype-fonts type1-fonts unicode vim-syntax x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Really need more info on this for it to be a bug with the Tomcat package on Gentoo. Seems possible application or Tomcat specific. No clue why you would have issues when upgrading versions of tomcat. Reverting back should make no difference. When you upgraded, did you try deleting the running/work dir's contents and restarting Tomcat? rm -f /var/run/tomcat-6/* Sounds like something was remaining from the previous version and wasn't refreshed/recompiled or something afterward. Might also need to re-deploy your app in 5.5.26.
The same error is thrown when i deploy my wars on the freshly installed Tomcat 5.5.26.When I deployed the same wars on Tomcat 5.5.23, no such errors were seen and the application is working fine. Is there any workaround for this problem, so that i could use Tomcat 5.5.26 for my application?
(In reply to comment #2) > The same error is thrown when i deploy my wars on the freshly installed Tomcat > 5.5.26. Are you deploying the same app as the person reporting the bug? The error originally reported isn't even a Tomcat error. It's an error with a webapp deployed in Tomcat. I am not even sure that's specific to Tomcat on Gentoo, or a problem with Tomcat in general. I fail to see how a minor revision bump could cause issues like that. I believe the only change was moving from ecj-3.2 to 3.3. Otherwise the ebuild is the same, and just using newer sources. I would suggest testing against a binary from upstream. Really not sure what I could do to the ebuild to address the reported problem. >When I deployed the same wars on Tomcat 5.5.23, no such errors were seen > and the application is working fine. Is there any workaround for this problem, > so that i could use Tomcat 5.5.26 for my application? The bug reporter was going from 5.5.25-r1 -> 5.5.26. Your talking about 5.5.23? Which the last 5.5.23-r6 was removed like 5 months ago from tree? About to close this bug as invalid or cantfix. Seems more like a problem with a webapp, than Tomcat. Much less a problem with Tomcat on Gentoo.
No response to my last comments in a week. Nothing I can do really to address this without feedback from reporter. Going to close as invalid. Since I don't believe this has to do with the package itself, but a application being deployed in Tomcat on Gentoo. Please comment or reopen if you have further information.
Hi everyone. I've been out my office for a couple of weeks and haven't been able to check my mail. Taking your advice I performed these operations: unistall tomcat-5.5.25-r1 install tomcat-5.5.26 rm -rf /var/run/tomcat-5.5/* rm -rf /var/lib/tomcat-5.5/work/* rm -rf /var/lib/tomcat-5.5/temp/* redeploy app After this the same error appeared. I agree it's quite weird that a revision should affect the way XML files are accessed by the app, no doubt there's something really fishy here :-P.
Please attach the full error, entire log, do not remove any sections. If you need to hide anything for privacy purposes. Please just change that data, but don't remove it.
No problem about data, complete error message: An error has been detected. Click here for more details. Error parsing pattern finder file skins/CustomSilvano/jsp/patternFinderConfiguration.xml: java.lang.IllegalArgumentException: InputStream cannot be null at javax.xml.parsers.SAXParser.parse(SAXParser.java:172) at com.transtools.tt.export.xml.HandledSaxParser.parse(SourceFile:128) at com.transtools.caravel.gui.patterns.parser.PatternFinderLoader.load(SourceFile:134) at com.transtools.caravel.taglib.handlers.skins.PatternFinderConfigurationTagHandler.doStartTag(SourceFile:67) at org.apache.jsp.skins.CustomSilvano.jsp.caravel_005fcu_jsp._jspx_meth_carSkin_005fpatternFindersConfiguration_005f0(caravel_005fcu_jsp.java:392) at org.apache.jsp.skins.CustomSilvano.jsp.caravel_005fcu_jsp._jspx_meth_carSkin_005fskin_005f0(caravel_005fcu_jsp.java:334) at org.apache.jsp.skins.CustomSilvano.jsp.caravel_005fcu_jsp._jspx_meth_carExec_005fcustomProcess_005f0(caravel_005fcu_jsp.java:228) at org.apache.jsp.skins.CustomSilvano.jsp.caravel_005fcu_jsp._jspService(caravel_005fcu_jsp.java:97) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Error log in catalina.out: Exception in thread "Caravel Program" java.lang.NullPointerException at com.transtools.caravel.core.job.r.a(SourceFile:57) at com.transtools.caravel.core.job.c.getProgramInfo(SourceFile:1807) at com.transtools.caravel.core.job.c.findProgram(SourceFile:926) at com.transtools.caravel.core.startup.h.run(SourceFile:185) at java.lang.Thread.run(Thread.java:595) Exception in thread "Caravel Program" java.lang.NullPointerException at com.transtools.caravel.core.job.r.a(SourceFile:57) at com.transtools.caravel.core.job.c.getProgramInfo(SourceFile:1807) at com.transtools.caravel.core.job.c.findProgram(SourceFile:926) at com.transtools.caravel.core.startup.h.run(SourceFile:185) at java.lang.Thread.run(Thread.java:595)
Hi, this is just a reminder, has there been any progress on this? tomcat-5.5.25-r1 isnt't in portage any longer, so that means the only available version is unusable for me :-S.
I am not sure what I can do to resolve this. I don't have said application that seems to have problems being deployed in Tomcat 5.5.26. Best thing I could suggest is moving to 6.0.x. As I only really support 5.5.26 in maintenance mode. Tomcat 5.x like 3+ years old now. 2+ for 5.5.x. I am pretty sure this is a problem in the application not in Tomcat. But till proven one way or the other I am leaving this bug open. I would recommend doing further testing and debugging to identify the source of the problem. If it really is Tomcat or not. Only two users reporting problems. If there was general deployment issues, many more should be reporting issues. I am thinking maybe some bug was fixed in Tomcat, and these applications aren't reacting well to that change. Or the opposite, a bug was introduce in later versions of Tomcat. I would suggest trying out a stand alone Tomcat binary from upstream. Download and toss in opt the release version of 5.5.26 from tomcat.apache.org. See if the same problems exist there. If not, then need to start looking at differences in jars, etc. If same problem, then the problem is either in the applications or with upstream.
Sorry guess I closed bug as invalid. I am not 100% either way but leaning toward invalid. Till more users comment, and/or it's proven to be a problem in Tomcat 5.5.26 on Gentoo, but not with Tomcat 5.5.26 binary from upstream.
Hi, I downloaded binary Tomcat-5.5.26 and tried it, exactly the same error :-S. I can't assure it isn't an application problem, but what I can say is that it does indeed work with Tomcat-5.5.25... same wars, same conf, but no luck. I copied files from one Tomcat installation to the other one, no luck. Then tried building wars again, no luck again. Maybe the error is some combination of both my application and Tomcat? Maybe there's something changed, not necessarily a bug, but something that changed Tomcat's behaviour in some way my app wasn't expecting. What's next? Contact upstream for support?
(In reply to comment #11) > Hi, I downloaded binary Tomcat-5.5.26 and tried it, exactly the same error Figured > What's next? Contact upstream for support? Yes but I would start with your application upstream and then go to Tomcat upstream from there. It's likely a problem in your app, not Tomcat. So I would start there. Not likely to get much feedback from Tomcat devs over a problem with a third party application. And again I suggest moving past 5.5.x ASAP.
Thanks for you help William. I guess I'd obtain more help from my upstream, but the thing is the app wasn't changed, only Tomcat, so I must think the problem comes from there. I'll try with Tomcat devs, wish me luck :-). I'll propose moving forward to Tomcat 6.x, although I think I'll have to fight for that (it isn't just moving us, but also our clients).
This is not a bug with the Tomcat package on Gentoo. This problem is occurring across multiple platforms with Tomcat 5.5.26. The problem originates with a single code change in org\apache\catalina\core\ApplicationContext.java. That file is built into ApplicationContext.class inside of catalina.jar. The code change that is causing this problem is as follows: if (path == null) Was changed in 5.5.26 to: if (path == null || !path.startsWith("/")) You can extract catalina.jar using unzip and replace ApplicationContext.class with the 5.5.25 version and zip it back up to verify. I hope this helps you find the problem inside your application.
Thanks for passing that info along. Not sure if I will look to do anything to correct package. I might if enough are effected by this.
(In reply to comment #14) > > The code change that is causing this problem is as follows: > if (path == null) > Was changed in 5.5.26 to: > if (path == null || !path.startsWith("/")) > That was it! Really good point there. I created a patch to undo that particular change and a new local ebuild to apply it. I will call my app provider to be able to work with standard Tomcat, but still this is a great workaround. If anyone'd like to have the local ebuild and/or the patch just tell me. Thanks.
