Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
On 4/8/2020 6:42 PM, calder wrote: > On Wed, Apr 8, 2020, 18:11 James H. H. Lampert > wrote: > >> >> And as to vendor-supplied installations, I agree with you. I'm rather >> irritated with the "Debianism" of splitting Tomcat up so completely that >> webapp contexts can be in at least two different places, and the general >> "Linuxism" of *not* including manager and host-manager (although I've >> never needed the latter) in the basic installation, and sometimes not >> even including a default root. >> > > It's not just a Debian thing - it's a Linux distro idiosyncrasy. > > And you don't have to use a distro's Tomcat layout / configuration. We > don't - we download P.V. Tomcat and extract to /opt (obviously, one could > choose to install to /usr/local if building) and use separate CATALINA_BASE > and CATALINA_HOME. > That's what I do as well. I use Ant scripts plus some property files to configure things. When a new version is rolled out, I edit a property file, build the new CATALINA_BASE directories with the Ant scripts, and I've got the new setup. To put the new setup into production, I shut down the existing Tomcats, move some links around, and bring up the new Tomcats. If the new Tomcats fail to come up properly, I swap the links back, bring up the old Tomcats, and then take a look at the logs in the appropriate CATALINA_BASE. The advantage to this setup is that I can do all of my upgrading except for the link swap at any time. The actual outage time is minutes. I should script the link swapping as well to shorten the down time and remove the chance of fat-fingering things. . . . just my two cents /mde/ signature.asc Description: OpenPGP digital signature
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
On Wed, Apr 8, 2020, 18:11 James H. H. Lampert wrote: > > And as to vendor-supplied installations, I agree with you. I'm rather > irritated with the "Debianism" of splitting Tomcat up so completely that > webapp contexts can be in at least two different places, and the general > "Linuxism" of *not* including manager and host-manager (although I've > never needed the latter) in the basic installation, and sometimes not > even including a default root. > It's not just a Debian thing - it's a Linux distro idiosyncrasy. And you don't have to use a distro's Tomcat layout / configuration. We don't - we download P.V. Tomcat and extract to /opt (obviously, one could choose to install to /usr/local if building) and use separate CATALINA_BASE and CATALINA_HOME.
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
James, On 4/8/2020 5:41 PM, James H. H. Lampert wrote: > On 4/8/20 4:57 PM, Mark Eggers wrote: >> See >> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy >> for some examples. > > Yes. That's the very point in the documentation that has my head spinning: >>> For example, the following will allow only hosts in >>> yournetwork.example.com to access content via your proxy server: > Require host yournetwork.example.com > > *Access* content?? I thought the Tomcat server is *serving* content. > >> So if I remember everything correctly, you could be really specific with >> the following: >> >> https://qux.baz.com;> >> Require ip 127.0.0.1 >> >> >> Place this inside the virtual host defined in the appropriate ssl.conf >> snippet. I think that you have an ssl.conf file per domain, right? >> >> Then in the non-ssl snippet, you would rewrite all the requests to go to >> HTTPS. > > That part makes sense, although I'm not entirely sure why I would want > to "be really specific" about the domain in the Proxy container, unless > it's to keep it from fighting with the other VirtualHosts. And actually, > I put the SSL and non-SSL VirtualHost blocks for the new domain in a > single .conf file. > James, This is going to be way off topic, and may not be completely correct. While I'm pretty good with Apache Tomcat, I'm still learning about Apache HTTPD. We should probably have further discussions off the mailing list. Anyway from an overview standpoint, think of a proxy as a virtual file system. Instead of serving information from a directory subject to constraints, Apache HTTPD is serving information from a proxy. From the browser's standpoint, the information is being served by Apache HTTPD, even though you're proxying Apache Tomcat. For example, on my mod_jk connected Apache Tomcat, the server is reported as: Server: Apache/2.2.15 (CentOS) This is what CentOS's patched Apache HTTPD 2.2 server reports, and is not indicative of the Apache Tomcat that I'm running behind mod_jk. So Apache HTTPD matches an incoming request to the most specific URL that it can, and then applies rules. This allows me to restrict HTTPD methods, do rewrites, and then passes the results off to Apache Tomcat (if configured to do so). When Apache Tomcat gets done with whatever it does (renders JSPs, creates / serves JSON, serves JS/CSS, etc.), it sends this back to Apache HTTPD. Apache HTTPD then does things like compress the output, edits / adds cookies, and edits / adds headers. Finally, the result gets sent to the browser. The browser has no idea that the response is generated via Apache Tomcat. OK, if someone notices a JSESSIONID, the user might have a clue. Other than that, no. I proxy behind Apache HTTPD for several reasons. Until recently, SAN certificates, Java, and Tomcat didn't play nicely together. That's changed. It's also easier to add some headers and cookies in Apache HTTPD than in Apache Tomcat. This is especially true for SameSite cookies, where certain browsers are broken and cannot handle SameSite=None. I have to do some ugly browser sniffing (fragile, not recommended) so that cookies generated by Apache Tomcat work inside an iframe. Now the order that all of this stuff happens is an entirely new discussion that might be better off-list, or on the Apache HTTPD mailing list. Think of Apache HTTPD as a Valve / Filter combination in the Apache Tomcat sense, if that helps. Oh, and being specific has some nice benefits. You can create different rules for different URLs before passing it off to a back end Apache Tomcat. Access control is just ONE of the things that you can do with Apache HTTPD sitting in front of Apache Tomcat. Running all of this in a cloud environment brings its own set of challenges. . . . just my two cents /mde/ signature.asc Description: OpenPGP digital signature
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
On 4/8/20 4:57 PM, Mark Eggers wrote: See https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy for some examples. Yes. That's the very point in the documentation that has my head spinning: For example, the following will allow only hosts in yournetwork.example.com to access content via your proxy server: Require host yournetwork.example.com *Access* content?? I thought the Tomcat server is *serving* content. So if I remember everything correctly, you could be really specific with the following: https://qux.baz.com;> Require ip 127.0.0.1 Place this inside the virtual host defined in the appropriate ssl.conf snippet. I think that you have an ssl.conf file per domain, right? Then in the non-ssl snippet, you would rewrite all the requests to go to HTTPS. That part makes sense, although I'm not entirely sure why I would want to "be really specific" about the domain in the Proxy container, unless it's to keep it from fighting with the other VirtualHosts. And actually, I put the SSL and non-SSL VirtualHost blocks for the new domain in a single .conf file. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
On 4/8/2020 4:11 PM, James H. H. Lampert wrote: > On 4/8/20 3:52 PM, Mark Eggers wrote: Require ip 127 > > Dear Mr. Eggers (et al.): > > I'm still not clear on what that even *does* (and the official docs > leave me even more confused: "only allow hosts in . . . to access > content via your proxy"); could you (or somebody else) explain it? > Remember, while I may be (deservedly or otherwise) a guru on getting > Tomcat running on an IBM Midrange box, I have no illusions about having > the slightest clue what I'm doing with httpd. Yesterday, I was tearing > my hair out because certbot wasn't working, only to discover that I had > a malformed VirtualHost. > > And as to vendor-supplied installations, I agree with you. I'm rather > irritated with the "Debianism" of splitting Tomcat up so completely that > webapp contexts can be in at least two different places, and the general > "Linuxism" of *not* including manager and host-manager (although I've > never needed the latter) in the basic installation, and sometimes not > even including a default root. > > -- Basically, the is applied to all the proxy statements in your configuration. See https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy for some examples. The Require statement means only allow connections from what is required - in my example 127 gets mapped to 127.0.0.1 (localhost). So the configuration that I have given restricts all proxy connections to localhost, which means that no outside proxy connections are possible. This is a good thing, I think. So if I remember everything correctly, you could be really specific with the following: https://qux.baz.com;> Require ip 127.0.0.1 Place this inside the virtual host defined in the appropriate ssl.conf snippet. I think that you have an ssl.conf file per domain, right? Then in the non-ssl snippet, you would rewrite all the requests to go to HTTPS. Again, please verify this with an Apache HTTPD expert, and discuss this on the Apache HTTPD mailing list. I do all of this with mod_jk, so my configuration is quite a bit different. Again, I personally like the broad brush approach and then override specifics per virtual host. Sort of a combination of least permissions plus management by exception. . . . just my two cents /mde/ signature.asc Description: OpenPGP digital signature
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
On 4/8/20 3:52 PM, Mark Eggers wrote: Require ip 127 Dear Mr. Eggers (et al.): I'm still not clear on what that even *does* (and the official docs leave me even more confused: "only allow hosts in . . . to access content via your proxy"); could you (or somebody else) explain it? Remember, while I may be (deservedly or otherwise) a guru on getting Tomcat running on an IBM Midrange box, I have no illusions about having the slightest clue what I'm doing with httpd. Yesterday, I was tearing my hair out because certbot wasn't working, only to discover that I had a malformed VirtualHost. And as to vendor-supplied installations, I agree with you. I'm rather irritated with the "Debianism" of splitting Tomcat up so completely that webapp contexts can be in at least two different places, and the general "Linuxism" of *not* including manager and host-manager (although I've never needed the latter) in the basic installation, and sometimes not even including a default root. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
James,
On 4/8/2020 3:27 PM, James H. H. Lampert wrote:
> Dear Mr. Eggers, et al.:
>
> Well, after running test installations of Tomcat on a whole string of
> EC2 spot instances, I went ahead and installed it on the target server.
> I've got it running, and enabled to start automatically, and I've added
> a security group to temporarily open 8080 to my office IP address, so
> that I can reach it directly and verify that it works (it does). And
> I've also verified that mod_proxy and mod_proxy_http are enabled (they
> already were; I didn't have to lift a finger)
>
> On 4/6/20 2:13 PM, Mark Eggers wrote:
>> # Secure your proxy - localhost for now - this is IMPORTANT
>>
>> Require ip 127
>>
>>
>> # Map applications
>> # You could just use / if you're proxying all requests
>> # Pick the correct Apache Tomcat port
>>
>> ProxyPass "/foo" "http://127.0.0.1:8080/foo;
>> ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo;
>
> Now I'm not sure I understand the container and its
> contents. The httpd and Tomcat servers are both running on the same box.
> "Require ip 127" sounds like it's specifying an incomplete IP address.
>
> I can sort-of understand the ProxyPass and ProxyPassReverse directives.
> Given that all requests to this particular VirtualHost ("qux.baz.com" to
> speak metasyntactically) should be going to Tomcat (which will have a
> root context and at least four [including manager] named contexts),
> would this be:
>
> ProxyPass "/" "http://127.0.0.1:8080/;
> ProxyPassReverse "/" "http://127.0.0.1:8080;
>
> ???
>
> Conversely, none of the other VirtualHosts would be proxying Tomcat (or
> anything else), so should all this be within the VirtualHost?
>
> --
> JHHL
>
See the following for IP address configuration in Apache HTTPD 2.4:
https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html
I think putting the proxy restriction in the virtual host would be OK,
but I'm a belt and suspenders kind of person. Putting it in the default
host makes sure that someone doesn't inadvertently open up your server
later. You can always override it at the virtual host level if you wish.
Finally, one of my pet peeves concerning vendor-supplied Apache HTTPD
installations is that they turn on a lot of modules by default. The
first thing I do with such an installation is to turn off everything
that is not being used in an installation. This usually includes all of
the _dav, _user, and proxy_ modules.
. . . just my two cents
/mde/
signature.asc
Description: OpenPGP digital signature
Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
Dear Mr. Eggers, et al.:
Well, after running test installations of Tomcat on a whole string of
EC2 spot instances, I went ahead and installed it on the target server.
I've got it running, and enabled to start automatically, and I've added
a security group to temporarily open 8080 to my office IP address, so
that I can reach it directly and verify that it works (it does). And
I've also verified that mod_proxy and mod_proxy_http are enabled (they
already were; I didn't have to lift a finger)
On 4/6/20 2:13 PM, Mark Eggers wrote:
# Secure your proxy - localhost for now - this is IMPORTANT
Require ip 127
# Map applications
# You could just use / if you're proxying all requests
# Pick the correct Apache Tomcat port
ProxyPass "/foo" "http://127.0.0.1:8080/foo;
ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo;
Now I'm not sure I understand the container and its
contents. The httpd and Tomcat servers are both running on the same box.
"Require ip 127" sounds like it's specifying an incomplete IP address.
I can sort-of understand the ProxyPass and ProxyPassReverse directives.
Given that all requests to this particular VirtualHost ("qux.baz.com" to
speak metasyntactically) should be going to Tomcat (which will have a
root context and at least four [including manager] named contexts),
would this be:
ProxyPass "/" "http://127.0.0.1:8080/;
ProxyPassReverse "/" "http://127.0.0.1:8080;
???
Conversely, none of the other VirtualHosts would be proxying Tomcat (or
anything else), so should all this be within the VirtualHost?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: learning tomcat 7 on Linux
OK then. So Tomcat installed, and I start learning tomorrow. Thank you, folks. :-) [image: tom.png] On Wed, 8 Apr 2020 at 17:59, Richard Monson-Haefel wrote: > I agree with Olaf. My courses are for Tomcat 9. I would upgrade to 9. My > course shows you in detail how to install 9 on Linux (although I use > LinuxMint its all done with the bash shell so its should work just as as > well on CentOSO) > > On Wed, Apr 8, 2020 at 11:50 AM Olaf Kock wrote: > > > > > On 08.04.20 14:55, Andy Sloane wrote: > > > Hi, > > > I have set up a Linux CentOS 7 host, and have installed Tomcat 7... > > > > > > ... > > > I would like to learn how to develop webapps. > > > > > I see no particular reason to start with Tomcat 7. Most of the code that > > you will learn will be version independent, and the End of Life for > > Tomcat 7 is already set to March 2021. I'd recommend to go with Tomcat > > 9. Installation - especially for development purposes - will be trivial > > and is easier for development anyway. > > > > I'm assuming you're running the old version, because that's what the > > CenOS repositories hold. For development: No need to do this. > > > > I don't know Richard's course, but I assume that he'll talk about a > > development environment and installing a new dev environment as well: > > Use that, rather than whatever comes with CentOS. Access permissions on > > the files of a development server are far simpler than on fully > > public-server-enabled installs. > > > > Olaf > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > -- > Richard Monson-Haefel > https://twitter.com/rmonson > https://www.linkedin.com/in/monsonhaefel/ >
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
Hi, Thanks for the test case. I've been able to figure out what is going wrong. I'll be able to fix this for the May releases (due about a month from now). I'm just thinking about the best way to fix this from the various options. I have a couple of questions: 1. Would a configuration based work-around be for interest? 2. Would the configuration based approach be a viable long term alternative for you? Mark On 08/04/2020 10:47, Jackson Ong wrote: > Hello Mark, > > I have tested on 8.5.54, still not able to load > javax.servlet.ServletContainerInitializer. I have created sample code to > recreate the issue. > https://github.com/salvatore-clong/tomcatSCI > > We use custom webapp class loader to load jar from common path, for this > case I put the jar in this path (tomcatSCI/WebContent/WEB-INF/commonLib). > Custom webapp class loader will load the jar in this path. ( > https://github.com/salvatore-clong/tomcat-custom-class-loader) > > 1) copy and place custom-classloader-tomcat-8.5.jar in tomcat lib folder > 2) Run tomcatSCI project on tomcat 8.5 > 3) check console if this appear INFO: jar addedtomcatSCI.jar (this is > printed from custom webapp class loader) > 4) check console if this appear ABC. (this is printed from > ServletContainerInitializer onStartup) > > On Tue, Apr 7, 2020 at 4:55 PM Mark Thomas wrote: > >> On 07/04/2020 08:09, Jackson Ong wrote: >>> Hi, >>> >>> I have tested 8.5.51 and 8.5.53, both doesn't work. The current version >>> that works for me is tomcat 8.5.50 >>> The recent changed on SCI was tomcat 7.0.103 ( >>> https://tomcat.apache.org/tomcat-7.0-doc/changelog.html) >>> Previously we have issue with tomcat 7.0.100 to 102, tested it works in >>> 7.0.103. >> >> Can you test with the 8.5.54 release candidate please? Details on how to >> obtain it are on the dev@ list. >> >> If you still see an issue, please create the simplest possible test case >> that recreates the issue and provide the steps necessary to recreate the >> issue from a clean 8.5.54 install. >> >> Thanks, >> >> Mark >> >> >>> >>> Jackson >>> >>> On Tue, Apr 7, 2020 at 2:51 PM Martin Grigorov >> wrote: >>> Hi, On Tue, Apr 7, 2020 at 9:01 AM Jackson Ong <83cl...@gmail.com> wrote: > We have an webapp running fine on Tomcat 8.5.50 and below and we used a > custom WebappClassLoader to load jars (common path for jars), but it failed > to load on Tomcat 8.5.51 and above. Upon checking, we noticed that > Which versions of "above" you have tried ? Because there was a regression with SCI recently that have been fixed in 8.5.53 (I think. Better check the changelogs). 8.5.54 is being tested at the moment and if no issues are found it will >> be released in the next few days. Martin > javax.servlet.ServletContainerInitializer that we defined in the jar is not > being loaded. > > From org.apache.catalina.startup.WebappServiceLoader source code of Tomcat > 8.5.51, the classLoader was changed from >> servletContext.getClassloader() > (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat >> 8.5.51 > line 144) > > However placing the jar at WEB-INF/lib it was able to load > javax.servlet.ServletContainerInitializer. The problem is when the jar >> is > outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). > > Thanks > >>> >> >> >> - >> 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: learning tomcat 7 on Linux
I agree with Olaf. My courses are for Tomcat 9. I would upgrade to 9. My course shows you in detail how to install 9 on Linux (although I use LinuxMint its all done with the bash shell so its should work just as as well on CentOSO) On Wed, Apr 8, 2020 at 11:50 AM Olaf Kock wrote: > > On 08.04.20 14:55, Andy Sloane wrote: > > Hi, > > I have set up a Linux CentOS 7 host, and have installed Tomcat 7... > > > > ... > > I would like to learn how to develop webapps. > > > I see no particular reason to start with Tomcat 7. Most of the code that > you will learn will be version independent, and the End of Life for > Tomcat 7 is already set to March 2021. I'd recommend to go with Tomcat > 9. Installation - especially for development purposes - will be trivial > and is easier for development anyway. > > I'm assuming you're running the old version, because that's what the > CenOS repositories hold. For development: No need to do this. > > I don't know Richard's course, but I assume that he'll talk about a > development environment and installing a new dev environment as well: > Use that, rather than whatever comes with CentOS. Access permissions on > the files of a development server are far simpler than on fully > public-server-enabled installs. > > Olaf > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
Re: learning tomcat 7 on Linux
On 08.04.20 14:55, Andy Sloane wrote: > Hi, > I have set up a Linux CentOS 7 host, and have installed Tomcat 7... > > ... > I would like to learn how to develop webapps. > I see no particular reason to start with Tomcat 7. Most of the code that you will learn will be version independent, and the End of Life for Tomcat 7 is already set to March 2021. I'd recommend to go with Tomcat 9. Installation - especially for development purposes - will be trivial and is easier for development anyway. I'm assuming you're running the old version, because that's what the CenOS repositories hold. For development: No need to do this. I don't know Richard's course, but I assume that he'll talk about a development environment and installing a new dev environment as well: Use that, rather than whatever comes with CentOS. Access permissions on the files of a development server are far simpler than on fully public-server-enabled installs. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: learning tomcat 7 on Linux
OK, so I'm going to have a look at that, since there's a 10-day free trial. :-) On Wed, 8 Apr 2020 at 14:11, Richard Monson-Haefel wrote: > Hi, > > A bit of self-promotion here. > > I just released a course, "Tomcat for Java Development" less than two weeks > ago which includes coverage of Tomcat on Linux. I'm also releasing - later > this week - a complementary course, "Java Application Development with > Tomcat". The first course teaches how to install, configure, troubleshoot, > and secure Tomcat. The second course focuses on the development of web > applications using servlets and JSPs on Tomcat. Both are introductory > level courses but they are very current and I think pretty good. They are > also pretty short - less than 2 hours each. > > You can find "Tomcat for Java Development" on Pluralsight.com today and > "Java Application Development with Tomcat" later in the week. > > Good luck! > > Richard > > > On Wed, Apr 8, 2020 at 7:56 AM Andy Sloane > wrote: > > > Hi, > > I have set up a Linux CentOS 7 host, and have installed Tomcat 7... > > > > [root@db3 ROOT]# /sbin/tomcat version > > Server version: Apache Tomcat/7.0.76 > > Server built: Mar 17 2020 23:48:55 UTC > > Server number: 7.0.76.0 > > OS Name:Linux > > OS Version: 3.10.0-1062.12.1.el7.x86_64 > > Architecture: amd64 > > JVM Version:1.8.0_242-b08 > > JVM Vendor: Oracle Corporation > > > > I would like to learn how to develop webapps. > > > > This is just for a hobby - I'll never sell anything I write, and will > never > > be a dev. I currently work doing UNIXy stuff for a big US multinational. > > This is just a thing on the side, like learning to play guitar. Can > > someone please suggest some resources? > > > > Many thanks. > > > > > -- > Richard Monson-Haefel > https://twitter.com/rmonson > https://www.linkedin.com/in/monsonhaefel/ >
Re: learning tomcat 7 on Linux
Hi, A bit of self-promotion here. I just released a course, "Tomcat for Java Development" less than two weeks ago which includes coverage of Tomcat on Linux. I'm also releasing - later this week - a complementary course, "Java Application Development with Tomcat". The first course teaches how to install, configure, troubleshoot, and secure Tomcat. The second course focuses on the development of web applications using servlets and JSPs on Tomcat. Both are introductory level courses but they are very current and I think pretty good. They are also pretty short - less than 2 hours each. You can find "Tomcat for Java Development" on Pluralsight.com today and "Java Application Development with Tomcat" later in the week. Good luck! Richard On Wed, Apr 8, 2020 at 7:56 AM Andy Sloane wrote: > Hi, > I have set up a Linux CentOS 7 host, and have installed Tomcat 7... > > [root@db3 ROOT]# /sbin/tomcat version > Server version: Apache Tomcat/7.0.76 > Server built: Mar 17 2020 23:48:55 UTC > Server number: 7.0.76.0 > OS Name:Linux > OS Version: 3.10.0-1062.12.1.el7.x86_64 > Architecture: amd64 > JVM Version:1.8.0_242-b08 > JVM Vendor: Oracle Corporation > > I would like to learn how to develop webapps. > > This is just for a hobby - I'll never sell anything I write, and will never > be a dev. I currently work doing UNIXy stuff for a big US multinational. > This is just a thing on the side, like learning to play guitar. Can > someone please suggest some resources? > > Many thanks. > -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
learning tomcat 7 on Linux
Hi, I have set up a Linux CentOS 7 host, and have installed Tomcat 7... [root@db3 ROOT]# /sbin/tomcat version Server version: Apache Tomcat/7.0.76 Server built: Mar 17 2020 23:48:55 UTC Server number: 7.0.76.0 OS Name:Linux OS Version: 3.10.0-1062.12.1.el7.x86_64 Architecture: amd64 JVM Version:1.8.0_242-b08 JVM Vendor: Oracle Corporation I would like to learn how to develop webapps. This is just for a hobby - I'll never sell anything I write, and will never be a dev. I currently work doing UNIXy stuff for a big US multinational. This is just a thing on the side, like learning to play guitar. Can someone please suggest some resources? Many thanks.
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
Hello Mark, I have tested on 8.5.54, still not able to load javax.servlet.ServletContainerInitializer. I have created sample code to recreate the issue. https://github.com/salvatore-clong/tomcatSCI We use custom webapp class loader to load jar from common path, for this case I put the jar in this path (tomcatSCI/WebContent/WEB-INF/commonLib). Custom webapp class loader will load the jar in this path. ( https://github.com/salvatore-clong/tomcat-custom-class-loader) 1) copy and place custom-classloader-tomcat-8.5.jar in tomcat lib folder 2) Run tomcatSCI project on tomcat 8.5 3) check console if this appear INFO: jar addedtomcatSCI.jar (this is printed from custom webapp class loader) 4) check console if this appear ABC. (this is printed from ServletContainerInitializer onStartup) On Tue, Apr 7, 2020 at 4:55 PM Mark Thomas wrote: > On 07/04/2020 08:09, Jackson Ong wrote: > > Hi, > > > > I have tested 8.5.51 and 8.5.53, both doesn't work. The current version > > that works for me is tomcat 8.5.50 > > The recent changed on SCI was tomcat 7.0.103 ( > > https://tomcat.apache.org/tomcat-7.0-doc/changelog.html) > > Previously we have issue with tomcat 7.0.100 to 102, tested it works in > > 7.0.103. > > Can you test with the 8.5.54 release candidate please? Details on how to > obtain it are on the dev@ list. > > If you still see an issue, please create the simplest possible test case > that recreates the issue and provide the steps necessary to recreate the > issue from a clean 8.5.54 install. > > Thanks, > > Mark > > > > > > Jackson > > > > On Tue, Apr 7, 2020 at 2:51 PM Martin Grigorov > wrote: > > > >> Hi, > >> > >> On Tue, Apr 7, 2020 at 9:01 AM Jackson Ong <83cl...@gmail.com> wrote: > >> > >>> We have an webapp running fine on Tomcat 8.5.50 and below and we used a > >>> custom WebappClassLoader to load jars (common path for jars), but it > >> failed > >>> to load on Tomcat 8.5.51 and above. Upon checking, we noticed that > >>> > >> > >> Which versions of "above" you have tried ? > >> Because there was a regression with SCI recently that have been fixed in > >> 8.5.53 (I think. Better check the changelogs). > >> 8.5.54 is being tested at the moment and if no issues are found it will > be > >> released in the next few days. > >> > >> Martin > >> > >> > >>> javax.servlet.ServletContainerInitializer that we defined in the jar is > >> not > >>> being loaded. > >>> > >>> From org.apache.catalina.startup.WebappServiceLoader source code of > >> Tomcat > >>> 8.5.51, the classLoader was changed from > servletContext.getClassloader() > >>> (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat > 8.5.51 > >>> line 144) > >>> > >>> However placing the jar at WEB-INF/lib it was able to load > >>> javax.servlet.ServletContainerInitializer. The problem is when the jar > is > >>> outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). > >>> > >>> Thanks > >>> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
