Re: SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
James, try to set tomcat port to 1443 and check, and write us if it starts than, try to start knock knock server with default port, than change it to 443 port - http://docs.oracle.com/javase/tutorial/networking/sockets/examples/KnockKnockServer.java (link and explanation is here http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html) write about the results regards Jakub On Wed, Apr 24, 2013 at 11:23 PM, James H. H. Lampert < jam...@touchtonecorp.com> wrote: > Neven Cvetkovic wrote: > > Btw in your log "" is actual real IP address, you just removed it >> for >> the mailing list, correct? >> > > That's the actual message from CATALINA.OUT, verbatim. Perhaps we're not > specifying an IP address in the configuration files (how would one do > that?), and (with several IP addresses assigned to the box) it's having > trouble deciding which one we want? > > And as I said, earlier today, I did find *something* else listening on 443 > (incidentally, on an AS/400, NETSTAT has a synonym, more idiomatically > native to the OS, of WRKTCPSTS), but now there's no trace of that something > else, and even when it was there, it was kind of elusive. > > -- > JHHL > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Policy files
Well I understand that there is only one SecurityManager per JVM, but as you mentioned I can restrict actions for specific CodeBases. This is what I am actually trying to do. I want the student web applications to have only a hand full of permissions defined in a policy file. I think I explained my self wrong earlier. The policy file I am speaking of, the one I want to apply to student projects, is more like a set of permissions that I want to give the web applications. I mainly want my testsuite and everything packaged with it to have all permissions. Generally the student projects should have no permissions. I want to give these applications only a minimal set of permissions, only the ones they actually would need to fullfil their tasks. The WebappClassLoader supports the method addPermission(Permission) which is nice somehow, but I don't want to hard code the permissions but rather have them in a policy file or so. The reason for having the permissions in a policy file is mainly because I thought I can configure something in context.xml so that the policy file gets picked up by tomcat. I just don't want to have these applications running on my computer not knowing what they actually do. To be honest I couldn't think of any permission I would give a student application. The libraries that can be used are predefined, so I give these jar files the permissions for reflection or whatever they need to work properly. Am I simplifying the whole thing and is what I want much harder to achive than I think? Am 24.04.2013 22:20, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christian, On 4/24/13 1:51 PM, Christian Beikov wrote: Yes we are talking about security manager policies. Good :) There's a lot about Spring that I don't know about, so I was just checking that you weren't talking about some crazy IoC thing or annotation-driven magic that no mere mortal can follow. So there is no possibility to just push the policy file to the WebappClassLoader? Nope: the SecurityManager applies to the whole JVM. But, the policy can bless certain JARs, etc. as being privileged. So, you make Tomcat and whatever code you wrote privileged and then leave all the student code to run under the heavy-handed security policy. As stated in the reply to Matrin Gainty there do exist methods to restrict the webapp, but unfortunately no method for supplying a policy file. Right: you can control the deployment descriptor(s) but not really much else. So this means I have to parse the policy file myself and add the permissions manually to the classloader? Uh... I don't think that's possible. I must admit I'm no ClassLoader ninja, but I don't think there's a way to tell a ClassLoader anything about security policies. What kinds of operations are you trying to restrict? Are there any options in the context.xml I could set for specifying a webapp local policy so that I don't have to fiddle around with how tomcat is called? I know how to apply a policy at runtime, but don't know how this affects tomcat when I apply it e.g. in a ServletContextListener. I think I'd have to understand more about what you are trying to do in order to be helpful. The SecurityManager applies its policies globally and you can't customize anything on a per-ClassLoader basis. You can do it on a per-codebase basis, but you have to know the URL(s) of the codebase(s) in advance. Would be cool if there was an option to do that kind of stuff. Yes, I rather think it would be cool to specify a security policy on a per-ClassLoader basis, but there are definitely some thorny issues there otherwise I think Sun/Oracle would have implemented that capability by now. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReD6oAAoJEBzwKT+lPKRYDGAP/R9SjzcX0ENxQ5A7/N+S26M8 Jd5sNOisQ9mdVowygJAwppYDqtUalmMZ5qZTtsyYZYWKn3QpiML10Qr36elFZsA5 zoCA1JRB+hwC/vhNgJGdhhNxDOEQo66mfiJlfQ0rHpOGwVrGppAuSV4kVfX5aZCQ 9Ssq2HZvfLE7tL0pg+qnBT1AA9/HU+hAmk4GkCETSMR16jB8NrwI10ejU7gt1F4F BaUCULZvYtLRelbsAQTfz4ZOQL0FZq2zD85BeZ+hey0koinpr+nY1aRGy4ASbmrM Eke8ruYKW5xbVmSyQ0A4JmaYmMrYFfc7SgdR7UOkD21wbHA87fSHF9oNhhom2Tqd Qsdn89swuBwp6XkS1akbfRc6RJ4WPCxNfxBWceGWlJewtgY8XRD8lPYOsHCSiVN/ SOSVnmCaa8Fs6ygk75wo6IKI+VlLRJqFSK5pr1iGK9hVC+xgBGB5APrhMhvSCUmO SuP6IxFMSRDhghlxUbDhd7hW7KZnpXGQCJZjSoEsW/ysjhwy0hfhLbkEGTyYV8Az wCap5r3eHc5KsHP0FK9F283DbiUhV8oHoLK0ddzKd9KrHbxap4Vekk2tqbUA52Vn gpcRk5vodI88w0mvtdc9b57luHPedmY87bqmayjqzh6VHixlT/O8+CQhmJLRrln3 Wf6YgQg1Li6p//YLwHpo =TJPJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Mit freundlichen Grüßen, *Christian Be
Re: SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
Neven Cvetkovic wrote: Btw in your log "" is actual real IP address, you just removed it for the mailing list, correct? That's the actual message from CATALINA.OUT, verbatim. Perhaps we're not specifying an IP address in the configuration files (how would one do that?), and (with several IP addresses assigned to the box) it's having trouble deciding which one we want? And as I said, earlier today, I did find *something* else listening on 443 (incidentally, on an AS/400, NETSTAT has a synonym, more idiomatically native to the OS, of WRKTCPSTS), but now there's no trace of that something else, and even when it was there, it was kind of elusive. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
James, Something else is listening on port 443 (SSL port). I am no AS/400 expert, but you should be able to see listening processes, e.g. Linux: netstat -vatpn | grep 443 Windows: netstat -aon | findstr "443" Did you try connecting to the port 443? Btw in your log "" is actual real IP address, you just removed it for the mailing list, correct? On Wed, Apr 24, 2013 at 4:50 PM, James H. H. Lampert < jam...@touchtonecorp.com> wrote: > We're trying to bring up SSL in Tomcat on a customer AS/400 (an E4C at > V7R1, using the /QOpenSys/QIBM/ProdData/**JavaVM/jdk60/64bit JVM), and > every time we launch CATALINA, we get > > SEVERE: Failed to initialize end point associated with ProtocolHandler >> ["http-bio-443"] >> Throwable occurred: java.net.BindException: The socket name is already in >> use. :443 >> > > Earlier today, I found something (I couldn't tell WHAT, because there were > no jobs associated with the port) listening (and idle for 16 hours) on 443, > on one of the IP addresses, but now, nothing on that port. I also looked > for restrictions on that port, and there aren't any. > > Any ideas of where to look next? > > -- > JHHL > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: in web.xml
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, April 24, 2013 3:28 PM
> To: Tomcat Users List
> Subject: Re: in web.xml
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jeff,
>
> On 4/24/13 2:22 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Jeffrey Janner
> >> [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, April 24,
> >> 2013 1:12 PM To: Tomcat Users List Subject: RE: in
> >> web.xml
> >>
> >>> -Original Message- From: Christopher Schultz
> >>> [mailto:ch...@christopherschultz.net] Sent: Wednesday, April 24,
> >>> 2013 12:28 PM To: Tomcat Users List Subject: Re:
> >>> in web.xml
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>>
> >>> Jeff,
> >>>
> >>> On 4/23/13 11:40 AM, Jeffrey Janner wrote:
> > -Original Message- From: Christopher Schultz
> > [mailto:ch...@christopherschultz.net] Sent: Thursday, April 18,
> > 2013 5:01 PM To: Tomcat Users List Subject: Re:
> > in web.xml
> >
> > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >
> > Jakub,
> >
> > On 4/17/13 9:22 PM, Jakub 1983 wrote:
> >> can I define database connection only in web.xml, without using
> >> context.xml files ?
> >>
> >> can I pass database url, login and password into
> ?
> >>
> >> when I define database conn in context.xml, resource-ref is not
> > needed
> >> at all, so what is it actually for ?
> >
> > If you define your database configuration in server.xml, you'll
> > have to map from global to local scope. You don't need to do this
> > with context.xml because the scope is -- by definition -- already
> >> local.
> >
> > - -chris
>
> Chris - Am I reading that correctly? If in my context.xml file, I
> define a DB resource as: type="oracle.ucp.jdbc.PoolDataSource"
> factory="oracle.ucp.jdbc.PoolDataSourceImpl"
> auth="Container"
> connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource"
> ... obviously redacted stuff ... /> I DO NOT need to add these
> lines to
> >>> my
> web.xml? Oracle Universal Connection
> Pool jdbc/oracleUCPPool
> javax.sql.DataSource
> Container
> >>>
> >>> I believe this is correct. It should be easy to try :)
> >>>
> That also brings up another, related, question. In my old web.xml,
> >> I
> had this entry:
> LOG4J_PROPS >> name>
> /WEB-INF/Log4j.properties
> Which I removed and replaced with an entry in the
> context.xml file: value="/WEB-INF/Log4j.properties" override="false" /> However,
> that
> didn't work. I had to provide the full path to the file in the
> >> value
> parameter. Is there a particular reason why?
> >>>
> >>> The two above are documented to be equivalent, assuming no other
> >>> factors are at work (e.g. Tomcat wasn't reading your new
> >>> META- INF/context.xml file because there was one already in
> >>> conf/[Engine]/[Host]/[app].xml.
> >>>
> >>> If it's not working, start a new thread to make sure you understand
> >>> how it's all supposed to work and possibly follow-up with a bug
> >> report.
> >>>
> Or would it be something inside our code?
> >>>
> >>> Tomcat doesn't use that value for anything, so it must be your code
> >>> reading it and interpreting it (hopefully using
> >>> ServletContext.getResource()).
> >>>
> >>> - -chris
> >>
> >> Actually, there is no META-INF file, we maintain the context.xml
> >> manually, since we multi-tenant and don't want to build
> >> tenant-specific wars. So it was definitely reading the latest
> >> version. Code uses context.getInitParameter("LOG4J_PROPS") which is
> >> passed directly to the log4j init routine (I think, still checking
> >> one reference).
> >
> > Yes, the returned string is passed unmolested to log4j's
> > PropertyConfigurator.
> >
> >> The error was being reported in the catalina logs and specifically
> >> mentioned the string in the error message. Simply switching to the
> >> FQPath did the trick.
>
> I wouldn't expect Tomcat to modify the value you were passing. Are you
> *sure* it was working in web.xml before you moved it into context.xml?
>
For the last 8 years or so.
> Using the fully-qualified path should pretty much always work, but if
> you know that the log4j configuration will be bundled as part of the
> web application, then you may as well make it context-relative. You
> should also use ServletContext.getResource and not read directly from
> the filesystem for a number of reasons.
>
> >> Of course, part of the reason for the change is that we'll be moving
> >> the file out of the WEB-INF directory in the future. Part of that
> >> multi-tenancy thing, so I'll be using FQPs in the future anyway. It
> >> was just a curiosity that expected behavior did not occur.
>
> Hmm. So, you'll be storing both context.xml *and* log4j.properties
> outside of the webapp?
Re: Tomcat 7.0.39 windows service setenv not used
Thanks!, so there is no other way to set these except to put in registry via tomcat7w.exe. On Wed, Apr 24, 2013 at 4:50 PM, Konstantin Kolinko wrote: > 2013/4/25 Satyendra Singh : > > I have created multiple windows services and for one of the service, i > have > > -Dcatalina.base=C:\servers\applications\service1 > > -Dcatalina.home=C:\servers\apache-tomcat-7.0.39 > > > > i have C:\servers\applications\service1\bin\setenv.bat where i have > > > > set JAVA_HOME= C:\ > > > > Set JAVA_OPTS=-D.. > > > > set CATALINA_OPTS=-Xms. > > > > running service1 does not seem to use these values, it only use those > that > > i can see at tomcat7w.exe on this service. > > > > > As documented, > [quote] > All the environment variables described here and the "setenv" script are > used only if you use the standard scripts to launch Tomcat. For example, if > you have installed Tomcat as a service on Windows, the service wrapper > launches Java directly and does not use the script files. > [/quote] > > http://tomcat.apache.org/tomcat-7.0-doc/RUNNING.txt > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Tomcat 7.0.39 windows service setenv not used
> From: Satyendra Singh [mailto:satya...@gmail.com] > Subject: Tomcat 7.0.39 windows service setenv not used > running service1 does not seem to use these values, it only use those that > i can see at tomcat7w.exe on this service. Services do not use _any_ .bat scripts, nor any environment variables. All properties must be configured in the tomcat7w.exe program associated with each service, which then stores the values in the Windows registry for use when the service is started. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
We're trying to bring up SSL in Tomcat on a customer AS/400 (an E4C at V7R1, using the /QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit JVM), and every time we launch CATALINA, we get SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"] Throwable occurred: java.net.BindException: The socket name is already in use. :443 Earlier today, I found something (I couldn't tell WHAT, because there were no jobs associated with the port) listening (and idle for 16 hours) on 443, on one of the IP addresses, but now, nothing on that port. I also looked for restrictions on that port, and there aren't any. Any ideas of where to look next? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.39 windows service setenv not used
2013/4/25 Satyendra Singh : > I have created multiple windows services and for one of the service, i have > -Dcatalina.base=C:\servers\applications\service1 > -Dcatalina.home=C:\servers\apache-tomcat-7.0.39 > > i have C:\servers\applications\service1\bin\setenv.bat where i have > > set JAVA_HOME= C:\ > > Set JAVA_OPTS=-D.. > > set CATALINA_OPTS=-Xms. > > running service1 does not seem to use these values, it only use those that > i can see at tomcat7w.exe on this service. > As documented, [quote] All the environment variables described here and the "setenv" script are used only if you use the standard scripts to launch Tomcat. For example, if you have installed Tomcat as a service on Windows, the service wrapper launches Java directly and does not use the script files. [/quote] http://tomcat.apache.org/tomcat-7.0-doc/RUNNING.txt - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.39 windows service setenv not used
I have created multiple windows services and for one of the service, i have -Dcatalina.base=C:\servers\applications\service1 -Dcatalina.home=C:\servers\apache-tomcat-7.0.39 i have C:\servers\applications\service1\bin\setenv.bat where i have set JAVA_HOME= C:\ Set JAVA_OPTS=-D.. set CATALINA_OPTS=-Xms. running service1 does not seem to use these values, it only use those that i can see at tomcat7w.exe on this service. any help would be appreciated. Thank You
Re: Question on servlet determination
2013/4/25 Christopher Schultz : > > Konstantin, > > On 4/24/13 3:56 PM, Konstantin Kolinko wrote: >> 2013/4/24 Christopher Schultz : >>> >>> On 4/23/13 11:35 PM, Caldarale, Charles R wrote: > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > Subject: Question on servlet determination > /Servlet1 > /Servlet2 What happens if you try this instead: /Servlet1/* /Servlet2/* >>> >>> While that should work, the original mapping should work, too. >>> The request for /Servlet1 (plus a slash on the end) should be >>> sent to Servlet1 with pathInfo="/". >>> >> >> No. An URL that does not end with "/*" is used for exact matching >> only. >> >> /foo and /foo/* are two different mappings. >> >> BTW, 1. in the examples webapp of Tomcat 6 and Tomcat 7 there is >> RequestInfoExample servlet that you can play around with. E.g. >> >> http://localhost:8080/examples/servlets/servlet/RequestInfoExample/foo/bar >> >> Adding an extra "/" works correctly. > > I notice that, although the is > "/servlets/servlet/RequestInfoExample/*", the trailing "/" is not > required in order to get the request mapped properly. That's > surprising to me given that "/foo" and "/foo/*" should be two > different mappings. > > I'm specifically looking at the examples in Tomcat 7.0.39. > No. With the following pattern requesting the "../foo/bar" URI above results in 404 for me. (In current 7.0.x, should not be different from 7.0.39). /servlets/servlet/RequestInfoExample >> Adding an extra "/" works correctly. My "adding" here is "adding to request URI in web browser", . http://localhost:8080/examples/servlets/servlet/RequestInfoExample http://localhost:8080/examples/servlets/servlet/RequestInfoExample/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question on servlet determination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 4/24/13 3:56 PM, Konstantin Kolinko wrote: > 2013/4/24 Christopher Schultz : >> >> On 4/23/13 11:35 PM, Caldarale, Charles R wrote: From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Subject: Question on servlet determination >>> /Servlet1 /Servlet2 >>> >>> What happens if you try this instead: >>> >>> /Servlet1/* >>> /Servlet2/* >> >> While that should work, the original mapping should work, too. >> The request for /Servlet1 (plus a slash on the end) should be >> sent to Servlet1 with pathInfo="/". >> > > No. An URL that does not end with "/*" is used for exact matching > only. > > /foo and /foo/* are two different mappings. > > BTW, 1. in the examples webapp of Tomcat 6 and Tomcat 7 there is > RequestInfoExample servlet that you can play around with. E.g. > > http://localhost:8080/examples/servlets/servlet/RequestInfoExample/foo/bar > > Adding an extra "/" works correctly. I notice that, although the is "/servlets/servlet/RequestInfoExample/*", the trailing "/" is not required in order to get the request mapped properly. That's surprising to me given that "/foo" and "/foo/*" should be two different mappings. I'm specifically looking at the examples in Tomcat 7.0.39. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReEIQAAoJEBzwKT+lPKRYtLUP/jdO4O/smOvVPL96PJdyk21T 4JPm7qFLk4dNHDnwr0NUwdeEoJBaKwmVSyTMrvLu1FbhUpaUv4jhQtgV5480k27e fnQhF4vwuyQaR1dOWb3j69m+soqukQHaU9TEVdl70i++gPrez6vra6mlc+FqOhXV r6/JSPucCHl8zvAeeNBqui5XY4hVgk7HeIO9ko8Jj8qjvLRpUhaaEHuqeL6lI14B MohH8CALTyRAvTRtsxmJZr/bb7w8nd274c1UkC/X93qBSNoIponck3SVYMaGFmxQ HzTCnfpIhX60xAOETh3ltbxzXG4/uyW/ay/WkAFst8uOvgXB5BclE4OAOHYHI13k opCGxg4vuP8ts9OcOTJG1UGa9cMTWwtHnUbbcvY76Y674nMfC45eP1CKXdTRD0AI sPPnARL6RRfcX7/jsVdF6I+rzKkjq+7mOQhYOJL02PgB/ccfS8ryHHxU5dWNRsmG OBcKnSHjtgesjb8nq2d35nOKTs9YCxdOoyrS44CGTWWzbEJb5SN/6JNdTYNfV5pJ 6hsUjdylhtnUixxs08QTqonNQJWEB6RjxWFU2neGgk1ytWpBsNMEARPb4CEWs1Do FVmBDeNsGOYVgW/DloSndUwtig8TP3z0uAsochLUx/8SJg4bkkzm9WP46Enzmog/ 3dazWAjtzWd8sy+2mtmS =c5IT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: in web.xml
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeff,
On 4/24/13 2:22 PM, Jeffrey Janner wrote:
>> -Original Message- From: Jeffrey Janner
>> [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, April 24,
>> 2013 1:12 PM To: Tomcat Users List Subject: RE: in
>> web.xml
>>
>>> -Original Message- From: Christopher Schultz
>>> [mailto:ch...@christopherschultz.net] Sent: Wednesday, April
>>> 24, 2013 12:28 PM To: Tomcat Users List Subject: Re:
>>> in web.xml
>>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> Jeff,
>>>
>>> On 4/23/13 11:40 AM, Jeffrey Janner wrote:
> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Thursday, April
> 18, 2013 5:01 PM To: Tomcat Users List Subject: Re:
> in web.xml
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>
> Jakub,
>
> On 4/17/13 9:22 PM, Jakub 1983 wrote:
>> can I define database connection only in web.xml, without
>> using context.xml files ?
>>
>> can I pass database url, login and password into
>> ?
>>
>> when I define database conn in context.xml, resource-ref
>> is not
> needed
>> at all, so what is it actually for ?
>
> If you define your database configuration in server.xml,
> you'll have to map from global to local scope. You don't
> need to do this with context.xml because the scope is -- by
> definition -- already
>> local.
>
> - -chris
Chris - Am I reading that correctly? If in my context.xml
file, I define a DB resource as: >>> name="jdbc/oracleUCPPool"
type="oracle.ucp.jdbc.PoolDataSource"
factory="oracle.ucp.jdbc.PoolDataSourceImpl"
auth="Container"
connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource"
... obviously redacted stuff ... /> I DO NOT need to add
these lines to
>>> my
web.xml? Oracle Universal
Connection Pool
jdbc/oracleUCPPool
javax.sql.DataSource
Container
>>>
>>> I believe this is correct. It should be easy to try :)
>>>
That also brings up another, related, question. In my old
web.xml,
>> I
had this entry:
LOG4J_PROPS> name>
/WEB-INF/Log4j.properties
Which I removed and replaced with an entry
in the context.xml file: >>> value="/WEB-INF/Log4j.properties" override="false" />
However, that didn't work. I had to provide the full path to
the file in the
>> value
parameter. Is there a particular reason why?
>>>
>>> The two above are documented to be equivalent, assuming no
>>> other factors are at work (e.g. Tomcat wasn't reading your new
>>> META- INF/context.xml file because there was one already in
>>> conf/[Engine]/[Host]/[app].xml.
>>>
>>> If it's not working, start a new thread to make sure you
>>> understand how it's all supposed to work and possibly follow-up
>>> with a bug
>> report.
>>>
Or would it be something inside our code?
>>>
>>> Tomcat doesn't use that value for anything, so it must be your
>>> code reading it and interpreting it (hopefully using
>>> ServletContext.getResource()).
>>>
>>> - -chris
>>
>> Actually, there is no META-INF file, we maintain the context.xml
>> manually, since we multi-tenant and don't want to build
>> tenant-specific wars. So it was definitely reading the latest
>> version. Code uses context.getInitParameter("LOG4J_PROPS") which
>> is passed directly to the log4j init routine (I think, still
>> checking one reference).
>
> Yes, the returned string is passed unmolested to log4j's
> PropertyConfigurator.
>
>> The error was being reported in the catalina logs and
>> specifically mentioned the string in the error message. Simply
>> switching to the FQPath did the trick.
I wouldn't expect Tomcat to modify the value you were passing. Are you
*sure* it was working in web.xml before you moved it into context.xml?
Using the fully-qualified path should pretty much always work, but if
you know that the log4j configuration will be bundled as part of the
web application, then you may as well make it context-relative. You
should also use ServletContext.getResource and not read directly from
the filesystem for a number of reasons.
>> Of course, part of the reason for the change is that we'll be
>> moving the file out of the WEB-INF directory in the future. Part
>> of that multi-tenancy thing, so I'll be using FQPs in the future
>> anyway. It was just a curiosity that expected behavior did not
>> occur.
Hmm. So, you'll be storing both context.xml *and* log4j.properties
outside of the webapp? Sounds like your deployments are going to
become more and more complex. Are you hosting your own webapp(s) on
your own servers? Or are you hosting clients' (potentially customized)
webapps on your servers? If you have full control, I'd put everything
possible into the webapp just for convenience.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
Re: Policy files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christian, On 4/24/13 1:51 PM, Christian Beikov wrote: > Yes we are talking about security manager policies. Good :) There's a lot about Spring that I don't know about, so I was just checking that you weren't talking about some crazy IoC thing or annotation-driven magic that no mere mortal can follow. > So there is no possibility to just push the policy file to the > WebappClassLoader? Nope: the SecurityManager applies to the whole JVM. But, the policy can bless certain JARs, etc. as being privileged. So, you make Tomcat and whatever code you wrote privileged and then leave all the student code to run under the heavy-handed security policy. > As stated in the reply to Matrin Gainty there do exist methods to > restrict the webapp, but unfortunately no method for supplying a > policy file. Right: you can control the deployment descriptor(s) but not really much else. > So this means I have to parse the policy file myself and add the > permissions manually to the classloader? Uh... I don't think that's possible. I must admit I'm no ClassLoader ninja, but I don't think there's a way to tell a ClassLoader anything about security policies. What kinds of operations are you trying to restrict? > Are there any options in the context.xml I could set for specifying > a webapp local policy so that I don't have to fiddle around with > how tomcat is called? I know how to apply a policy at runtime, but > don't know how this affects tomcat when I apply it e.g. in a > ServletContextListener. I think I'd have to understand more about what you are trying to do in order to be helpful. The SecurityManager applies its policies globally and you can't customize anything on a per-ClassLoader basis. You can do it on a per-codebase basis, but you have to know the URL(s) of the codebase(s) in advance. > Would be cool if there was an option to do that kind of stuff. Yes, I rather think it would be cool to specify a security policy on a per-ClassLoader basis, but there are definitely some thorny issues there otherwise I think Sun/Oracle would have implemented that capability by now. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReD6oAAoJEBzwKT+lPKRYDGAP/R9SjzcX0ENxQ5A7/N+S26M8 Jd5sNOisQ9mdVowygJAwppYDqtUalmMZ5qZTtsyYZYWKn3QpiML10Qr36elFZsA5 zoCA1JRB+hwC/vhNgJGdhhNxDOEQo66mfiJlfQ0rHpOGwVrGppAuSV4kVfX5aZCQ 9Ssq2HZvfLE7tL0pg+qnBT1AA9/HU+hAmk4GkCETSMR16jB8NrwI10ejU7gt1F4F BaUCULZvYtLRelbsAQTfz4ZOQL0FZq2zD85BeZ+hey0koinpr+nY1aRGy4ASbmrM Eke8ruYKW5xbVmSyQ0A4JmaYmMrYFfc7SgdR7UOkD21wbHA87fSHF9oNhhom2Tqd Qsdn89swuBwp6XkS1akbfRc6RJ4WPCxNfxBWceGWlJewtgY8XRD8lPYOsHCSiVN/ SOSVnmCaa8Fs6ygk75wo6IKI+VlLRJqFSK5pr1iGK9hVC+xgBGB5APrhMhvSCUmO SuP6IxFMSRDhghlxUbDhd7hW7KZnpXGQCJZjSoEsW/ysjhwy0hfhLbkEGTyYV8Az wCap5r3eHc5KsHP0FK9F283DbiUhV8oHoLK0ddzKd9KrHbxap4Vekk2tqbUA52Vn gpcRk5vodI88w0mvtdc9b57luHPedmY87bqmayjqzh6VHixlT/O8+CQhmJLRrln3 Wf6YgQg1Li6p//YLwHpo =TJPJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question on servlet determination
2013/4/24 Christopher Schultz : > > On 4/23/13 11:35 PM, Caldarale, Charles R wrote: >>> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] >>> Subject: Question on servlet determination >> >>> /Servlet1 >>> /Servlet2 >> >> What happens if you try this instead: >> >> /Servlet1/* >> /Servlet2/* > > While that should work, the original mapping should work, too. The > request for /Servlet1 (plus a slash on the end) should be sent to > Servlet1 with pathInfo="/". > No. An URL that does not end with "/*" is used for exact matching only. /foo and /foo/* are two different mappings. BTW, 1. in the examples webapp of Tomcat 6 and Tomcat 7 there is RequestInfoExample servlet that you can play around with. E.g. http://localhost:8080/examples/servlets/servlet/RequestInfoExample/foo/bar Adding an extra "/" works correctly. 2.Handling of welcome files in Tomcat 7 depends on "strict servlet compliance" setting (see Migration guide and system properties page in Configuration reference). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.33 manager - 403 Access Denied
2013/4/24 Shanti Suresh : > Hi Konstantin, > > On Tue, Apr 23, 2013 at 6:48 PM, Konstantin Kolinko > wrote: > >> >> > >> > I can't tell what I'm missing. Also, steps #2 and #3 are not even >> required >> > if I am using the RemoteAddrValve, correct? >> >> No. They are not related to RemoteAddrValve. >> > > Thanks! > > >> >> >> I would say that you should be stopped by CsrfPreventionFilter, >> because your heapused.jsp is not in the list of configured entry >> points. >> > > Bingo! > >> >> Shanti wrote: >> > The funny thing is that I gather the JMX metrics in an identical manner >> on >> > Tomcat 7.0.23 and JDK 1.6 on several other RedHat Linux servers. >> >> CVE-2012-4431 >> > > Thanks so much! > > I am now able to get heapused.jsp to work. I only had to add heapused.jsp > into web.xml. I did not need to add "/jmxroxy/". > > -manager/WEB-INF/web.xml:- > > CSRF > > org.apache.catalina.filters.CsrfPreventionFilter > > entryPoints > > /html,/html/,/html/list,/heapused.jsp,/index.jsp > > > > > curl http://localhost:6090/manager/heapused.jsp ==> gives me the value. > > One question I have though is that I have other JSP pages for gathering > other JMX metrics. I would like to not have to list these individually as > entry points. I tried to put these JSPs into a jmx/ sub-directory under > manager/. I added: "/jmx/*" both individually > as well as in conjunction with in web.xml. > > > CSRF > > org.apache.catalina.filters.CsrfPreventionFilter > > entryPoints > > /html,/html/,/html/list,/jmx/,/heapused.jsp,/index.jsp > > /jmx/* > > > But I got a 403 upon accessing: > > curl http://localhost:6090/manager/jmx/heapused.jsp > > The CSRF filter documentation did not mention "url-pattern": > http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html > > Is there a way to achieve what I'd like? > The source code is out there. You can subclass the filter, implement your own, or propose a patch. This feature was not needed, thus nobody implemented it. Alternatively, it is possible to change filter mapping so that it is not mapped to jsp servlet as a whole but to "/index.jsp" only (the only publicly callable jsp page there). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: in web.xml
> -Original Message-
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> Sent: Wednesday, April 24, 2013 1:12 PM
> To: Tomcat Users List
> Subject: RE: in web.xml
>
> > -Original Message-
> > From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > Sent: Wednesday, April 24, 2013 12:28 PM
> > To: Tomcat Users List
> > Subject: Re: in web.xml
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Jeff,
> >
> > On 4/23/13 11:40 AM, Jeffrey Janner wrote:
> > >> -Original Message- From: Christopher Schultz
> > >> [mailto:ch...@christopherschultz.net] Sent: Thursday, April 18,
> > >> 2013 5:01 PM To: Tomcat Users List Subject: Re: in
> > >> web.xml
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> > >>
> > >> Jakub,
> > >>
> > >> On 4/17/13 9:22 PM, Jakub 1983 wrote:
> > >>> can I define database connection only in web.xml, without using
> > >>> context.xml files ?
> > >>>
> > >>> can I pass database url, login and password into ?
> > >>>
> > >>> when I define database conn in context.xml, resource-ref is not
> > >> needed
> > >>> at all, so what is it actually for ?
> > >>
> > >> If you define your database configuration in server.xml, you'll
> > >> have to map from global to local scope. You don't need to do this
> > >> with context.xml because the scope is -- by definition -- already
> local.
> > >>
> > >> - -chris
> > >
> > > Chris - Am I reading that correctly? If in my context.xml file, I
> > > define a DB resource as: > > type="oracle.ucp.jdbc.PoolDataSource"
> > > factory="oracle.ucp.jdbc.PoolDataSourceImpl" auth="Container"
> > > connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource" ...
> > > obviously redacted stuff ... /> I DO NOT need to add these lines to
> > my
> > > web.xml? Oracle Universal Connection
> > > Pool jdbc/oracleUCPPool
> > > javax.sql.DataSource
> > > Container
> >
> > I believe this is correct. It should be easy to try :)
> >
> > > That also brings up another, related, question. In my old web.xml,
> I
> > > had this entry: LOG4J_PROPS name>
> > > /WEB-INF/Log4j.properties
> > > Which I removed and replaced with an entry in the
> > > context.xml file: > > value="/WEB-INF/Log4j.properties" override="false" /> However, that
> > > didn't work. I had to provide the full path to the file in the
> value
> > > parameter. Is there a particular reason why?
> >
> > The two above are documented to be equivalent, assuming no other
> > factors are at work (e.g. Tomcat wasn't reading your new META-
> > INF/context.xml file because there was one already in
> > conf/[Engine]/[Host]/[app].xml.
> >
> > If it's not working, start a new thread to make sure you understand
> > how it's all supposed to work and possibly follow-up with a bug
> report.
> >
> > > Or would it be something inside our code?
> >
> > Tomcat doesn't use that value for anything, so it must be your code
> > reading it and interpreting it (hopefully using
> > ServletContext.getResource()).
> >
> > - -chris
>
> Actually, there is no META-INF file, we maintain the context.xml
> manually, since we multi-tenant and don't want to build tenant-specific
> wars. So it was definitely reading the latest version.
> Code uses context.getInitParameter("LOG4J_PROPS") which is passed
> directly to the log4j init routine (I think, still checking one
> reference).
Yes, the returned string is passed unmolested to log4j's PropertyConfigurator.
> The error was being reported in the catalina logs and specifically
> mentioned the string in the error message. Simply switching to the
> FQPath did the trick.
> Of course, part of the reason for the change is that we'll be moving
> the file out of the WEB-INF directory in the future. Part of that
> multi-tenancy thing, so I'll be using FQPs in the future anyway. It
> was just a curosity that expected behavior did not occur.
> Jeff
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
On 24/04/2013 18:38, Rossen Stoyanchev wrote: - Original Message - From: "Mark Thomas" To: "Tomcat Users List" Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? Not that I am aware of which why I said "EG" rather than "specification". The JIRA ticket is about adding a "disconnect" callback but I can imagine in the very least, onComplete can be called. After the connection is over. onComplete should be called once the connection times out. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? My point was that if a disconnect event was added to the spec then the BIO connector could never be spec compliant. On reflection, it might not be that bad. The event could be fired just not when the client disconnects. It would have to wait until an attempt was made to read from / write to the socket. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: in web.xml
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, April 24, 2013 12:28 PM
> To: Tomcat Users List
> Subject: Re: in web.xml
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jeff,
>
> On 4/23/13 11:40 AM, Jeffrey Janner wrote:
> >> -Original Message- From: Christopher Schultz
> >> [mailto:ch...@christopherschultz.net] Sent: Thursday, April 18,
> >> 2013 5:01 PM To: Tomcat Users List Subject: Re: in
> >> web.xml
> >>
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >> Jakub,
> >>
> >> On 4/17/13 9:22 PM, Jakub 1983 wrote:
> >>> can I define database connection only in web.xml, without using
> >>> context.xml files ?
> >>>
> >>> can I pass database url, login and password into ?
> >>>
> >>> when I define database conn in context.xml, resource-ref is not
> >> needed
> >>> at all, so what is it actually for ?
> >>
> >> If you define your database configuration in server.xml, you'll have
> >> to map from global to local scope. You don't need to do this with
> >> context.xml because the scope is -- by definition -- already local.
> >>
> >> - -chris
> >
> > Chris - Am I reading that correctly? If in my context.xml file, I
> > define a DB resource as: > type="oracle.ucp.jdbc.PoolDataSource"
> > factory="oracle.ucp.jdbc.PoolDataSourceImpl" auth="Container"
> > connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource" ...
> > obviously redacted stuff ... /> I DO NOT need to add these lines to
> my
> > web.xml? Oracle Universal Connection
> > Pool jdbc/oracleUCPPool
> > javax.sql.DataSource
> > Container
>
> I believe this is correct. It should be easy to try :)
>
> > That also brings up another, related, question. In my old web.xml, I
> > had this entry: LOG4J_PROPS
> > /WEB-INF/Log4j.properties
> > Which I removed and replaced with an entry in the
> > context.xml file: > value="/WEB-INF/Log4j.properties" override="false" /> However, that
> > didn't work. I had to provide the full path to the file in the value
> > parameter. Is there a particular reason why?
>
> The two above are documented to be equivalent, assuming no other
> factors are at work (e.g. Tomcat wasn't reading your new META-
> INF/context.xml file because there was one already in
> conf/[Engine]/[Host]/[app].xml.
>
> If it's not working, start a new thread to make sure you understand how
> it's all supposed to work and possibly follow-up with a bug report.
>
> > Or would it be something inside our code?
>
> Tomcat doesn't use that value for anything, so it must be your code
> reading it and interpreting it (hopefully using
> ServletContext.getResource()).
>
> - -chris
Actually, there is no META-INF file, we maintain the context.xml manually,
since we multi-tenant and don't want to build tenant-specific wars. So it was
definitely reading the latest version.
Code uses context.getInitParameter("LOG4J_PROPS") which is passed directly to
the log4j init routine (I think, still checking one reference).
The error was being reported in the catalina logs and specifically mentioned
the string in the error message. Simply switching to the FQPath did the trick.
Of course, part of the reason for the change is that we'll be moving the file
out of the WEB-INF directory in the future. Part of that multi-tenancy thing,
so I'll be using FQPs in the future anyway. It was just a curosity that
expected behavior did not occur.
Jeff
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.33 manager - 403 Access Denied
Hi Konstantin, On Tue, Apr 23, 2013 at 6:48 PM, Konstantin Kolinko wrote: > > > > > I can't tell what I'm missing. Also, steps #2 and #3 are not even > required > > if I am using the RemoteAddrValve, correct? > > No. They are not related to RemoteAddrValve. > Thanks! > > > I would say that you should be stopped by CsrfPreventionFilter, > because your heapused.jsp is not in the list of configured entry > points. > Bingo! > > Shanti wrote: > > The funny thing is that I gather the JMX metrics in an identical manner > on > > Tomcat 7.0.23 and JDK 1.6 on several other RedHat Linux servers. > > CVE-2012-4431 > Thanks so much! I am now able to get heapused.jsp to work. I only had to add heapused.jsp into web.xml. I did not need to add "/jmxroxy/". -manager/WEB-INF/web.xml:- CSRF org.apache.catalina.filters.CsrfPreventionFilter entryPoints /html,/html/,/html/list,/heapused.jsp,/index.jsp curl http://localhost:6090/manager/heapused.jsp ==> gives me the value. One question I have though is that I have other JSP pages for gathering other JMX metrics. I would like to not have to list these individually as entry points. I tried to put these JSPs into a jmx/ sub-directory under manager/. I added: "/jmx/*" both individually as well as in conjunction with in web.xml. CSRF org.apache.catalina.filters.CsrfPreventionFilter entryPoints /html,/html/,/html/list,/jmx/,/heapused.jsp,/index.jsp /jmx/* But I got a 403 upon accessing: curl http://localhost:6090/manager/jmx/heapused.jsp The CSRF filter documentation did not mention "url-pattern": http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html Is there a way to achieve what I'd like? Thanks! -Shanti
Re: Policy files
Yes we are talking about security manager policies. So there is no possibility to just push the policy file to the WebappClassLoader? As stated in the reply to Matrin Gainty there do exist methods to restrict the webapp, but unfortunately no method for supplying a policy file. So this means I have to parse the policy file myself and add the permissions manually to the classloader? Are there any options in the context.xml I could set for specifying a webapp local policy so that I don't have to fiddle around with how tomcat is called? I know how to apply a policy at runtime, but don't know how this affects tomcat when I apply it e.g. in a ServletContextListener. Would be cool if there was an option to do that kind of stuff. Mit freundlichen Grüßen, *Christian Beikov* Am 24.04.2013 19:13, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christian, On 4/24/13 2:29 AM, Christian Beikov wrote: I am using tomcat as an embedded container for a while now, it is really amazing, but now I got stuck on a topic. I am implementing a testsuite for automatic testing of uploaded solutions by students. The deployment works like a charm, I also found your StuckThreadDetectionValve very useful to kill threads of the students applications. The next assignment will involve some areas where I would like to specify a policy file so that the students can't do anything they aren't supposed to. Now to my problem. Cool. One thing is that I want a policy file to be in the students projects, so that they actually get the exceptions when they are doing something wrong. What do I have to configure in these student web projects so that they can e.g. deploy the project directly from netbeans to tomcat and have the policy applied? I assume you are talking about SecurityManager policies. Unfortunately, the SecurityManager applies to the entire JVM, so you can't do something cool like allow one ClassLoader to run amok while classes loaded from another one are constrained. Instead, you can place limits on the entire JVM (e.g. no System.exit) and then poke holes in those protections for trusted content -- usually a specific JAR file, etc. If you are going to do that, you need to attempt privileged "actions" everywhere your driver code is going to do something that requires such privileges. If the student code tries to do something forbidden (e.g. System.exit), they'll get a SecurityException. If you try to do it without a privileged action, you'll also get an exception. The other thing is that I want the policy file to be in my testsuite project and configure it on demand when deploying the student solutions. Currently I create an instance of StandardContext for each student web application, then I configure the context and finally add it to the host of the server. What do I need to configure, to apply the policy in this case? You have to apply the policy when you launch the JVM via system properties on the command-line. Fortunately, all of your privileged code should be known in advance, so you shouldn't have to adjust anything for student-submitted code: all their stuff is limited by your policy. Remember that you have to give Tomcat all the privileges *it* needs as well as your own code. Check the catalina.policy file to see what privileges are necessary to properly run Tomcat under a SecurityManager. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBLUAAoJEBzwKT+lPKRYzOAP/iEB1IPyKjSSY/74IjYqR31G wzF6/HuEzwauYgdCxugxFhiogskUsHGnbgKtd4I0hGRtXwfLQf02c5foR6pV04F3 dy4ViYvXTvTLgM6YqcqDEClFigfJdRZdqb26bRUvbrSacTAgp6ifm2Tc7yBpkcR2 rWo0/zdCQTATHlryKnAtfpx0jngoXmyMxrNVH1efw36zN/C50zq26ri9VMG9vEcE TOy8w8lscj8PaCKj5e0skgvwKWjGrH4gplLOW07STK0Mtpb4rfSL5iua73CoaPsD PvnzlfgJsYWhlzWF6mExKlTDP+9UmC1195VSfVb3yPdSREf+Lk+PcpAIRnqj4Zma ZAQys1LcM5CUPzq4y6T4dokGDIXpwsBaphN7S4MKDp+vgb2W0Z6UbidjkUHiZ25r 1dPbt67f3Ro6gYRO/ggorc9y5/0yYs6xjaA9SuM7xvm4uGG4lEn092f6FBnd0+OZ 7t/6IylDSP5+CxCmXrPBu9TeJppq42biVz8VJaM+BJjlDKU6BIn+P2qPR/N1C2QK wR8aSbcxzKWekSkLv5VCnErCDbx+YekMWVfVfuQobQkMIha977cBHlqc+jhioG2g QIHaMAPA6JQMEQdSHrob98QirBI9FfZSDDdWQ/w9BuaAT3+bXXPKvUvgbLz14vN+ CLya7aynTMumUFHBnnv2 =MeqU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question on servlet determination
> -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, April 24, 2013 12:20 PM > To: Tomcat Users List > Subject: Re: Question on servlet determination > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jeff, > > On 4/23/13 5:45 PM, Jeffrey Janner wrote: > >> -Original Message- From: Propes, Barry L > >> [mailto:barry.l.pro...@citi.com] Sent: Tuesday, April 23, 2013 > >> 4:34 PM To: 'Tomcat Users List' Subject: RE: Question on servlet > >> determination > >> > >> I'm tempted to say no. > >> > >> Because you might be adding a "/" in front of your servlet mapping. > >> > >> In other words, changing the path of the folder slightly, with a > >> different relative path. > >> > > > > I went back and read the servlet spec for 2.5, and according to it, > > Tomcat should be redirecting the URI ending "/Servlet2" to > > "/Servlet2/" and then applying welcome files (I do have some defined, > > just didn't include it below). Amazingly, this appears to be what > > happens. However, if the ending "/" already exists, it doesn't just > > go looking for welcome files. > > If you have a servlet mapped to /Servlet1 (and /Servlet2), why should > there be any redirecting at all? That should only happen if the > DefaultServlet is handling the request and /Servlet1 refers to a > directory (or something that looks like one). > > - -chris I was specifically using the terminology in the 2.5 spec. To quote from page 72, the section on Welcome Files: Consider a Web application where: • The deployment descriptor lists the following welcome files. index.html default.jsp • The static content in the WAR is as follows /foo/index.html /foo/default.jsp /foo/orderform.html /foo/home.gif /catalog/default.jsp /catalog/products/shop.jsp /catalog/products/register.jsp • A request URI of /foo will be redirected to a URI of /foo/. • A request URI of /foo/ will be returned as /foo/index.html. • A request URI of /catalog will be redirected to a URI of /catalog/. • A request URI of /catalog/ will be returned as /catalog/default.jsp. • A request URI of /catalog/index.html will cause a 404 not found • A request URI of /catalog/products will be redirected to a URI of / catalog/products/. • A request URI of /catalog/products/ will be passed to the “default” servlet, if any. If no “default” servlet is mapped, the request may cause a 404 not found, may cause a directory listing including shop.jsp and register.jsp, or may cause other behavior defined by the container. See Section SRV.11.2, “Specification of Mappings” for the definition of “default” servlet. But then, I could have been interpreting that incorrectly, since I think it's referring to requests into directories, not Servlets. The more I think about it, the more I'm sure it's our code. There are no directories that match the servlet names. Tomcat is correctly matching the servlet name, and passing the rest of the request string to the servlet, null in the first case, and "/" in the second. Our code assumes a null string means put up a specific page but doesn't know what to do with a "/" (have not researched, but probable). It's not really relying on the welcome-list at all. That makes even more sense when you understand that both servlets have the same document base (the Web directory), and both welcome files are in that directory, yet each servlet manages to put up the servlet-specific welcome file. Does that start to make sense, Chris? Jeff
Fwd: Re: Policy files
Accidently mailed on tomee-list before >< Thanks for the quick answer but it seems I didn't explain my situation completely. We use Maven for all assignments, I can control what base project they have to use for a specific assignment. Also in my testsuite I automatically build these projects and deploy the artifacts to my embedded tomcat. The problem is when it comes to the policy files. Where do I need to add the path to the policy file for the base maven projects of the students? Is there any option in context.xml or so that I can use? The second problem is that I want to configure the policy for each student project when deploying on embedded tomcat(since the students could change the file in their projects). Where do I have to configure the policy when instantiating the StandardContext myself? I saw that the Loader of the context is of the type WebappLoader and the ClassLoader is a WebappClassLoader. I also found a method addPermission in WebappClassLoader, but I don't want to parse the policy file myself and add the permissions one by one. Isn't there an attribute to set the policy for that class loader? So to summarize it a bit, I want to know what to configure in e.g. context.xml(if that is the place where to configure the policy) to have a specific policy applied. Mit freundlichen Grüßen, *Christian Beikov* Am 24.04.2013 12:48, schrieb Martin Gainty: Sooner or later your students will need to stop playing with IDEs and get serious about creating a real war Maven provides maven-war-plugin for creating deployable web archives as far as applying differing policies (or configurations) you can use archetypes for initial creation of the war http://www.sonatype.com/books/mvnex-book/reference/web-sect-creating-project.html properties for deployment configuration changes can be manipulated by passing attributes to MANIFEST.MF bash>mvn Dmaven.war.containerConfigXML=MYContextXML.xml org.apache.maven.plugins:maven-war-plugin:2.3:manifest http://maven.apache.org/plugins/maven-war-plugin/manifest-mojo.html#containerConfigXML bash>mvn org.apache.maven.plugins:maven-war-plugin:2.3:war the first command copies to META-INF your customised MYContextXML.xml (context) the second command builds out the war in \target folder http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html *Viel Gluck* Martin __ Thank the general and tell him I have no desire to drink with him or any other Russian *** ** * * General George Patton > Date: Wed, 24 Apr 2013 08:29:27 +0200 > From: christian.bei...@gmail.com > To: users@tomcat.apache.org > Subject: Policy files > > Hello there! > > I am using tomcat as an embedded container for a while now, it is really > amazing, but now I got stuck on a topic. > I am implementing a testsuite for automatic testing of uploaded > solutions by students. The deployment works like a charm, I also found > your StuckThreadDetectionValve very useful to kill threads of the > students applications. > The next assignment will involve some areas where I would like to > specify a policy file so that the students can't do anything they aren't > supposed to. Now to my problem. > > One thing is that I want a policy file to be in the students projects, > so that they actually get the exceptions when they are doing something > wrong. What do I have to configure in these student web projects so that > they can e.g. deploy the project directly from netbeans to tomcat and > have the policy applied? > > The other thing is that I want the policy file to be in my testsuite > project and configure it on demand when deploying the student solutions. > Currently I create an instance of StandardContext for each student web > application, then I configure the context and finally add it to the host > of the server. What do I need to configure, to apply the policy in this > case? > > I hope someone can help me with that, thanks in advance! > -- > > Mit freundlichen Grüßen, > > *Christian Beikov*
Re: AsyncListener.onError and disconnected client
- Original Message - > From: "Mark Thomas" > To: "Tomcat Users List" > Sent: Wednesday, April 24, 2013 12:47:54 PM > Subject: Re: AsyncListener.onError and disconnected client > > On 24/04/2013 16:33, Rossen Stoyanchev wrote: > > Hi, > > > > I've seen various discussions here and on the web but I haven't > > found > > a conclusive answer. Why does an AsyncListener not receive onError > > notifications when a client disconnects? > > Because the Servlet EG says that is the required behaviour. The EG is > currently revisiting that decision. See > https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? The JIRA ticket is about adding a "disconnect" callback but I can imagine in the very least, onComplete can be called. After the connection is over. > > To my knowledge there is nothing inherent in NIO and TCP that > > prevents the server from detecting that the client has > > disconnected. > > The WebSocket implementation detects disconnected clients > > immediately > > and other HTTP servers (e.g. node) seem to be able to do this. What > > is it about the Servlet async support that prevents it from knowing > > when a client has disconnected? > > It would mean having to ditch the BIO connector / or not being able > to pass the TCK (assuming the TCK tested this) when using the BIO > connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? > Not sure about APR/native. I'd need to look at the docs and probably > run some tests. Thanks, Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: in web.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, On 4/23/13 11:40 AM, Jeffrey Janner wrote: >> -Original Message- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Thursday, April 18, >> 2013 5:01 PM To: Tomcat Users List Subject: Re: in >> web.xml >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Jakub, >> >> On 4/17/13 9:22 PM, Jakub 1983 wrote: >>> can I define database connection only in web.xml, without >>> using context.xml files ? >>> >>> can I pass database url, login and password into >>> ? >>> >>> when I define database conn in context.xml, resource-ref is >>> not >> needed >>> at all, so what is it actually for ? >> >> If you define your database configuration in server.xml, you'll >> have to map from global to local scope. You don't need to do this >> with context.xml because the scope is -- by definition -- already >> local. >> >> - -chris > > Chris - Am I reading that correctly? If in my context.xml file, I > define a DB resource as: type="oracle.ucp.jdbc.PoolDataSource" > factory="oracle.ucp.jdbc.PoolDataSourceImpl" auth="Container" > connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource" ... > obviously redacted stuff ... /> I DO NOT need to add these lines to > my web.xml? Oracle Universal Connection > Pool jdbc/oracleUCPPool > javax.sql.DataSource > Container I believe this is correct. It should be easy to try :) > That also brings up another, related, question. In my old web.xml, > I had this entry: > LOG4J_PROPS > /WEB-INF/Log4j.properties > Which I removed and replaced with an entry in the > context.xml file: value="/WEB-INF/Log4j.properties" override="false" /> However, that > didn't work. I had to provide the full path to the file in the > value parameter. Is there a particular reason why? The two above are documented to be equivalent, assuming no other factors are at work (e.g. Tomcat wasn't reading your new META-INF/context.xml file because there was one already in conf/[Engine]/[Host]/[app].xml. If it's not working, start a new thread to make sure you understand how it's all supposed to work and possibly follow-up with a bug report. > Or would it be something inside our code? Tomcat doesn't use that value for anything, so it must be your code reading it and interpreting it (hopefully using ServletContext.getResource()). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBYiAAoJEBzwKT+lPKRYsTwQAIx2p8gxjFKeeOnVx/UewP5O nOAtrYovqbVCwC13P5hgrFPqjvmFtsGcCOeqJuij1GZODIg9OU4Z6Vs5pUISaiDC p1CFaYEL0PxBtl7wr7KC4A7k7WNnpxCnYauhgOWMR1xJXeXz40Hux32HCK9mNkhL RP5BYpJqXuO6L53U5lUhA/o0rgKoJVttRt+oqn1tPMBxatZU4MRUrt88zuEk+3va eQJfGZ05aQv+I6wRQDooQvAtbvhal7vnIx3PBMs40GG1shjkRy9jCz5b4o5BJCuv bAeeB73Dv/APXs/a4/6fVfzv/wq8l7nxRCod1xYga8q/4o39oJKrJmlVgyTOgbOS h04raAVhys95pQa8BLfSWr65Vh6wdAufduocS3sL75M09AouUUu4APB0Yt6JrMIH 3z7bbAN4kLXZ+4NfcvYbJtLNh+jFNwbf/B+ZsjXS/t0OUemZ0JXHPN3SvI0mLHPI NoIgaAi6skAGotYSIXL4Lvr8J9UCuFZZBXb1r7L2tvWyMaMI92Uy2AuYFK3Jdn7E 0p1R8ABhznuN3gbT5pOSiGqNolAeiOAnCMhzQLCJk9LD9srUB/Y1K5H3KQzX9RMa uralof0w70G3k6bZCVTy3gq726c7D7b//7WtzEHm/bfQK3RIb/E9Ete7b0Loposi ZwTpY6etPPckA6gsXRa0 =rAMP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question on servlet determination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 4/23/13 11:35 PM, Caldarale, Charles R wrote: >> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] >> Subject: Question on servlet determination > >> /Servlet1 >> /Servlet2 > > What happens if you try this instead: > > /Servlet1/* > /Servlet2/* While that should work, the original mapping should work, too. The request for /Servlet1 (plus a slash on the end) should be sent to Servlet1 with pathInfo="/". - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBS1AAoJEBzwKT+lPKRYmUEQALFahIXLw0D5N4hPQ+KmWHsv MxERJGJCMVD8QAc7EXK1FatSauRiy1cB13Ae5SVRdIvlwC1nbQLgTA9bDrVZHX/R Ut8LvWlxPCTfihOPOQpPN4upGWOM7VyC4uDo6pXXF70TiBAvL1JuRVQvoBkF8u4X 2m0biF8qEa8gJXeWf0+m7GgbC7ytLQLQa/l5LGeBwnMq5gbvjP9QrbNr517PQhp4 dsDnP72feP0HP5nk3tVtLuPab3Gz7zwWY1kbW/8UsBNchioBIvkCDzBfK1WcJaYi F2JdA0NsbssR02jy/i+L+RlXtvuyUR2SlfLIwIg/vaCMUA3bjLfHW0QFB7P6/Qjc +cTgckryIDzU1tI+eyALDn5pcKoR/agl1N7EU3kAQ7L9Al+ONnTkE18lHDnoBHtc q7LWS5GXDDqvZO/iA713d+xGYgDm+W6SYXLhErK8N7P+ze0hI2/l4gKV0aBtLT5e gOa+tFrQEJDiHg/RE4N0l4hKhZFJ4kp+/cE/Q59ul4FFTuJhUf574sPBDq2aRcv4 q0degEfLxnfFtP1oxwjpviAfdN2ZccBpHTlwZ4CL5kQ2K7d5y7G96ldQSEeJksrS HDDNfohwQVJN62Wo29Ld3W7zJ0v5xgLDn+E6aJq+zldBjRu8iTlnli20nWTHnVRq apntFNgcpDZCpWXoWLuj =GhL+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question on servlet determination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, On 4/23/13 5:45 PM, Jeffrey Janner wrote: >> -Original Message- From: Propes, Barry L >> [mailto:barry.l.pro...@citi.com] Sent: Tuesday, April 23, 2013 >> 4:34 PM To: 'Tomcat Users List' Subject: RE: Question on servlet >> determination >> >> I'm tempted to say no. >> >> Because you might be adding a "/" in front of your servlet >> mapping. >> >> In other words, changing the path of the folder slightly, with a >> different relative path. >> > > I went back and read the servlet spec for 2.5, and according to > it, Tomcat should be redirecting the URI ending "/Servlet2" to > "/Servlet2/" and then applying welcome files (I do have some > defined, just didn't include it below). Amazingly, this appears to > be what happens. However, if the ending "/" already exists, it > doesn't just go looking for welcome files. If you have a servlet mapped to /Servlet1 (and /Servlet2), why should there be any redirecting at all? That should only happen if the DefaultServlet is handling the request and /Servlet1 refers to a directory (or something that looks like one). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBQ/AAoJEBzwKT+lPKRYnVUP/A32hsNrCKupzCtQSHeolP9X WsWWP7Vy1svMG/9aFPbbvMmpV4YPDp+lxUy615q2jiP7o5Ys/Ovu5SemCqoZRhYh 1Aj/vgESnUQtQDCQwny7XUMErWkWsC8C6TWpQ+SNoD+iQlNnXgArztQS2Ufl0rRX h4FjF+/6R8+mcfPUlpOmSOwFl45DjQEocOuWdfYewtlZkzNu0dZxZ7S10RBq0ATu loaMKC/dFvgSa/vqf5wwVW69zqlMVVh0/y7JFgN71zyv7i2VJCGqDHEPPBEFV5/O el4b5Q3wjb6Bk99sv4sDOyC85eUcN0SaDkb9ygTkkuamI3sdZxl06ej/AJU/TIOn 5bLBn89N8DKqLu6t7qI5M4yQ+dqGx6SmqGtGgG71+MoJ+BpcmQKciJf9wC2kh6nA JYdOXxRb7297guzZxL9gw7uz9asVV7TVWH1SHm2jzXkxaezu2OXpWX3FRocQU66q +/PlH0gry9bjGyWfM6KKAb1rRRYKF6r5NxKMjDVKIwPIYmPpeFeSZ78koGAMhruS k+T0N/iTQ8nLsM0qBkiMffZv8Mgr1AMygP0v7NB407S0q4HF28y5v5ZpwqnRU1Cu fgO76UgnHYkZkegO3pQkwfzzIIO9HoPxk2pqKTzi9ttgI9QXeVvWJxcj65SSjshL 71xkuFIhbmh/9Pc5AlW4 =c7ZG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Policy files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christian, On 4/24/13 2:29 AM, Christian Beikov wrote: > I am using tomcat as an embedded container for a while now, it is > really amazing, but now I got stuck on a topic. I am implementing a > testsuite for automatic testing of uploaded solutions by students. > The deployment works like a charm, I also found your > StuckThreadDetectionValve very useful to kill threads of the > students applications. The next assignment will involve some areas > where I would like to specify a policy file so that the students > can't do anything they aren't supposed to. Now to my problem. Cool. > One thing is that I want a policy file to be in the students > projects, so that they actually get the exceptions when they are > doing something wrong. What do I have to configure in these student > web projects so that they can e.g. deploy the project directly from > netbeans to tomcat and have the policy applied? I assume you are talking about SecurityManager policies. Unfortunately, the SecurityManager applies to the entire JVM, so you can't do something cool like allow one ClassLoader to run amok while classes loaded from another one are constrained. Instead, you can place limits on the entire JVM (e.g. no System.exit) and then poke holes in those protections for trusted content -- usually a specific JAR file, etc. If you are going to do that, you need to attempt privileged "actions" everywhere your driver code is going to do something that requires such privileges. If the student code tries to do something forbidden (e.g. System.exit), they'll get a SecurityException. If you try to do it without a privileged action, you'll also get an exception. > The other thing is that I want the policy file to be in my > testsuite project and configure it on demand when deploying the > student solutions. Currently I create an instance of > StandardContext for each student web application, then I configure > the context and finally add it to the host of the server. What do I > need to configure, to apply the policy in this case? You have to apply the policy when you launch the JVM via system properties on the command-line. Fortunately, all of your privileged code should be known in advance, so you shouldn't have to adjust anything for student-submitted code: all their stuff is limited by your policy. Remember that you have to give Tomcat all the privileges *it* needs as well as your own code. Check the catalina.policy file to see what privileges are necessary to properly run Tomcat under a SecurityManager. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBLUAAoJEBzwKT+lPKRYzOAP/iEB1IPyKjSSY/74IjYqR31G wzF6/HuEzwauYgdCxugxFhiogskUsHGnbgKtd4I0hGRtXwfLQf02c5foR6pV04F3 dy4ViYvXTvTLgM6YqcqDEClFigfJdRZdqb26bRUvbrSacTAgp6ifm2Tc7yBpkcR2 rWo0/zdCQTATHlryKnAtfpx0jngoXmyMxrNVH1efw36zN/C50zq26ri9VMG9vEcE TOy8w8lscj8PaCKj5e0skgvwKWjGrH4gplLOW07STK0Mtpb4rfSL5iua73CoaPsD PvnzlfgJsYWhlzWF6mExKlTDP+9UmC1195VSfVb3yPdSREf+Lk+PcpAIRnqj4Zma ZAQys1LcM5CUPzq4y6T4dokGDIXpwsBaphN7S4MKDp+vgb2W0Z6UbidjkUHiZ25r 1dPbt67f3Ro6gYRO/ggorc9y5/0yYs6xjaA9SuM7xvm4uGG4lEn092f6FBnd0+OZ 7t/6IylDSP5+CxCmXrPBu9TeJppq42biVz8VJaM+BJjlDKU6BIn+P2qPR/N1C2QK wR8aSbcxzKWekSkLv5VCnErCDbx+YekMWVfVfuQobQkMIha977cBHlqc+jhioG2g QIHaMAPA6JQMEQdSHrob98QirBI9FfZSDDdWQ/w9BuaAT3+bXXPKvUvgbLz14vN+ CLya7aynTMumUFHBnnv2 =MeqU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question regarding tomcat upgrade from 7.0.23. to 7.0.37
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Madhu, On 4/24/13 1:33 AM, Madhu Purohit wrote: > Hi We have recently upgraded tomcat fom 7.0.23 to 7.037 and also > Java from 1.6.0_21 to 1.7.0_15. When we run the load runner > testcases we get the following error > > “content was blocked because it was not signed by a valid > certificate” This is not an error message I recognize from Tomcat: it must be coming from your load runner test cases (or from load runner itself). > But other normal browser testing goes through. Do we need to > install new certificates? What kind of certificates are you using? > There has been no change in the code of our application. With > tomcat 7.0.23 we do not get this error. Appreciate your inputs > regarding why we are getting this error. If you installed a new version of Tomcat and your SSL certificates were in a keystore somewhere Tomcat-version-specific (like in CATALINA_HOME instead of CATALINA_BASE), then you may not have set up your keystore properly. I'm not even sure if you are talking about SSL certificates, but that's the only kind of certificate Tomcat handles, so I figured I'd mention it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBFeAAoJEBzwKT+lPKRYmmAQAJZUiB37EtGkDMNAwbQbwALr WNAP5NxxjhRAk4nqtGG+vjt6RbEyyrUerHBhqubKvWpPdmYG6wHHw6xUQBYxwjB9 c6XGqvOT0S9vVfeKOtmgRTFF4MPWwv1mh6DuUMJlTX+ORYJEmr9JczQcyMRn61zM xP4QwpMljRsFeAcLV0HN4bcLYx8ly8u7B6Bs0Idp/bd7W2GKgq9EQT8s12KjJtXI JyVOSFOCC0tCW9iVP7S2p1mdbaDGLs5t3fEqREF5I7fozWCi8zox3+P6M09eE9FN R4p9REX1awtuczoE4mb7vyByPmJUTTFHzEIqPZUwxbTPvfhOVIaRKCxIKxGM/qru LtNpJayb0UaywFGJyONycIXd5TueKqKDnacrwB/FmJsKZMLV1ZEecmrb9z8YDKz7 Iys+zqYgANWW9ZQ/8qKCz3CXZSOjwaBEOAZE9zYsCebE9B7XDvMPE4XIiZEixoql 5vHNMLfeldfb1KbfUgY5kQX+zrx1mAFbpi4vi8GXH8mQqqpMFCFHoJlK9dUAEAlp CoR4mzD1BcQVEb4KK18I5WnlWqDdkS93Q6G3WKR1xvTCvec7wqAuS6+uhR0WH1yq GcTHkQ+aWwKTkB7H4Hd4RksrIZKS6CdU1gymjEJJswdXO76IQ18uw31eeGJpwFXC 7GPO6tlWyMWynIg0OUn6 =mSQ7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: two responses from one request - how is it possible ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/23/13 11:24 AM, Jeffrey Janner wrote: >> -Original Message- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Monday, April 22, >> 2013 4:31 PM To: Tomcat Users List Subject: Re: two responses >> from one request - how is it possible ? >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Jeffrey, >> >> On 4/22/13 4:18 PM, Jeffrey Janner wrote: >>> >>> -Original Message- From: André Warnier [mailto:aw@ice- >> sa.com] Sent: Sunday, April 21, 2013 7:03 PM To: Tomcat Users List Subject: Re: two responses from one request - how is it possible ? Jakub 1983 wrote: > http://www.mulesoft.com/tomcat-connector states: > > Using the current arrangement, both Connectors will pass > all requests to the same Engine, which will in turn pass > all these requests to both > of its contained web applications. This means that each > request will potentially generate two responses, one from > each application. port="8443"/> > port="8444"/> > path="/webapp1"/> > > > Is it really true what they write ? > (For anyone else reading this, I did look at the indicated webpage, and it is really what they say there) To me, it sounds like utter nonsense. Or else, I need to revise my whole understamding of HTTP and Tomcat. It even looks like nonsense squared, since : - each request is sent by one client on one connection to one port (meaning one Tomcat Connector), and the (single) response to that request will also come back on that same connection - each request should have a target URL (like /webapp1 OR /webapp2, but not both), and will be processed (once) by the application (context) corresponding to that URL, and will generate only one response Maybe we should ask the author of that page for more details. He >> may have invented the amplifier version of Tomcat. Additionally, it is really bad practice to put elements in the server.xml file. >>> From the article: >>> " Using the current arrangement, both Connectors will pass all >>> requests to the same Engine, which will in turn pass all these >>> requests to both of its contained web applications. This means >>> that each request will potentially generate two responses, one >>> from each application." >>> >>> Well, after noting some of the bad grammar in the opening few >>> paragraphs (listen to vs. listen on), I was going to give the >>> author >> a >>> pass on the use of "both" in the first sentence, instead of >>> "either" or "one of". But then he goes onto the second >>> sentence and proves that he meant both. >>> >>> In actuality, he should have stopped the first sentence at >>> "Engine", and then continued with a new sentence (keeping in >>> mind the >> simplified >>> structure): "The Engine will then see if the first string after >>> the hostname portion of the request URL matches any of the >>> defined contexts. If a match is found, then the request is >>> passed to that context and the response is sent back via the >>> original connector. If a match is not found, then an error is >>> returned." >>> >>> Of course, after reading the original, I now understand why I >>> was never tempted to even try this company's version of Tomcat, >>> despite the number of times they've promoted themselves on the >>> list. >> >> Jason Brittain used to work at MuleSoft: they /are/ legit, though >> this particular post seems to require some serious editing, or >> even deletion. >> >> - -chris > > OH, I was never worried about /legit/ status, but this page and > others probably made me skeptical on the quality issue. You know, > first impressions and all. Wouldn't mind hearing from some who > found reason to use their product over standard release. We use Mirth Connect which is a product bundled with Mule ESB. They have moved away from Mule for their upcoming product version, but I think that was more because they simply didn't need everything Mule was providing (kind of like discovering that Tomcat will work when you started out with Weblogic). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReBALAAoJEBzwKT+lPKRY/coP/R1jQxUOEZlN+ueK5tEUa70V pb5poHBodRXtwfX3GJF0pS95igYQIzVMhi95BVO13eQnYxqbwoN+MAxdDaDfh+mU ySOml1eUh7Zb0v2U60ZDtHcCBqGV6K34zptDevzzEMXZ1ansoIpBEXkt57oGB2BB 7fZs0ShRe1N4AiBIpq0k0zbfV90W6HRkgfjHZalCbP1ZuBWZ7YKbo2bJk1Z1R7J5 ynur/pLGNZfWpZ13VFME8i5yw8GoRYPmQHkp2scE5oTyfH6p6LIjOhWmTJ3QLgVq 1HFT7dbfoqhp/BPv4tyChr70q+BwfT2oKs/8f5ssCOVKOophmDdBBGUZ5+aaFxyt gozjgVcHKmzq7E5++MarhkeyVCN9/ub0wC+2qnCCcI8k2xfFBg3zOHu3iN65Q5X+ VjhKF6LT4JmpWQlkwQE2Q2k0xEOCVvMycFj/kH8qvTDQ9oTo2iFP
Re: AsyncListener.onError and disconnected client
On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. Not sure about APR/native. I'd need to look at the docs and probably run some tests. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Hi Katy, On 24.04.2013 16:38, Beavers, Melinda K (Kay) wrote: > Rainer, thank you for that link!! I have put this line in my > isapi_redirect.properties file: > "rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties" and put my > rewrite.properties file in place with just a single line in it: > "/apps/cepv/website/=/website/" and reset IIS. It is not working but in the > debug log I never see any reference to using the rewrite file. > > I never see entries like described below: > > "During startup, you should see > > Using rewrite rule file YOURRULESFILE > > in the log file, and later > > Loaded rewrite rule file YOURRULESFILE > > Between those two, you should also see lines indicating, that the > contents of the file got parsed." > > Do you know if there's some other step I'm missing or if it has to be a > certain version in order to recognize the rewrite file? First: which version are you using? Then: I assume we already know that your entries to isapi_redirect.properties work in principle, i.e. that you can confirm that some of the entries did work, just not the rewrite_rule_file entry. Correct? Next I assume you could correctly set a log file using the log_file entry and that you can now set the log level to "debug" using log_level=debug. When you now start up, you should get a couple of log lines containing the word "Using". Post at least them or even better all startup log messages, excluding any confidential stuff. Regards, Rainer > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Wednesday, April 24, 2013 2:03 AM > To: users@tomcat.apache.org > Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL > paths are different > > On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: >> We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 >> server so that http://iis.company.com/website/myfile.jsp will correctly >> redirect according to our 'isapi_redirect.properties', 'workers.properties', >> and 'uriworkermap.properties ' and serve the JSP page from >> http://tomcat.company.com/website/myfile.jsp . That appears to be working >> just fine. But we actually need to have a different IIS URL. What we are >> trying to figure out is if we can configure it so that >> http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve >> the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on >> the IIS server is has two extra levels (/apps/cepv) in the URL path and does >> not match the path on the tomcat server where the JSP content is. We have to >> have those two extra levels in the IIS URL path for other technical reasons >> and we cannot match or include those two extra levels on the tomcat side. >> >> We have tried the following but cannot get it to work. >> >> website.worker=website_ajp13 >> /apps/cepv/website/*.jsp=$(website.worker) >> >> Is there anything we can do to map this correctly? > > Have a look at > > https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting > > starting from "If you are using Microsoft IIS as a web server...". > > Regards, > > Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Beavers, Melinda K (Kay) wrote: Rainer, thank you for that link!! I have put this line in my isapi_redirect.properties file: "rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties" and put my rewrite.properties file in place with just a single line in it: "/apps/cepv/website/=/website/" and reset IIS. It is not working but in the debug log I never see any reference to using the rewrite file. I never see entries like described below: "During startup, you should see Using rewrite rule file YOURRULESFILE in the log file, and later Loaded rewrite rule file YOURRULESFILE Between those two, you should also see lines indicating, that the contents of the file got parsed." Do you know if there's some other step I'm missing or if it has to be a certain version in order to recognize the rewrite file? Regards, Katy -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Wednesday, April 24, 2013 2:03 AM To: users@tomcat.apache.org Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from "If you are using Microsoft IIS as a web server...". Melinda, in addition to what Rainer writes above, and if you determine later that you need more powerful URL-rewriting capabilities under IIS later, have a look at : http://www.helicontech.com/isapi_rewrite/ Also, on this list, try to not "top-post" your reponses, it makes it more difficult for everyone to follow the conversation (scrolling up and down etc..) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AsyncListener.onError and disconnected client
Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? The scenario is that async processing starts (via request.startAsync), the Servlet container thread is exited, and then at some point before the async request completes, the client goes away (e.g. browser tab is closed). The only way I've found to detect the client has gone away is to write to and flush the servlet response buffer. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? Thanks, Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
Rainer, thank you for that link!! I have put this line in my isapi_redirect.properties file: "rewrite_rule_file=C:\Avaya\TomcatFilter\rewrite.properties" and put my rewrite.properties file in place with just a single line in it: "/apps/cepv/website/=/website/" and reset IIS. It is not working but in the debug log I never see any reference to using the rewrite file. I never see entries like described below: "During startup, you should see Using rewrite rule file YOURRULESFILE in the log file, and later Loaded rewrite rule file YOURRULESFILE Between those two, you should also see lines indicating, that the contents of the file got parsed." Do you know if there's some other step I'm missing or if it has to be a certain version in order to recognize the rewrite file? Regards, Katy -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Wednesday, April 24, 2013 2:03 AM To: users@tomcat.apache.org Subject: Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: > We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 > server so that http://iis.company.com/website/myfile.jsp will correctly > redirect according to our 'isapi_redirect.properties', 'workers.properties', > and 'uriworkermap.properties ' and serve the JSP page from > http://tomcat.company.com/website/myfile.jsp . That appears to be working > just fine. But we actually need to have a different IIS URL. What we are > trying to figure out is if we can configure it so that > http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve > the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on > the IIS server is has two extra levels (/apps/cepv) in the URL path and does > not match the path on the tomcat server where the JSP content is. We have to > have those two extra levels in the IIS URL path for other technical reasons > and we cannot match or include those two extra levels on the tomcat side. > > We have tried the following but cannot get it to work. > > website.worker=website_ajp13 > /apps/cepv/website/*.jsp=$(website.worker) > > Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from "If you are using Microsoft IIS as a web server...". Regards, Rainer - 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: Question on servlet determination
> -Original Message- > From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] > Sent: Tuesday, April 23, 2013 10:35 PM > To: Tomcat Users List > Subject: RE: Question on servlet determination > > > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > > Subject: Question on servlet determination > > > /Servlet1 > > /Servlet2 > > What happens if you try this instead: > > /Servlet1/* > /Servlet2/* > > - Chuck > Thanks for the hint Chuck, but no change. I still get the 404 error page. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question on servlet determination
> -Original Message- > From: Neven Cvetkovic [mailto:neven.cvetko...@gmail.com] > Sent: Tuesday, April 23, 2013 5:29 PM > To: Tomcat Users List > Subject: Re: Question on servlet determination > > > > > > > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > > > > > > > > > > > > Everything > > > *.jsp > > > *.html > > > *.js > > > /Servlet1 > > > /Servlet2 > > > > > > > Jeffrey, why don't you just use "catch all" url pattern? > > Is there anything that you don't want to be part of the same security > constraint? In this case security constraint just enforces SSL, but > could do other things, check roles, etc. In that case you might want to > split secure and non-secure resources ... (e.g. login page should not > be secure and login action should be secure, etc...) > > What are you trying to achieve? > > Cheers! > Neven > IIRC, I originally had the "/*" entry, back in Tomcat 4.x, but it wouldn't force the move to https for any files directly asked for in the top level. For example, http://myhost/login.jsp would not switch to https until after you entered your login information. If I get some free time, I'll probably be retesting, but, yes, I'm also going to be adding a section that will be using a different auth method for a third servlet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Nio connector in embedded tomcat7
Hi,
Not sure if anyone has used NIO connector in embedded tomcat 7 but I am
out of luck so far. It seems so simple but I could not get it work. I am
wondering if this is a bug in embedded version of tomcat because it works
fine on standalone version. If this turns out to be a bug in tomcat 7
embedded, then I may have to think about moving to Jetty but it would be
ideal if I can figure this out with tomcat 7 itself.
I am pasting the complete method that create Tomcat instance with NIO
connector and starts it. If I don't have NIO connector all rest requests
works perfectly. But with this NIO connector I can't connect to server. I
looked at the tomcat unit tests and they don't seem to be doing anything
special for NIO connector. Any help would be appreciated.
public void init() throws LifecycleException, IOException {
log.debug("Initializing Tomcat");
final File base = createBaseDirectory();
log.info("Using base folder: " + base.getAbsolutePath());
final Tomcat tomcat = new Tomcat();
tomcat.setPort(TOMCAT_PORT);
tomcat.setBaseDir(base.getAbsolutePath());
Context context = tomcat.addContext("/perfmon",
base.getAbsolutePath());
//handle rest requests
Wrapper cxfServlet = Tomcat.addServlet(context, "CXFServlet",
new
CXFServlet());
cxfServlet.addInitParameter("config-location",
"classpath:perfmon-rest-server.xml");
cxfServlet.setLoadOnStartup(1);
context.addServletMapping("/rest/*", "CXFServlet");
context.addApplicationListener(ContextLoaderListener.class.getName());
context.setLoader(new
WebappLoader(Thread.currentThread().getContextClassLoader()));
//atmosphere websocket support
Wrapper atmosphereServlet = Tomcat.addServlet(context,
"AtmosphereServlet", new TomcatAtmosphereServlet());
atmosphereServlet
.addInitParameter("org.atmosphere.cpr.packages",
"com.kiva.perfmon.prototype.pubsub.websocket");
atmosphereServlet.setLoadOnStartup(0);
context.addServletMapping("/pubsub/*", "AtmosphereServlet");
context.addParameter("contextConfigLocation",
"classpath:perfmon-context.xml");
// add nio connector for websocket support
Connector nioConnector = new
Connector(Http11NioProtocol.class.getName());
nioConnector.setPort(TOMCAT_PORT);
nioConnector.setProperty("address",
InetAddress.getByName("localhost").getHostAddress());
tomcat.setConnector(nioConnector);
tomcat.start();
tomcat.getServer().await();
}
Thanks in advance.
Praveen
On 4/23/13 Apr 23, 12:21 PM, "Praveen Peddi"
wrote:
>Sorry I meant "nio" connector not bio connector. Outlook auto-correct is
>not smart enough :)
>
>On 4/23/13 Apr 23, 12:08 PM, "Praveen Peddi"
>wrote:
>
>>I am not sure if this is the same issue I am having but apparently I am
>>also using atmosphere for web sockets and make it work in embedded
>>tomcat.
>>
>>I looked at the tomcat unit tests for bio connector and the tests are not
>>doing anything special. They set the address to localhost. I tried the
>>below code similar to the unit tests but I still can't connect to tomcat
>>when I use this connector.
>>
>>Connector nioConnector = new
>>Connector(Http11NioProtocol.class.getName());
>> nioConnector.setPort(TOMCAT_PORT);
>> nioConnector.setProperty("address",
>>InetAddress.getByName("localhost").getHostAddress());
>>tomcat.setConnector(nioConnector);
>>
>>
>>Unit test I saw is here:
>>http://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/non
>>b
>>l
>>ocking/TestNonBlockingAPI.java
>>And
>>http://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/sta
>>r
>>t
>>up/TomcatBaseTest.java
>>
>>
>>Thanks
>>Praveen
>>
>>On 4/23/13 Apr 23, 10:40 AM, "Tribon Cheng" wrote:
>>
>>>Just like this issue:
>>>
>>>http://atmosphere-framework.2306103.n4.nabble.com/WebSocket-not-working-
>>>o
>>>n
>>>-Tomcat-7-With-NIO-connector-was-WebSocket-not-working-on-Tomcat-7-td465
>>>2
>>>3
>>>51.html
>>>
>>>
>>>On Tue, Apr 23, 2013 at 10:16 PM, Mark Thomas wrote:
>>>
On 23/04/2013 15:11, Praveen Peddi wrote:
> Hi all, I am trying to set Nio connector in tomcat7 so I can use
> WebSocket support. I did the following (as simple as it can get) but
> it doesn't seem to work. When I do this I can't connect to the
> server. For example I have a GET REST request that should work but I
> get connection refused. Same with WebSocket request.
>
>
> Connector nioConnector = new Connector();
>
> nioConnector.setPort(TOMCAT_PORT);
>
> nioConnector.setProtocol(Http11NioProtocol.class.getName());
>
> tomcat.setConnector(nioCo
Re: two responses from one request - how is it possible ?
Hi André,
Those notes are very succinct. Appreciate it. Thank you for sharing.
-Shanti
On Wed, Apr 24, 2013 at 4:45 AM, André Warnier wrote:
> André Warnier wrote:
>
>> Shanti Suresh wrote:
>>
>>> André
>>>
>>> Please kindly share the half-page that you have written up so far.
>>> Actually, would you please finish it up and then post?
>>>
>>>
>> Well, here you go. Luckily, it was still in my drafts folder.
>> Remember that it was a draft, and that a more accurate explanation is
>> available in the Servlet Spec.
>>
>>
>>
>> A HTTP request looks like this :
>>
>> GET /the_url.. HTTP/1.1
>> Host: somehost.company.com
>> ..
>>
>> The "Host:" header is examined first, to find out to which configured
>> Tomcat this request is addressed. If a matching Host is found, then
>> this will be the one which processes this request further. If none is
>> found, then the request will be processed by Tomcat's default (the
>> one named in the tag).
>>
>> Then comes the evaluation of the URL ("/the_url..").
>> Within the selected , Tomcat will first attempt to match the first
>> part of the URL with (the path of) one of the (non-ROOT) defined contexts.
>> If a match is found, the request will be passed to that context for
>> processing (*).
>> If no match is found, and there is no default context defined, then
>> Tomcat will return an error to the client.
>> If there is a default context defined, then Tomcat will pass this request
>> to the default context (the one under (appBase)/ROOT) for processing.
>> Within that default context, a match will then be attempted with any of
>> the elements of that default context. If a mapping is found,
>> the request will be passed to the corresponding servlet for processing.
>> If no mapping is found, the request will be passed to the default servlet
>> of the default context for processing. That one attempts to find a file on
>> disk within the default context, which matches the path indicated by the
>> URL. If it finds one, the file will be returned as the response. If no such
>> file is found, a 404 error will be returned.
>>
>> (*) within a matching context, there will be further matching of the
>> second part of the URL, with one the defined servlet's
>> elements.
>>
>> addendum : and (as this was an unfunished draft)
> I should have added that each non-ROOT context also has a default servlet,
> inherited from the default (catalina_base)/conf/web.xml.
> So if within a context no appropriate can be found for this
> request to this context, the request will be processed by the default
> servlet of that context, which will look for a file on disk to satisfy the
> request. And if it doesn't find one, it will return a 404 error.
>
> I should also have added that the URL-mapping as described above is a bit
> rough, and that the Servlet Spec explains more accurately how this is done.
>
>
> --**--**-
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.**apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: two responses from one request - how is it possible ?
André Warnier wrote:
Shanti Suresh wrote:
André
Please kindly share the half-page that you have written up so far.
Actually, would you please finish it up and then post?
Well, here you go. Luckily, it was still in my drafts folder.
Remember that it was a draft, and that a more accurate explanation is
available in the Servlet Spec.
A HTTP request looks like this :
GET /the_url.. HTTP/1.1
Host: somehost.company.com
..
The "Host:" header is examined first, to find out to which configured
Tomcat this request is addressed. If a matching Host is found,
then this will be the one which processes this request further. If none
is found, then the request will be processed by Tomcat's default
(the one named in the tag).
Then comes the evaluation of the URL ("/the_url..").
Within the selected , Tomcat will first attempt to match the first
part of the URL with (the path of) one of the (non-ROOT) defined
contexts. If a match is found, the request will be passed to that
context for processing (*).
If no match is found, and there is no default context defined, then
Tomcat will return an error to the client.
If there is a default context defined, then Tomcat will pass this
request to the default context (the one under (appBase)/ROOT) for
processing. Within that default context, a match will then be attempted
with any of the elements of that default context. If a
mapping is found, the request will be passed to the corresponding
servlet for processing.
If no mapping is found, the request will be passed to the default
servlet of the default context for processing. That one attempts to
find a file on disk within the default context, which matches the path
indicated by the URL. If it finds one, the file will be returned as the
response. If no such file is found, a 404 error will be returned.
(*) within a matching context, there will be further matching of the
second part of the URL, with one the defined servlet's
elements.
addendum : and (as this was an unfunished draft)
I should have added that each non-ROOT context also has a default servlet, inherited from
the default (catalina_base)/conf/web.xml.
So if within a context no appropriate can be found for this request to this
context, the request will be processed by the default servlet of that context, which will
look for a file on disk to satisfy the request. And if it doesn't find one, it will
return a 404 error.
I should also have added that the URL-mapping as described above is a bit rough, and that
the Servlet Spec explains more accurately how this is done.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: two responses from one request - how is it possible ?
Shanti Suresh wrote:
André
Please kindly share the half-page that you have written up so far.
Actually, would you please finish it up and then post?
Well, here you go. Luckily, it was still in my drafts folder.
Remember that it was a draft, and that a more accurate explanation is available in the
Servlet Spec.
A HTTP request looks like this :
GET /the_url.. HTTP/1.1
Host: somehost.company.com
..
The "Host:" header is examined first, to find out to which configured Tomcat this
request is addressed. If a matching Host is found, then this will be the one which
processes this request further. If none is found, then the request will be processed by
Tomcat's default (the one named in the tag).
Then comes the evaluation of the URL ("/the_url..").
Within the selected , Tomcat will first attempt to match the first part of the URL
with (the path of) one of the (non-ROOT) defined contexts. If a match is found, the
request will be passed to that context for processing (*).
If no match is found, and there is no default context defined, then Tomcat will return an
error to the client.
If there is a default context defined, then Tomcat will pass this request to the default
context (the one under (appBase)/ROOT) for processing. Within that default context, a
match will then be attempted with any of the elements of that default
context. If a mapping is found, the request will be passed to the corresponding servlet
for processing.
If no mapping is found, the request will be passed to the default servlet of the default
context for processing. That one attempts to find a file on disk within the default
context, which matches the path indicated by the URL. If it finds one, the file will be
returned as the response. If no such file is found, a 404 error will be returned.
(*) within a matching context, there will be further matching of the second part of the
URL, with one the defined servlet's elements.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: > We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 > server so that http://iis.company.com/website/myfile.jsp will correctly > redirect according to our 'isapi_redirect.properties', 'workers.properties', > and 'uriworkermap.properties ' and serve the JSP page from > http://tomcat.company.com/website/myfile.jsp . That appears to be working > just fine. But we actually need to have a different IIS URL. What we are > trying to figure out is if we can configure it so that > http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve > the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on > the IIS server is has two extra levels (/apps/cepv) in the URL path and does > not match the path on the tomcat server where the JSP content is. We have to > have those two extra levels in the IIS URL path for other technical reasons > and we cannot match or include those two extra levels on the tomcat side. > > We have tried the following but cannot get it to work. > > website.worker=website_ajp13 > /apps/cepv/website/*.jsp=$(website.worker) > > Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from "If you are using Microsoft IIS as a web server...". Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
