Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat
Hi Michael, you should be fine using a contemporary version of Java like JDK17 or JDK21. Ferrick, Michael wrote (at 2024-09-11 13:13 +): > Hello, > > The powers above have notified me that the Java version 9.0.1.0 (x64) that I > am using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers > (OS 2019) and MUST be remediated. That means use another Java version! > > I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) > from the Control Panel (It notified me that it would stop Tomcat) and I > installed jdk-8u421-windows-x64.exe in the default location of C:Program > Files\Java, which was the same location as the original 9.0.1.0 version. > > Apache Software is located on E:\Program Files\Apache Software > Foundation\Tomcat 9.0. > > I opened Services and attempted to Start Apache Tomcat and I got an error > message. The only thing the message meant to me is that Tomcat failed to > start. I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if > the content is important to resolve let me know. > > I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and > Java 8.421 (64-bit)). > > I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to > confirm both Java and the toolkit was also installed. > > I re-opened Services and was able to restart Apache Tomcat. > > I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as > above uninstalled Java 9.0.1 and installed java 8.422 and it failed to start > Apache Tomcat, so I once again had to revert to the "vulnerable" Java 9.0.1. > > Can anyone tell me what non-vulnerable version of Java will work with Tomcat > 9.0.84 or what I am missing to make the 8.xx versions I have work? I can't > simply upgrade Apache Tomcat as there are just too many developers entrenched > in this version. > > Thank you, > Mike > > _ > The information contained in this email and any attachments have been > classified as limited access and/or privileged State Street > information/communication and is intended solely for the use of the named > addressee(s). If you are not an intended recipient or a person responsible > for delivery to an intended recipient, please notify the author and destroy > this email. Any unauthorized copying, disclosure, retention or distribution > of the material in this email is strictly forbidden. > Go green. Consider the environment before printing this email. > > > > Information Classification: General -- Mit freundlichem Gruß / With kind regards Holger Klawitter -- listen klawitter de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: The Import cannot be resolved
Hi, I once had a similar experience when the tomcat process ran out of file handles. At some point tomcat wasn't able to open a file and cached the absence of that file. Later on tomcat still remembered the absence and threw errors just like yours. Stephen Tenberg wrote (at 2024-06-22 09:03 -0400): > Hello, I am trying to convert a large mature application to Tomcat 9. No > WAR file is used, the files are statistically placed in directories. > > So far it's going pretty well and large parts of the application are > working. A few minor incompatibilities have been solved. > > One sticking point has been this error: > > An error occurred at line: [15] in the generated java file: > [/opt/tomcat-9.0.90/work/Catalina/local.procheckauto.com/ROOT/org/apache/jsp/admin/menu_jsp.java] > The import com.xxx.rr.user cannot be resolved > > This is confirmed present in the class tree, the permissions are > correct, and we compiled from the command line to verify. > > Looking through the classes tree there is nothing different about this > simple class compared to all the others which ARE resolved. > > Has anyone faced something like this and figured out a way to debug it? > > The log stack trace has the same information and no clue as to WHY it > couldn't be resolved. > > Compiling the class in Eclipse or command line is fine, and the JSP > file looks correct with just a standard import and errors or warning > in eclipse. > > The class directory is symlinked, but allowlinking has been specified > and many classes before this one in the same tree are successfully > accessed, so I have no reason to think the symlink is an issue. -- Mit freundlichem Gruß / With kind regards Holger Klawitter -- listen klawitter de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: allow symlink tomcat 9
A plain should suffice. Giacomo Morri wrote (at 2024-04-24 12:03 +0200): > Hi Holger, thanks for your reply. > > consider that the symlink is /MTF/Content -> /realt/path/, how can i set the > Resource element for that path? > > Regards, > > Giacomo > > > > On 24/04/24 11:55, Holger Klawitter wrote: > > Hi, > > > > allowLinking goes into a Resource Element inside Context, > > not into Context itself. This changed in Tomcat 8.0 IIRC. > > > > Giacomo Morri wrote (at 2024-04-24 11:42 +0200): > > > Hi, i have a servlet for uploading files inside a path that contains a > > > symbolic link, the upload works fine with tomcat 7 but after upgrading it > > > to > > > tomcat 9 the servlet give me a java.lang.NullPointerException at > > > java.io.File.. > > > > > > I tried setting the allowLinking param to true for the context in this > > > way: > > > > > > > > /> > > > > > > But it doesn't work. > > > > > > Can you please help me? > > > > > > Regards, > > > > > > Giacomo > > > > > > > > > ----- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > -- > > Mit freundlichem Gruß / With kind regards > >Holger Klawitter > > -- > > listen klawitter de > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- > > *Cone * > *Essentially digital* > Via Sandro Totti 7A - 60131 Ancona > Tel 071 42 974 > Cell 3273458156 > eMail giacomo.mo...@cone.it <mailto:giacomo.mo...@cone.it> > Web www.cone.it <http://www.cone.it> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Mit freundlichem Gruß / With kind regards Holger Klawitter -- listen klawitter de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: allow symlink tomcat 9
Hi, allowLinking goes into a Resource Element inside Context, not into Context itself. This changed in Tomcat 8.0 IIRC. Giacomo Morri wrote (at 2024-04-24 11:42 +0200): > Hi, i have a servlet for uploading files inside a path that contains a > symbolic link, the upload works fine with tomcat 7 but after upgrading it to > tomcat 9 the servlet give me a java.lang.NullPointerException at > java.io.File.. > > I tried setting the allowLinking param to true for the context in this way: > > > > But it doesn't work. > > Can you please help me? > > Regards, > > Giacomo > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Mit freundlichem Gruß / With kind regards Holger Klawitter -- listen klawitter de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
unsupported source vm 17?
Hi there, I am using tomcat 9.0.73 along with jdk 17.0.7+8. I have set up tomcat to support jdk 17 on all jsp pages. jsp org.apache.jasper.servlet.JspServlet compilerSourceVM 17 compilerTargetVM 17 fork false xpoweredBy false 3 In the logfiles I notice the following Warning: 17-May-2023 11:53:37.171 WARNUNG [http-nio-80-exec-10] org.apache.jasper.compiler.JDTCompiler.generateClass Unsupported source VM [17] requested, using [16] Does this mean that tomcat/jasper is not fully supporting jdk17 at this point? Mit freundlichem Gruß / With kind regards Holger Klawitter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tag files compiled in wrong encoding?
Hi Mark, this fix was light speed! Thanks a lot! Regards, Holger - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tag files compiled in wrong encoding?
Hi there, I am investigating an encoding problem in the compiler for tag files: the following tag file (WEB-INF/tag/umlaut.tag): <%@tag trimDirectiveWhitespaces="true" pageEncoding="UTF-8" %> <%= "ü does not work" %> // bytes c3 bc (the file is in utf-8) compiles into umlaut_tag.java in which the umlaut is doubly utf-8 encoded like this: out.print( "ü does not work" ); // bytes c3 83 c2 bc String literals in jsp files work just fine, so I assume that the basic encoding setup is correct. Is this a jasper problem? Where can I report this (which component in bz)? Or am I missing some peculiarities regarding tags files? Regards, Holger - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
howto deal with war files if context.xml needs configration?
Hi there, I have written a webapplication with I would like to distribute as a war file amongst a few hosts. There is a resource in the context file which needs some individual configuration per server. * I used to unpack directly into the webapps directory and doing the configuration in the true context.xml file. * As far as I understand, this approach is no longer recommended and causes more an more problems with every new tomcat version. BUT * If I upload the warfile via manager or ant, I have first to extract the context file, edit it, and pack it back. * I have to create a war file with the same name as the basename becomes the context name. * This way I am confronted with a bunch of war files undistinguishable by name and only differring in contents of context.xml file. * I can hardly think of a better recipe to create confusion. Is there a better way to handle this deployment scenario? Mit freundlichem Gruß / With kind regards Holger Klawitter -- listen < @/at > klawitter < ./dot > de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
