recommendations for using multiple CRLs
Does this group have any recommendations for merging multiple external CRLs into one CRL for use with Tomcat, or just making Tomcat aware of multiple CRLs?
Re: distinction between resource charset and format octet decoding
On 01/02/2019 17:58, Garret Wilson wrote: > OK, Mark, I've made my initial edits to the > https://wiki.apache.org/tomcat/FAQ/CharacterEncoding page. _Please check > them over!_ This is my first edit to the wiki. > > That page has a lot of legacy information, some of which had to do with > internal Tomcat stuff, and some of which had to do with minute details > of obsolete RFCs and evolution of browser behavior. I didn't want to > spend the entire day (week?) on this, so I tried to surgically to only > address the sections relating to POST of > application/x-www-form-urlencoded and how percent-encoded octets are > interpreted. I couldn't resist updating the specification links and > changing just a little prose about URL percent encoding. > > There is the risk now that other sections of the page are still outdated > and conflict with my changes, but most importantly the FAQ should > provide more complete information on how Tomcat web applications can be > made to work with modern browsers. > > Please let me know if I bungled anything or if I need to clarify something. LGTM. > Thanks for letting me participate. No need to thank us. We should be thanking you. Thank you. So, what do you want to work on next? ;) Cheers, Mark > > Garret > > On 1/23/2019 12:26 AM, Mark Thomas wrote: >> On 23/01/2019 05:07, Garret Wilson wrote: >>> On 1/15/2019 3:20 AM, Mark Thomas wrote: … Anything in PascalCase becomes a link to a wiki page of that name. Usernames are created in this form so references to the user automatically become links to that user's page in the wiki. >>> >>> Ah, OK, that explains it. Very good to know. Maybe a little semantic >>> overloading, but as this is my first wiki account anywhere, I'm guessing >>> it's typical with whatever software you're using. >>> >>> Anyway my account is created, with username `GarretWilson`. After I get >>> permissions I'll update the info on octet encoding for >>> application/x-www-form-urlencoded in relation to the servlet spec. It >>> may not be immediately, but I'll slowly but surely get to it. >> Karma granted. Happy editing. >> >> Cheers, >> >> 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: distinction between resource charset and format octet decoding
OK, Mark, I've made my initial edits to the https://wiki.apache.org/tomcat/FAQ/CharacterEncoding page. _Please check them over!_ This is my first edit to the wiki. That page has a lot of legacy information, some of which had to do with internal Tomcat stuff, and some of which had to do with minute details of obsolete RFCs and evolution of browser behavior. I didn't want to spend the entire day (week?) on this, so I tried to surgically to only address the sections relating to POST of application/x-www-form-urlencoded and how percent-encoded octets are interpreted. I couldn't resist updating the specification links and changing just a little prose about URL percent encoding. There is the risk now that other sections of the page are still outdated and conflict with my changes, but most importantly the FAQ should provide more complete information on how Tomcat web applications can be made to work with modern browsers. Please let me know if I bungled anything or if I need to clarify something. Thanks for letting me participate. Garret On 1/23/2019 12:26 AM, Mark Thomas wrote: On 23/01/2019 05:07, Garret Wilson wrote: On 1/15/2019 3:20 AM, Mark Thomas wrote: … Anything in PascalCase becomes a link to a wiki page of that name. Usernames are created in this form so references to the user automatically become links to that user's page in the wiki. Ah, OK, that explains it. Very good to know. Maybe a little semantic overloading, but as this is my first wiki account anywhere, I'm guessing it's typical with whatever software you're using. Anyway my account is created, with username `GarretWilson`. After I get permissions I'll update the info on octet encoding for application/x-www-form-urlencoded in relation to the servlet spec. It may not be immediately, but I'll slowly but surely get to it. Karma granted. Happy editing. Cheers, 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
Re: distinction between resource charset and format octet decoding
On 2/1/2019 9:38 AM, Christopher Schultz wrote: Amazing. A close reading of RFC 3986 reveals that there is no clear mandate for UTF-8 in existing URI schemes, even though recommended for new schemes. Anyway, everyone seems to have settled on UTF-8 (Tomcat included), so I'll try to indicate that. Wait... are you saying that _it's the Wild West out there?_ ;) Yes. The web is indeed held together with duct-tape and bailing wire. It's amazing that it works as well as it does. Hahaha. I'm /so/ happy someone agrees with me! Here's to improving things with a little JB Weld once in a while. (That's what my grandparents used on the farm when the bailing wire and duct tape couldn't handle it.) Garret
Re: distinction between resource charset and format octet decoding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Garret, On 2/1/19 11:08, Garret Wilson wrote: > On 2/1/2019 7:23 AM, Garret Wilson wrote: >> … * "There /is no default encoding for URIs/ specified anywhere, >> which is why there is a lot of confusion when it comes to >> decoding these values." Sheesh, this is is ancient. I'll correct >> it as per https://tools.ietf.org/html/rfc3986#section-2.5 . > > > Amazing. A close reading of RFC 3986 reveals that there is no > clear mandate for UTF-8 in existing URI schemes, even though > recommended for new schemes. Anyway, everyone seems to have settled > on UTF-8 (Tomcat included), so I'll try to indicate that. Wait... are you saying that _it's the Wild West out there?_ ;) Yes. The web is indeed held together with duct-tape and bailing wire. It's amazing that it works as well as it does. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxUhDEACgkQHPApP6U8 pFhWlA/8Cxr6xzT8+cw5Mu/a8cH788p+ucK4QtO9Qlm6EBhhX2sW9BelWpk2ftOX xypZkwW155D2hlz58eUTGSoFl92rgFZNXmXBoIXd+MDgNS/b0zgabb7N7wlHswzj LJArA9GtXNjRy5vJc4Bpe37ZpiqcV9f/sbQhSO31ZrJYvnVuOOYszzfp2g6UWlg5 +OAgfi2L99uMxJdqc81eIVsL6mmmhlkJYe6ejAZjb/EQ2Lk74MKlgCUfaoasCdYd hqdQJIBpRGvUnx6UEoq+sdEilBAXTJocGv8cyOFQY5rHcaTy7WIQ9mIWilTjBb6O gxWJbgRfX+uOVhTT5mo7LoE+YVLQZ3QPAM21SEXtX3PR5Vuk4hB8SYj3/er7S7v2 /kPL0d5K2DsO8034PoZQBturIV8pkiF5jqr2nSTND/B0nFK9hcZu27qY9RigHF95 8owMY7/hdMsK2PlYOwyj6dZSMx94Iy5mWDCrF3GUFCbEN9u3/6HoRYuJZOpCv8h1 aZHZmiYDEtxzxL8OkXNqyuBu4k+HJ58/ABMelpXOjxMVHuFXkqny6XiqrzyWac+z yW1otX/uLKgqKI9PL3O8MfzVS5LZ6XVtprkZUDhCBvsA8vQTZYBRVQu3DiGMPojj U4STB1VBJSV4I67bBhkQaAZnsqIgeNi/qzHC+5h6hbHl+Me1lRg= =Z4XG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: distinction between resource charset and format octet decoding
On 2/1/2019 7:23 AM, Garret Wilson wrote: … * "There /is no default encoding for URIs/ specified anywhere, which is why there is a lot of confusion when it comes to decoding these values." Sheesh, this is is ancient. I'll correct it as per https://tools.ietf.org/html/rfc3986#section-2.5 . Amazing. A close reading of RFC 3986 reveals that there is no clear mandate for UTF-8 in existing URI schemes, even though recommended for new schemes. Anyway, everyone seems to have settled on UTF-8 (Tomcat included), so I'll try to indicate that. Garret - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: distinction between resource charset and format octet decoding
Good morning, I'm just getting to the editing. I'm going to list some thoughts I have as I go through this, so you can verify things: * The servlet spec links are way out of date. I'll update them. * "There /is no default encoding for URIs/ specified anywhere, which is why there is a lot of confusion when it comes to decoding these values." Sheesh, this is is ancient. I'll correct it as per https://tools.ietf.org/html/rfc3986#section-2.5 . * "Most of the web uses ISO-8859-1 as the default for query strings." Is this still true?! In light of the above, I would think it is not true, but I wanted to ask, as you know better about what you've seen "in the wild". Garret
Re: Disable auto scanning for EJBs in a NON-EJB web application in Tomee 7.1.0
On 01/02/2019 12:20, Priyadarshini Krishna wrote: > Request help. Try asking the TomEE project rather than the Tomcat project.] Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Disable auto scanning for EJBs in a NON-EJB web application in Tomee 7.1.0
Hi, I am working on migrating a web-app for my organisation. We have started using Spring 5, which needs the latest Tomee and hence the migration process. Our application works fine on Tomee 1.7.5. We do not have any EJBs in our web application, but Tomee 7.1.0 seems to scan for one. I have done the following changes, but have not found any success. Changes made: 1.) Create empty Scan.xml under WEB-INF folder in the applictaion 2.) Update exclusions.list as follows default-list MyappJar- cxf-core- MyappWar- 3.) Updated the system.properties under tomee/conf # Which paths / libraries should be scanned? openejb.scan.webapp.container = false #openejb.scan.webapp.container.includes = .*(geronimo|mp-jwt|failsafe).* #openejb.scan.webapp.container.excludes = None of the above seems to work and I get the following error. == *ERROR:* INFO: Dumping Generated openejb-jar.xml to: /opt/tomee/temp/openejb-jar-2341936619230328309Login.xml Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: FAIL ... Login: Missing required persistence.xml for @PersistenceContext ref "entityManager" to unit "workflowPersistenceUnit" Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: FAIL ... Login: Missing required persistence.xml for @PersistenceContext ref "entityManager" to unit "auditLoggingPersistenceUnit" Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: Invalid EjbModule(name=Login, path=/opt/tomee/webapps/Login) Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: FAIL ... Login: Missing required persistence.xml for @PersistenceContext ref "entityManager" to unit "workflowPersistenceUnit" Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: FAIL ... Login: Missing required persistence.xml for @PersistenceContext ref "entityManager" to unit "auditLoggingPersistenceUnit" Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults logResults SEVERE: Invalid WebModule(name=Login, path=/opt/tomee/webapps/Login) Feb 01, 2019 11:32:40 AM org.apache.openejb.config.ReportValidationResults deploy INFO: Set the 'openejb.validation.output.level' system property to VERBOSE for increased validation details. Feb 01, 2019 11:32:40 AM org.apache.tomee.catalina.TomcatWebAppBuilder startInternal SEVERE: Unable to deploy collapsed ear in war StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Login] org.apache.openejb.config.ValidationFailedException: Module failed validation. AppModule(name=Login) I have few Spring beans (not EJBs), which have the annotation "@PersistenceContext". Request help. -- Kind Regards Thank You, Priya
