Aw: Re: Logrotation throu CATALINA_OUT_CMD in Tomcat9
> You need to do what the instructions state: create a FIFO and specify its > name in the CATALINA_OUT variable. For example, do Ah, yes, mkfifo catalina.out fixed it for me. I had no idea what a fifo is, now I knew. Kind regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Logrotation throu CATALINA_OUT_CMD in Tomcat9
Hi, my catalina.out is getting bigger and bigger. In order to have smaller catalina.out I noticed this environment-variable: CATALINA_OUT_CMD Inside the catalina.sh is documented: # CATALINA_OUT_CMD (Optional) Command which will be executed and receive # as its stdin the stdout and stderr from the Tomcat java # process. If CATALINA_OUT_CMD is set, the value of # CATALINA_OUT will be used as a named pipe. # No default. # Example (all one line) # CATALINA_OUT_CMD="/usr/bin/rotatelogs -f $CATALINA_BASE/logs/catalina.out.%Y-%m-%d.log 86400" I try to use that example and export this variable before start of tomcat: export CATALINA_OUT_CMD="/usr/bin/rotatelogs -f /home/tomcat/apache-tomcat-9.0.75/logs/catalina.out.%Y-%m-%d.log 86400" Unfortunately the tomcat does not work anymore, instead this message appear: /home/tomcat/apache-tomcat-9.0.75/logs/catalina.out exists and is not a named pipe. Start aborted. Any Ideas? Kind regards Peter Rader - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: Servlet-Mapping having %-sign
> Peter, > > On 12/29/23 07:56, Peter Rader wrote: > > having a URL like this: > > > > https://localhost:8443/index.html works perfect. This is my mapping: > > > > > > Nano-Nano-Servlet > > /index.html > > > > > > Nano-Nano-Servlet > > *.ts > > > > > > Unfortunately this URI does not load (because of the %-sign): > > > > https://localhost:8443/@rm%2fmodel.ts > > > > It gives a http-status:400 having the message "Invalid URI: [noSlash]" > > What's the use-case for having a client use a %-encoded / in your URL? > That kind of thing is usually evidence of a hacking attempt, which is > why Tomcat returns a 400 response. I generate TypeScript dynamically. In order to use it in Node: I register a servlet to create npm-packages at run-time. On Node-side I use this command: 1. Register servlet as npm source: 'npm config set @myapp:registry=https://nonofyourbusiness.mydomain.com:8443/' 2. Start the download: 'npm install @myapp/model --loglevel verbose' (hint: @myapp is the tomcat) This is the output of the second command: npm info it worked if it ends with ok npm verb cli [ npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/node', npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/npm', npm verb cli 'install', npm verb cli '@myapp/model@1.0.0', npm verb cli '--loglevel', npm verb cli 'verbose' npm verb cli ] npm info using npm@6.14.15 npm info using node@v14.18.1 npm verb config Skipping project config: /home/grim/.npmrc. (matches userconfig) npm verb npm-session 778f7308eede99d8 npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/@myapp%2fmodel 28ms npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 14ms npm timing stage:loadCurrentTree Completed in 71ms npm timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms npm timing stage:loadIdealTree:loadShrinkwrap Completed in 3ms npm timing stage:loadIdealTree:loadAllDepsIntoIdealTree Completed in 1ms npm timing stage:loadIdealTree Completed in 5ms npm timing stage:generateActionsToTake Completed in 1ms npm verb correctMkdir /home/grim/.npm/_locks correctMkdir not in flight; initializing npm verb lock using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 7ms npm timing action:extract Completed in 10ms npm timing action:finalize Completed in 1ms npm timing action:refresh-package-json Completed in 1ms npm info lifecycle model@1.0.0~preinstall: model@1.0.0 npm timing action:preinstall Completed in 1ms npm info linkStuff model@1.0.0 npm timing action:build Completed in 0ms npm info lifecycle model@1.0.0~install: model@1.0.0 npm timing action:install Completed in 1ms npm info lifecycle model@1.0.0~postinstall: model@1.0.0 npm timing action:postinstall Completed in 0ms npm verb unlock done using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging npm timing stage:executeActions Completed in 18ms npm timing stage:rollbackFailedOptional Completed in 1ms npm timing stage:runTopLevelLifecycles Completed in 97ms npm WARN saveError ENOENT: no such file or directory, open '/home/grim/package.json' npm info lifecycle undefined~preshrinkwrap: undefined npm info lifecycle undefined~shrinkwrap: undefined npm info lifecycle undefined~postshrinkwrap: undefined npm WARN enoent ENOENT: no such file or directory, open '/home/grim/package.json' npm verb enoent This is related to npm not being able to find a file. npm verb enoent npm WARN grim No description npm WARN grim No repository field. npm WARN grim No README data npm WARN grim No license field. npm http fetch POST 400 https://registry.npmjs.org/-/npm/v1/security/audits/quick 266ms + model@1.0.0 (as @myapp/model) added 1 package in 0.347s npm verb exit [ 0, true ] npm timing npm Completed in 463ms npm info ok --- end of console output As you might have noticed, this time the URL responded successfully. This is because I modified catalina.properties (org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true). > > https://stackoverflow.com/questions/19576777/why-does-apache-tomcat-handle-encoded-slashes-2f-as-path-separators I agree that this might become a security risk. Since the mentioned mod_jk-bug is not affected in this particular case, I could exoticize the tomcat-config to undo tomcats built-in-workaround throu the catalina.properties. It does not feel like an elegant solution, but it works for now. If however npm might be the future for some developers, a redesign of tomcat may a more desirable solution. It might be hard to tell the npm people to change their "way of downloading npm-packages" because "mod_jk have a bug" might not be concidered as a convincing argument. :-D > > -chris &g
Servlet-Mapping having %-sign
Hey, having a URL like this: https://localhost:8443/index.html works perfect. This is my mapping: Nano-Nano-Servlet /index.html Nano-Nano-Servlet *.ts Unfortunately this URI does not load (because of the %-sign): https://localhost:8443/@rm%2fmodel.ts It gives a http-status:400 having the message "Invalid URI: [noSlash]" Any ideas? Kind regards / Happy new year Peter Rader - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Forward: Jakarta Servlet support decision (insight to a discussion in freemarker-devs)
FYI I share this mail from the freemarker-mailsystem for your entertainment, enjoy. > Gesendet: Dienstag, 07. November 2023 um 23:50 Uhr > Von: "Daniel Dekany" > An: "FreeMarker developer list" > Subject: Jakarta Servlet support decision > > The package of Servlet related classes has changed because of Jakarta, > which breaks our Servlet support (freemarker.ext.servlet), which is packged > into freemarker.jar. > > We have to choose which end result we want (ignore the "how" for now) as > the solution, from these two (as far as I can tell): > > 1. We can copy the `freemarker.ext.servlet` package into > `freemarker.ext.jakartaservlet` (or such), and we will only have the normal > artifact in Maven Central, which contains that, and also the older > freemarker.ext.servlet. Explanation: As you probably know, 2.x has a single > monolithic freemarker.jar artifact, which already contains support classes > of various optional dependencies. We already support multiple incompatible > Serlvet/JSP versions, and has separate version-specific classes for some. > But, classes like freemarker.ext.servlet.FreemarkerServlet managed to stay > common amongst Servlet API versions. For the Jakarta change not even that > can remain common of course. > > 2. We can have an additional artifact variant (let's say via Maven > classifier "jakarta"), that still uses the `freemarker.ext.servlet` > package, but there that links to the Jakarta Servlet classes. This artifact > will drop support for pre-Jakarta Servlet/JSP versions. > > Possibility 1 pro: We don't have to publish one more artifact. Also, then > users don't have to fiddle with dependency management to choose the > artifact with the "jakarta" classifier. > > Possibility 1 con: Any existing dependent Java code that used > `freemarker.ext.servlet` so far, and wants to migrate to a Jakarta Servlet > container, has to be modified to link to `freemarker.ext.jakartaservlet` > instead. That sounds quite bad, however, the same dependent Java code > likely has to be modified anyway, to link to Jakarta Servlet classes. > Except, there are tools, like > https://github.com/apache/tomcat-jakartaee-migration, that transforms jar-s > to depend on Jakarta Servlet API, but same tools of course won't replace > links to freemarker.ext.servlet with freemarker.ext.jakartaservlet, so some > pain is expected. Also, `web.xml`-s that refer to > `freemarker.ext.servlet.FreemarkerSerlvet` also have to be modified, if > someone uses a Jakarta container. > > Opinions? > > Note 1: We had two attempts so far on this issue, but certainly the actual > solution will be a 3rd one. Anyway, the "how" is now not the point now, but> > here they are: > > - > https://github.com/apache/freemarker/pull/94[https://github.com/apache/freemarker/pull/94] > - > https://github.com/apache/freemarker/pull/95[https://github.com/apache/freemarker/pull/95] > > Note 2: At some later(!) point, maybe in a FreeMarker 2.4.0, we can get rid > of non-Jakarta servlet support. At the same point, we will also get rid of > the GAE/non-GAE variety. So we could end up with just a single variant of > the freemarker 2.x artifact, over time. > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fw: AW: Maven tomcat7:redeploy upload reset/retry
> > Hi Folks, > > > > I am running a tomcat 8.5.50. > > > > I try to upload a webapp using maven-tomcat7-plugin. > > > > It worked very good for a couple of years. I did nothing new to the > > configuration. > > > > Then I see broken pipes during build: > > > > > > [INFO] Deploying war to http://www.foobar.de/manager/de.foobar.xxx- > > 1.0.0-SNAPSHOT[https://deref- > > gmx.net/mail/client/1mSXrDjDU9k/dereferrer/?redirectUrl=http%3A%2F%2Fw > > ww.foobar.de%2Fmanager%2Fde.foobar.xxx-1.0.0-SNAPSHOT] > > Uploading: > > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-] > > 1.0.0-SNAPSHOT=true[https://deref- > > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw > > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0- > > SNAPSHOT%26update%3Dtrue] > > 3534/82321 KB > > Uploading: > > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-] > > 1.0.0-SNAPSHOT=true[https://deref- > > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw > > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0- > > SNAPSHOT%26update%3Dtrue] > > 3504/82321 KB > > Uploading: > > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-] > > 1.0.0-SNAPSHOT=true[https://deref- > > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw > > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0- > > SNAPSHOT%26update%3Dtrue] > > 3684/82321 KB > > Uploading: > > http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-[http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-] > > 1.0.0-SNAPSHOT=true[https://deref- > > gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fw > > ww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0- > > SNAPSHOT%26update%3Dtrue] > > 3474/82321 KB > > > > The redeployment failed. I checked the free space and there are about 4 > > gigabyte free on the device. > > > > I already checked the upload-size in manager/WEB-INF/web.xml I already > > checked the ip-disclosure in manager/META-INF/context.xml I already checked > > the connectionTimeout in the http and https connector. > > I already checked the username and password. > > I already checked the roles. > > > > It have worked successfully until a few days. I changed nothing. > > > > Any ideas? (I do not like to update to a new tomcat-version) > > > > Kind regards > > Peter Rader > > -- > > Could you check the tomcat logs? > Under normal circumstances there should be some information to track down the > issue. > Check all the log files according to the timestamp and post snippets, if you > find something related. > > Greetings, > Thomas > > I checked the Tomcat-logs using enabled logging I saw: 02-May-2023 11:56:44.656 FINE [http-nio-80-exec-4] org.apache.catalina.realm.RealmBase.hasResourcePermission Role found: manager-script 02-May-2023 11:56:44.657 FINE [http-nio-80-exec-4] org.apache.catalina.authenticator.AuthenticatorBase.invoke Successfully passed all security constraints 02-May-2023 11:56:44.657 FINER [http-nio-80-exec-4] org.apache.catalina.core.StandardWrapper.allocate Returning non-STM instance 02-May-2023 11:56:44.657 INFO [http-nio-80-exec-4] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application 'de.foobar.xxx-1.0.0-SNAPSHOT' 02-May-2023 11:56:44.814 FINE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.startup.HostConfig.checkResources Checking context[] redeploy resource /usr/local/share/apache-tomcat-8.5.50/webapps/ROOT.war 02-May-2023 11:56:44.814 FINE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.startup.HostConfig.checkResources Checking context[] redeploy resource /usr/local/share/apache-tomcat-8.5.50/webapps/ROOT (last two messages are repeated 50 times the different applications) As you can see, the authentication completed successfully. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Maven tomcat7:redeploy upload reset/retry
Hi Folks, I am running a tomcat 8.5.50. I try to upload a webapp using maven-tomcat7-plugin. It worked very good for a couple of years. I did nothing new to the configuration. Then I see broken pipes during build: [INFO] Deploying war to http://www.foobar.de/manager/de.foobar.xxx-1.0.0-SNAPSHOT[https://deref-gmx.net/mail/client/1mSXrDjDU9k/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Fde.foobar.xxx-1.0.0-SNAPSHOT] Uploading: http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue] 3534/82321 KB Uploading: http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue] 3504/82321 KB Uploading: http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue] 3684/82321 KB Uploading: http://www.foobar.de/manager/text/deploy?path=de.foobar.xxx-1.0.0-SNAPSHOT=true[https://deref-gmx.net/mail/client/LgHF_x8BUC4/dereferrer/?redirectUrl=http%3A%2F%2Fwww.foobar.de%2Fmanager%2Ftext%2Fdeploy%3Fpath%3Dde.foobar.xxx-1.0.0-SNAPSHOT%26update%3Dtrue] 3474/82321 KB The redeployment failed. I checked the free space and there are about 4 gigabyte free on the device. I already checked the upload-size in manager/WEB-INF/web.xml I already checked the ip-disclosure in manager/META-INF/context.xml I already checked the connectionTimeout in the http and https connector. I already checked the username and password. I already checked the roles. It have worked successfully until a few days. I changed nothing. Any ideas? (I do not like to update to a new tomcat-version) Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 6 29 33 29 6 Fax: 0049 (0)30 / 6 29 33 29 6 Handy: 0049 (0)176 / 87 521 576 Handy: 0049 (0)176 / 47 876 303 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Tomcat/Java app timezone radomly changes during operation.
Hi David, is it a moving server? We had similar issues on a airborn server crossing nation-borders rapidly. 10 minutes is unusual. The lowest timezone-change is 15 minutes afaik. Kind regards > > Hi all, > > I've experienced an issue since the morning of the 21st that I'm > hoping to get some direction on for where to look. > > An app uses the date/time to set a timeout for a password reset. > This had been working fine for years and suddenly it failed. A restart of > tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1 hr > and now is averaging a 10 minute or so working duration between tomcat > restarts. > > Changing the logging in the app showed that the issue is due to it > sending UTC to the DB while it is broken. Restarting Tomcat results in CDT > being sent for a while until randomly it switches again. > > RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29 > ntp is on, chrony is syncing, Java states correct time when queried > however unsure if it's JDK or JRE when targeted. OS time is good. > > When I redeploy the app, log timestamps for the app are in UTC as well > until restarting tomcat. During the issue the log timestamp remains in > CDT as expected, even though values passed are UTC. > > I have explicitly defined the timezone in setenv.sh with no change in > behavior. > > Any thoughts as what to investigate are greatly appreciated. > > Thanks, > David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: PostConstruct annotation in a filter since version 9.0.60
PostConstruct is for dependency-injection. A vanilla tomcat does no dependency injection. Can you confirm you have a vanilla tomcat? Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 6 29 33 29 6 Fax: 0049 (0)30 / 6 29 33 29 6 Handy: 0049 (0)176 / 87 521 576 Handy: 0049 (0)176 / 47 876 303 Gesendet: Freitag, 01. April 2022 um 23:02 Uhr Von: "Cherio" An: users@tomcat.apache.org Betreff: PostConstruct annotation in a filter since version 9.0.60 I observed an announced change in behavior in version 9.0.60 (and later). My application has a Spring class loaded as a javax.servlet.Filter. It has a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior changed. Now Tomcat attempts to take action on that method. The attempt fails with "java.lang.IllegalArgumentException: Invalid javax.annotation.PostConstruct annotation" exception and that results in the whole application failing to start. I use PostConstruct in other Spring modules but it looks like Tomcat cares only about classes it deals with directly. I do not see this change documented anywhere so I assume this may be a regression or an undocumented bug fix or feature. Does anyone have more information about this? Thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Tomcat - Deployment
Dear Admin Priyanka, unfortunately the source-code your developers wrote might be invalid. The error might occour in a Thread calling the productExclusionRegistryDao-bean (Maybe the ProductExclusionRegistryDao.java source-file) in the method used to initialize the application. In order to solve the bug your developers are in charge IMO. Please provide the stacktrace to your developers in order to solve the problem. Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 6 29 33 29 6 Fax: 0049 (0)30 / 6 29 33 29 6 Handy: 0049 (0)176 / 87 521 576 Handy: 0049 (0)176 / 47 876 303 Gesendet: Sonntag, 07. November 2021 um 16:04 Uhr Von: "Kumawat, Priyanka" An: "Tomcat Users List" Betreff: Tomcat - Deployment Hi Team , I have did a Tomcat application deployment on Production region and copied the WAR file to the webapps location of tomcat , we normally do this change monthly , tested on Stage env after successful it will go to the production env. But This time we have encountered an issue- after the deployment completes - The logs was giving the below error - The client reports there is no issue with the WAR file as it was deployed successfully for lower env - stage , they have asked to deploy one more time on prod , this time it worked successful. I need your help to determine wat went wrong during the first implementation while the same steps were performed during both the times. 2021-11-07 05:05:58,277 ERROR org.springframework.web.context.ContextLoader:350 - Context initialization failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'fleetTireFinderRestController': Unsatisfied dependency expressed through field 'fleetOrderService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'fleetOrderServiceImpl': Unsatisfied dependency expressed through field 'catalogHelper'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'catalogHelperDao': Unsatisfied dependency expressed through field 'productValidationDao'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'productValidationDao': Unsatisfied dependency expressed through field 'tireFinder'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'tireFinderDao': Unsatisfied dependency expressed through field 'prodExclusions'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'productExclusionRegistryDao': Invocation of init method failed; nested exception is org.springframework.jdbc.UncategorizedSQLException: StatementCallback; uncategorized SQLException for SQL [select * from excl_dc_ph]; SQL state [null]; error code [-4470]; [jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null; nested exception is com.ibm.db2.jcc.am.SqlException: [jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'fleetOrderServiceImpl': Unsatisfied dependency expressed through field 'catalogHelper'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'catalogHelperDao': Unsatisfied dependency expressed through field 'productValidationDao'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'productValidationDao': Unsatisfied dependency expressed through field 'tireFinder'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'tireFinderDao': Unsatisfied dependency expressed through field 'prodExclusions'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'productExclusionRegistryDao': Invocation of init method failed; nested exception is org.springframework.jdbc.UncategorizedSQLException: StatementCallback; uncategorized SQLException for SQL [select * from excl_dc_ph]; SQL state [null]; error code [-4470]; [jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null; nested exception is com.ibm.db2.jcc.am.SqlException: [jcc][t4][10120][10898][4.9.78] Invalid operation: result set is closed. ERRORCODE=-4470, SQLSTATE=null Thanks & Regards, Priyanka Kumawat | Middleware Admin T +91.7879364483 EMail - priyanka.kuma...@dxc.com<mailto:priyanka.kuma...@dxc.com> DL - ams-leveraged-webadmin-offsh...@dxc.com<mailto:ams-leveraged-webadmin-offsh...@d
Aw: Re: tomcat hangs
Chris, > Gesendet: Donnerstag, 09. September 2021 um 22:15 Uhr > Von: "Christopher Schultz" > An: users@tomcat.apache.org > Betreff: Re: Aw: tomcat hangs > Peter, > > On 9/9/21 08:21, Peter Rader wrote: > > I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM > > (in virtualbox btw). The jdk for some reason request a random number. > > The JDK asks the LinuxOS for a new random number (maybe in the hope > > to use a hardware-based TRNG). Since this linux in virtualbox is > > not-so low-level the random number is generated due to RAM > > squarenumbers, because no memory is changed - no new random number > > has been generated and we get a OS-based softlock. > > WHAT? > > -chris YES, id reported this many years ago https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4952383 There is a workaround (from comments): set java.security.egd=file:/dev/urandom Regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: tomcat hangs
I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM (in virtualbox btw). The jdk for some reason request a random number. The JDK asks the LinuxOS for a new random number (maybe in the hope to use a hardware-based TRNG). Since this linux in virtualbox is not-so low-level the random number is generated due to RAM squarenumbers, because no memory is changed - no new random number has been generated and we get a OS-based softlock. Regards > HiI use apache tomcat 8.0.32 and oracle-jdk-8u66 and redhat 6.After working > with the system for a few hours > and the load on the system increases, suddenly the tomcat hangs and no logs > are printed and it is not possible > to connect via jvisualvm and I can not get any dump and I have to reload > Tomcat.I have increased maxthreads > and use the HttpProtocol protocol.Please suggest a way to fix the my tomact. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
IDNs emoji replaced by punycode - how to remain with emoji?
Hi, I try to support a emoji in a IDN. This is the head of my engine-config: Both, HTTP and HTTPS connector have the UTF8 encoding: Unfortunately the browser-url redirect to the punycode xn--x7h.example.com in Chrome, Edge and Firefox (did not test more). How to remain with emoji IDN in the browser URL? Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 6 29 33 29 6 Fax: 0049 (0)30 / 6 29 33 29 6 Handy: 0049 (0)176 / 8 7521576 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request for Help
Hello Mohan,
please tell if you are using
1. the JSP technology inside the application
2. what JDK version on server-side
Kind regards
Peter Rader
--
Fachinformatiker AE / IT Software Developer
Peter Rader
Wilsnacker Strasse 17
10559 Berlin - GERMANY
Tel: 0049 (0)30 / 6 29 33 29 6
Fax: 0049 (0)30 / 6 29 33 29 6
Handy: 0049 (0)176 / 8 7521576
Gesendet: Mittwoch, 29. Juli 2020 um 06:33 Uhr
Von: "Mohan T"
An: "Tomcat Users List"
Betreff: Request for Help
Dear All,
In one of the environments we are using apache-tomcat-8.5.35.
On server start we are getting this exception
org.apache.catalina.core 28-Jul-2020 13:46:13.407 SEVERE
[localhost-startStop-1] org.apache.catalina.core.StandardContext.loadOnStartup
Servlet [RVW_Banner] in web application [/security] threw load() exception
java.lang.NoSuchMethodError:org.eclipse.jdt.internal.compiler.Compiler.(Lorg/eclipse/jdt/internal/compiler/env/INameEnvironment;Lorg/eclipse/jdt/internal/compiler/IErrorHandlingPolicy;Lorg/eclipse/jdt/internal/compiler/impl/CompilerOptions;Lorg/eclipse/jdt/internal/compiler/ICompilerRequestor;Lorg/eclipse/jdt/internal/compiler/IProblemFactory;)V
at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:480)
Any inputs to overcome this could help us in this.
Thanks
Mohan
DISCLAIMER: This communication contains information which is confidential and
the copyright of Ramco Systems Ltd, its subsidiaries or a third party
("Ramco"). This email may also contain legally privileged information.
Confidentiality and legal privilege attached to this communication are not
waived or lost by reason of mistaken delivery to you.This email is intended to
be read or used by the addressee only. If you are not the intended recipient,
any use, distribution, disclosure or copying of this email is strictly
prohibited without the express written approval of Ramco. Please delete and
destroy all copies and email Ramco at le...@ramco.com immediately. Any views
expressed in this communication are those of the individual sender, except
where the sender specifically states them to be the views of Ramco. Except as
required by law, Ramco does not represent, warrant and/or guarantee that the
integrity of this communication has been maintained nor that the communication
is free of errors, virus, interception or interference. If you do not wish to
receive such communications, please forward this communication to
market...@ramco.com and express your wish not to receive such communications
henceforth.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: Re: /META-INF/resources/ and Chrome's DevTools
Ah ok, I use maven, only tomcat 7 and 6 is available. PreResources are only available in tomcat8 so I decide against tomcat in higher versions than 7. Kind regards > Gesendet: Montag, 06. April 2020 um 16:34 Uhr > Von: "Mark Thomas" > An: users@tomcat.apache.org > Betreff: Re: Aw: Re: /META-INF/resources/ and Chrome's DevTools > On 06/04/2020 09:16, Peter Rader wrote: > > Hello Konstantin Kolinko, > > > > I tried to use the PreResource but it does not work. > > > > 2020-04-06 10:13:05 WARNUNG org.apache.tomcat.util.digester.Digester > endElement No rules found matching 'Context/Resources/PreResources'. > > > > This is my context.xml > > > > > > > type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" > > url="" > > username="xxx" password="xxx" maxTotal="50" > > maxIdle="50" maxWait="10"> > > > > > className="org.apache.catalina.webresources.FileResourceSet" > > base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources" > > internalPath="index.html" /> > > That doesn't look quite right. I'd expect it to look something like: > > className="org.apache.catalina.webresources.FileResourceSet" > base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources" > /> > > To map the contents of the "...\META-INF\resources" directory into the > root of the web application. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: /META-INF/resources/ and Chrome's DevTools
Hello Konstantin Kolinko, I tried to use the PreResource but it does not work. 2020-04-06 10:13:05 WARNUNG org.apache.tomcat.util.digester.Digester endElement No rules found matching 'Context/Resources/PreResources'. This is my context.xml Any idea? > > Gesendet: Montag, 16. März 2020 um 01:01 Uhr > Von: "Konstantin Kolinko" > An: "Tomcat Users List" > Betreff: Re: /META-INF/resources/ and Chrome's DevTools > ??, 15 ???. 2020 ?. ? 13:47, Peter Rader : > > > > I have my default.js in a frontend.jar's /META-INF/resources/js/ according > > to the specs (last paragraph of point 10.10 in > > https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf > > ) it is served successfully. This works great! > > 1. If you unpack the file into a directory in your web application > (into its /js/ directory), > it will take precedence over the version packed in the framework jar. > > > 2. It is possible to map files from elsewhere on your hard drive into > your web application. > It can be done with "" element in the > META-INF/context.xml file of your web application. > > For reference: > http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html[http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html] > > > 3. If your Tomcat runs on the same computer. you can run the web > application from an expanded directory, without packing it as a war > file. > > 1) Copy your META-INF/context.xml file as > $CATALINA_BASE/conf/Catalina/localhost/yourwebappname.xml > > 2) Add docBase attribute to the element in it. > > See > http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context[http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context] > > > Best regards, > Konstantin Kolinko Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 20 9930560 Fax: 0049 (0)30 / 20 9930561 Handy: 0049 (0)176 / 8 7521576 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: /META-INF/resources/ and Chrome's DevTools
> > > > I have my default.js in a frontend.jar's /META-INF/resources/js/ according > > to the specs (last paragraph of point 10.10 in > > https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf > > ) it is served successfully. This works great! > > 1. If you unpack the file into a directory in your web application > (into its /js/ directory), > it will take precedence over the version packed in the framework jar. Ok this will work but I run the app using mvn tomcat:run Any behavioural modification to this process will order modifications to the pom.xml. Since this leads to be more project-specific code under version-control to support I like to avoid this. > > > 2. It is possible to map files from elsewhere on your hard drive into > your web application. > It can be done with "" element in the > META-INF/context.xml file of your web application. > > For reference: > http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html[http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html] > This might do the trick! Ill try that out. If that is confirmed to be working I can get rid of https://github.com./enexusde/devtools-tomcat-bypass . > > 3. If your Tomcat runs on the same computer. you can run the web > application from an expanded directory, without packing it as a war > file. > > 1) Copy your META-INF/context.xml file as > $CATALINA_BASE/conf/Catalina/localhost/yourwebappname.xml > > 2) Add docBase attribute to the element in it. > > See > http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context[http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context] > Since beside the frontend.jar I have other jars who serve static resources. This means I must have multiple docBases what is not possible AFAIK. > > Best regards, > Konstantin Kolinko Kind regards Peter Rader - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: /META-INF/resources/ and Chrome's DevTools
I wrote a little WebFilter for this task. https://github.com/enexusde/devtools-tomcat-bypass Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 20 9930560 Fax: 0049 (0)30 / 20 9930561 Handy: 0049 (0)176 / 8 7521576 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
/META-INF/resources/ and Chrome's DevTools
I have my default.js in a frontend.jar's /META-INF/resources/js/ according to the specs (last paragraph of point 10.10 in https://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf ) it is served successfully. This works great! Chrome load this default.js during surfing on localhost. Using DevTools I can map this in-browser-default.js to a local directory. This allowes chrome to synchronize the local source-version of the default.js with the in-browser loaded default.js. This way I have a source-cascade. 1. The default.js is Packed into the frontend.jar. 2. The frontend.jar is Packed into the application.war. 3. The application.war is served via Tomcat. The Problem: If I reload the website Chrome DevTools drops all changes I made to the Tomcat served version. So if I change a single byte in the default.js I have to: 1. Pack the jar 2. Pack the war 3. Redeploy the war. This process takes a length of about 5 minutes. It is reloading the application and package the jars/wars for the sake of 1 byte change. The Question: Can I map a single resource to a file dynamically without reloading the application. Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 20 9930560 Fax: 0049 (0)30 / 20 9930561 Handy: 0049 (0)176 / 8 7521576 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Installing a program designed for Tomcat 5.5 on Tomcat 9
> I am currently trying to install a program designed to operate on Win XP 32 > and earlier on to a Win 10 environment. The program extracts to the Shared > and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting > the database and installing it on SQL 2017 I added the JDBC connector and > downloaded and installed tomcat 9 only to find there is no shared folder to > extract the shared files to. Any suggestions? Hm, shared ... do you mean the endorsed folder? From old apps I remember that some jdbc-jars have to be placed in tomcat's endorsed folder. I am pretty sure that you could use the JVM/JDK's endorsed folder. They usually have their place in \lib\endorsed . Kind regards Peter Rader - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
> Does it ever work? Yes, I deployed and redeployed much larger WARs (i.e. 107MiB) many times to the same instance. > > The Tomcat manager has a default limit of 50MiB for uploads. Your WAR > file it larger than that, so it might be failing. Some weeks ago I changed this default limit to "about" 500MiB - as I always do (!!). To give you the 100% prove I send you the max-file-size-config: 524288 524288 0 > > The /second/ upload in your log file might be because the deployer > re-tries when the first attempt fails. Hm, if the plugin retries to upload I expect some logging output. Even if there is no debug-output for the retry, I could try to debug it locally. > It's so fast because Tomcat > rejects the request immediately after looking at the Content-Length, > instead of allowing 71MiB of stream over the network before rejecting > the request. This can not be true, how would you tell the existance of this line in the log?: 02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application 'XXX' If - and only if - a WAR is rejected because of its size, the Manager would never ever write "Hey dude, I am deploying your web application XXX!". Right? Anyway I found it by myself. > On 2/2/20 4:48 PM, Peter Rader wrote: > > The old version of the application had a daemon that have not yet > > finished his execution. > > Tomcat cannot detect this situation, so it's unlikely to be the direct > problem. I see. > How did you come to your conclusion? I noticed two hints that guides me to this idea: 1. I configured a user having the role manager-gui and tried to stop the web-application using the manager-web-interface (/manager/html/list). Stop command was not successfull, a error message occoured above the application-table. 2. I could send the SHUTDOWN signal successfully, all looks like a clear shutdown (the connectors successfully shutting down, CDI shutdown, EntityManager closed, port 80+443 becomes free, sessions passivated) but the java-process remains running for no reason and must be killed manually. 3. Last but not least, the original problem: The webapp fails to redeploy using mvn tomcat:redeploy. > > - -chris -- Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: SOLVED - Re: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
> Please post updates to the original thread. This is the original thread. > As suggested in the original thread, it was a permissions issue ... > permission denied because the port was already in use : ) Why do you think it is a permission issue? I already disproved that! How can you break it down to port-already-in-use? I found the answer and it was faar away from any permission issue! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SOLVED - Re: Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
The old version of the application had a daemon that have not yet finished his execution. Unfortuantely there is no further logging why the old version not stoped yet. I expected to have the "mvn redeploy" waiting forever for this deamon-locked problem. What I can not do is write a bug report because the bug was inside my app. But what I might do is to add a feature-request. Not sure where, and not sure for what component, maven-tomcat-plugin maybe... Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
Thank you for your reply. > Always look for the last "Caused by" in a stack trace for root cause. An > "IOException: Error writing to server" is indicative of a permissions > issue - I would start there, possibly the user account running the process. As pointed out in No. 3 the log said that the permission has been granted successfully. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mvn redeploy - double redeployment problem (within 0.2 seconds)
oke (TomcatManager.java:604) at org.codehaus.mojo.tomcat.TomcatManager.deployImpl (TomcatManager.java:662) at org.codehaus.mojo.tomcat.TomcatManager.deploy (TomcatManager.java:295) at org.codehaus.mojo.tomcat.AbstractDeployWarMojo.deployWar (AbstractDeployWarMojo.java:85) at org.codehaus.mojo.tomcat.AbstractDeployMojo.invokeManager (AbstractDeployMojo.java:85) at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute (AbstractCatalinaMojo.java:141) at org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute (AbstractWarCatalinaMojo.java:70) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) 1. Access log shows the PUT command: 02-Feb-2020 16:57:06.429 FINE [http-nio-80-exec-5] org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT /manager/text/deploy?path=xxx==true HTTP/1.1 2. Target-Tomcat's logging identifies the upload-user in this line: 02-Feb-2020 16:57:06.433 FINE [http-nio-80-exec-5] org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[Text Manager interface (for scripts)]' against PUT /text/deploy --> true 3. The user is authenticated in this log-line: 02-Feb-2020 16:57:06.446 FINE [http-nio-80-exec-5] org.apache.catalina.realm.CombinedRealm.authenticate Authenticated user [XXX] with realm [org.apache.catalina.realm.UserDatabaseRealm] 4. Tomcat is starting deployment: 02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application 'XXX' 5. Tomcat points out the deployment command: 02-Feb-2020 16:57:06.610 FINE [http-nio-80-exec-6] org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT /manager/text/deploy?path=XXX==true HTTP/1.1 6. Tomcat show the deployment-request size of ~71 MB Content-Length: 74784695 Then the socket is closed: 02-Feb-2020 16:57:06.603 FINE [http-nio-80-exec-5] org.apache.tomcat.util.net.NioEndpoint.close Socket: [org.apache.tomcat.util.net.NioChannel@33ae9b28:java.nio.channels.SocketChannel[closed]] closed 7. Access log shows the PUT command (AGAIN!!!): 02-Feb-2020 16:57:06.610 FINE [http-nio-80-exec-6] org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [PUT /manager/text/deploy?path=xxx==true HTTP/1.1 Please notice the two deployment threads: -6 and -5 Any ideas? Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 20 9930560 Fax: 0049 (0)30 / 20 9930561 Handy: 0049 (0)176 / 8 7521576 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Aw: Re: TC8 -> TC9 KeyAlias SSL not supported?
> Peter, > > Can you find what you are looking for here? > > > > > ? No! There is no such node or any similar content. And there simply can not be such a node because all the connector-xml-nodes are self-closing as you might have already noticed. AFAIK I should not create this SSLHostConfig because it is created automatically somehow according to the deprecated xml-node "keyAlias" (see: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated) )! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: TC8 -> TC9 KeyAlias SSL not supported?
> > I recently moved from T8 to T9 to use PKI. > > Exact versions? T8 = 8.5.50.0 on amazon-corretto-8.232.09.1-linux-x64 T9 = 9.0.30.0 on amazon-corretto-8.232.09.1-linux-x64 > > > My keystore contains multiple CAs. > > > > I had to modify the ssl-connector from > > org.apache.coyote.http11.Http11Protocol > > to > > org.apache.coyote.http11.Http11NioProtocol > > Full Connector configurations (with sensitive data masked)? TC8= TC9= Masks: - XXX keystore CA - keystore or truststore - X password for keystore/truststore > > Mark Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TC8 -> TC9 KeyAlias SSL not supported?
I recently moved from T8 to T9 to use PKI. My keystore contains multiple CAs. I had to modify the ssl-connector from org.apache.coyote.http11.Http11Protocol to org.apache.coyote.http11.Http11NioProtocol Unfortunately the attribute "keyAlias" seems to not be supported in the NIO anymore. SSL is not valid anymore because the wrong keyAlias is choosen. Any ideas how to select the correct key? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
