Re: Tomcat gets not enough memory on vServer
Hello, thank you all for your answers! Because of this and some other problems, I decided to switch the provider and I have now an other machine running an 32bit OS. Using the same default settings as on the other two machines, tomcat is now running very fine. I don't know the reason, but I think it could depend on the vServer host-technology and host-settings. Merry Christmas to all Lars - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Errors in session replication and very high server load
Well, the log messages you see, are all based on timeouts.
If your system has a load average of 12, unless you have a 12-way
machine, that is very high, and could be the cause of your timeouts.
You will need to figure out what is causing the high load average.
Filip
On 12/18/2009 01:30 AM, mohame...@easy-dialog.info wrote:
Dear All,
I have a strange problem. When I added a new server to my tomcat cluster I have
noticed that the load is getting very high on the server. Tomcat log show a lot
of these lines
18.12.2009 09:07:14 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-120}:4000,{62, 75, -127, -120},4000, alive=65087504,id={-64 -42 103 97 8 -7 69
-88 -113 -106 -32 -64 46 76 -117 -58 }, payload={}, command={}, domain={}, ]
18.12.2009 09:07:14
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-122}:4000,{62, 75, -127, -122},4000, alive=64996684,id={-15 62 -53 -50 -43 81
75 18 -112 -43 58 -102 69 72 83 21 }, payload={}, command={}, domain={}, ]]
18.12.2009 09:07:19
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
performBasicCheck
WARNUNG: Member added, even though we werent
notified:org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-117}:4000,{62, 75, -127, -117},4000, alive=58229968,id={16 -115 -21 -109 18 -76
79 58 -95 -17 57 -32 -69 -111 -20 28 }, payload={}, command={}, domain={}, ]
18.12.2009 09:07:19 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-117}:4000,{62, 75, -127, -117},4000, alive=58229968,id={16 -115 -21 -109 18 -76
79 58 -95 -17 57 -32 -69 -111 -20 28 }, payload={}, command={}, domain={}, ]
18.12.2009 09:08:10 org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75,
-127, -121}:4000,{62, 75, -127, -121},4000, alive=64986581,id={-87 -91 115 -83
80 64 76 -9 -68 -107 -109 52 0 -47 109 98 }, payload={}, command={}, domain={},
]
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
performBasicCheck
INFO: Suspect member, confirmed
dead.[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-121}:4000,{62, 75, -127, -121},4000, alive=64986581,id={-87 -91 115 -83 80 64
76 -9 -68 -107 -109 52 0 -47 109 98 }, payload={}, command={}, domain={}, ]]
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62,
75, -127, -121}:4000,{62, 75, -127, -121},4000, alive=65045054,id={-87 -91 115
-83 80 64 76 -9 -68 -107 -109 52 0 -47 109 98 }, payload={}, command={},
domain={}, ]] message. Will verify.
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62, 75, -127,
-121}:4000,{62, 75, -127, -121},4000, alive=65045054,id={-87 -91 115 -83 80 64
76 -9 -68 -107 -109 52 0 -47 109 98 }, payload={}, command={}, domain={}, ]]
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62,
75, -127, -122}:4000,{62, 75, -127, -122},4000, alive=65054434,id={-15 62 -53
-50 -43 81 75 18 -112 -43 58 -102 69 72 83 21 }, payload={}, command={},
domain={}, ]] message. Will verify.
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62,
75, -127, -118}:4000,{62, 75, -127, -118},4000, alive=58290426,id={101 61 65 84
-59 -114 65 -57 -106 8 -118 -25 -55 56 -82 111 }, payload={}, command={},
domain={}, ]] message. Will verify.
18.12.2009 09:08:10
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{62,
75, -127, -120}:4000,{62, 75, -127, -120},4000, alive=65141440,id={-64 -42 103
97 8 -7 69 -88 -113 -106 -32 -64 46 76 -117 -58 }, payload={}, command={},
domain={}, ]] message. Will verify.
Also the load on the server is getting very high (while no CPU usage). This is
the output of top
top - 08:29:51 up 63 days, 22:53, 1 user, load average: 12.95, 10.61, 8.35
Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 0.6%sy, 0.0%ni, 98.4%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 33023640k total, 19154120k used, 13869520k free, 373012k buffers
Swap: 92k total, 676k used, 999316k free,
submitting more patches
Hi. Bill, Mark, I have more patches to submit for LocalStrings_fr.properties files, in the various sub-directories of Tomcat6. I also have a couple of new ones, for sub-dirs where no French version existed. Do I keep submitting this on Bugzilla, one by one ? Or is there some better way ? I would like by the way to express my respectful regards to the original author of the French translations. Believe me, it is not easy to come up with French terms for JMX Remote Listener and the like. One particularly troublesome aspect : is servlet a he, or a she ? The author of the French translations chose to make it a she, which is kind of cute and changes the way I am now thinking about these modules. But then comes the question of whether we should also change the name to servlette, because la servlet sounds kind of funny. Maybe there should be a vote about this among the French-speaking committers ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
Hello, I've always spoke of a servlet as a female name. Think about an applet, for instance. But that's only my opinion. Regards, Pierre On Sun, Dec 20, 2009 at 3:02 PM, André Warnier a...@ice-sa.com wrote: Hi. Bill, Mark, I have more patches to submit for LocalStrings_fr.properties files, in the various sub-directories of Tomcat6. I also have a couple of new ones, for sub-dirs where no French version existed. Do I keep submitting this on Bugzilla, one by one ? Or is there some better way ? I would like by the way to express my respectful regards to the original author of the French translations. Believe me, it is not easy to come up with French terms for JMX Remote Listener and the like. One particularly troublesome aspect : is servlet a he, or a she ? The author of the French translations chose to make it a she, which is kind of cute and changes the way I am now thinking about these modules. But then comes the question of whether we should also change the name to servlette, because la servlet sounds kind of funny. Maybe there should be a vote about this among the French-speaking committers ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Ad augusta per angusta Des résultats grandioses par des voies étroites
Re: submitting more patches
Pierre Goupil wrote: Hello, I've always spoke of a servlet as a female name. Think about an applet, for instance. But that's only my opinion. Opinions is what this is all about. So, what about a first round of informal voting ? le servlet est initialisé ? y/n la servlet est initialisée ? y/n la servlette est initialisée ? y/n l'applet est initialisé ? y/n l'applet est initialisée ? y/n l'applette est initialisée ? y/n ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
Mark Thomas wrote:
On 19/12/2009 10:45, André Warnier wrote:
...
To get back to the main issue, as long as I anway get the hang of this
stuff, and have checked out the SVN of Tomcat anyway,
where in the /valves stuff do I find where it actually checks the
remote IP against which RemoteAddressValve operates ?
public void invoke(Request request, Response response)
throws IOException, ServletException {
process(request.getRequest().getRemoteAddr(), request, response);
}
It is the request.getRequest().getRemoteAddr() call.
Right.
So, to summarise the original concern :
The point was to see if it was possible to upgrade the
RemoteAddressValve so that it would offer a choice, when filtering the
remote IP address (for a request which came in through a proxy),
between the original client's address, and the IP address of the proxy
itself (the one connected directly to the Tomcat Connector socket).
The idea being, to stop some unwanted proxy server to use our services
if we don't want to, independently of the real proxy-ed remote client.
It would seem that currently in such a case, the RemoteAddressValve
always considers the original client's address.
The above getRemoteAddr() call refers to request, which seems to be a
Request as defined in connector/Request.java :
/**
* Return the remote IP address making this Request.
*/
public String getRemoteAddr() {
if (remoteAddr == null) {
coyoteRequest.action
(ActionCode.ACTION_REQ_HOST_ADDR_ATTRIBUTE, coyoteRequest);
remoteAddr = coyoteRequest.remoteAddr().toString();
}
return remoteAddr;
}
This seems to check if Request.remoteAddr has already been set, if not
to call something to set it, and then return the address as a string.
This looks rather bad, because wherever that action above is carried
out, it seems that it must have its own logic for determining the remote
address. Somewhere along the line, considering that this is a proxied
call, it must decide to pick up the remote address from a
X-forwarded-for HTTP header instead of the real IP address of the
proxy itself.
So changing something there would probably mean quite a few cascading
changes in multiple areas, to avoid unwanted side-effects.
One would probably have to add at least some new fields in the
coyoteRequest, like
/**
* Remote address of the closest proxy.
*/
protected String proxyRemoteAddr = null;
/**
* Remote host of the closest proxy.
*/
protected String proxyRemoteHost = null;
/**
* Remote port of the closest proxy
*/
protected int proxyRemotePort = -1;
then the action codes to fill these, and so on.
I see some very suspicious comment for instance in
coyote/ajp/AjpAprProcessor.java :
/*
* AJP13 misses to forward the remotePort.
* Allow the AJP connector to add this info via
* a private request attribute.
* We will accept the forwarded data as the remote port,
* and remove it from the public list of request
attributes.
*/
which does not sound very auspicious.
In other words : it seems that quite early in the request process, a
decision is taken to *replace* the remote IP address as obtained from
the socket, by the ultimate IP of the client for which this proxy
request is being processed. This casts a doubt on the ability of even a
servlet filter to obtain the IP address of the proxy server which has
the real connection with Tomcat.
All a bit beyond my dabbling capabilities, I'm afraid.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
On 20/12/2009 14:02, André Warnier wrote: Hi. Bill, Mark, I have more patches to submit for LocalStrings_fr.properties files, in the various sub-directories of Tomcat6. I also have a couple of new ones, for sub-dirs where no French version existed. Do I keep submitting this on Bugzilla, one by one ? Or is there some better way ? If I recall correctly you are using Tortoise SVN. If you generate the patch from the root of the svn checkout, you will get all of the patches in a single file. You can then attach that to a new bugzilla entry. If that doesn't work for some reason, you can attach multiple patches to one Bugzilla entry. Thanks for your efforts on this. They are much appreciated. And for everyone else, Tomcat currently has partial translations for German, Spanish and Japanese. Contributions to extend or correct those translations - or to add completely new translations - are always welcome. If you have the language skills but aren't sure how to get started on the translations, please do ask for help on the users list. Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
On 20/12/2009 16:04, André Warnier wrote: In other words : it seems that quite early in the request process, a decision is taken to *replace* the remote IP address as obtained from the socket, by the ultimate IP of the client for which this proxy request is being processed. This casts a doubt on the ability of even a servlet filter to obtain the IP address of the proxy server which has the real connection with Tomcat. All a bit beyond my dabbling capabilities, I'm afraid. This is one of those times where the solution will depend on the protocol you are using. The AJP connectors will report the client's IP address so you need an alternative solution. Using the request.secret attribute is probably the simplest fix although keep in mind that AJP is clear text so the secret might not be that secret. The HTTP connectors will report the proxy's IP address so the RemoteAddressValve can be used. Note in Tomcat 7: - where the RemoteIpValve is available you would need to make sure that the RemoteAddressVlave was earlier in the pipeline than the RemoteIpValve - you have the option of using Valves or Filters for this functionality HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
Mark Thomas wrote: ... This is one of those times where the solution will depend on the protocol you are using. The AJP connectors will report the client's IP address so you need an alternative solution. Using the request.secret attribute is probably the simplest fix although keep in mind that AJP is clear text so the secret might not be that secret. The problem being that Apache's mod_proxy_ajp does not seem to allow setting the secret. http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass (mod_jk does) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
Mark Thomas wrote: ... If I recall correctly you are using Tortoise SVN. If you generate the patch from the root of the svn checkout, you will get all of the patches in a single file. You can then attach that to a new bugzilla entry. You do recall correctly, and it did generate a single patch file. Examine it carefully though, I don't really know what I'm doing yet. If that doesn't work for some reason, you can attach multiple patches to one Bugzilla entry. It did not however seem to generate anything for the new files, so I filed these separately, one per bug. One more thing : I noticed that in some of the Language_fr.properties files, not all of the labels that are present in the basic Language.properties file are present if the _fr version. Example : connector/Language.properties Should I add the missing entries, or is there a specific reason why they are not translated ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
On 20.12.2009 21:00, André Warnier wrote: Mark Thomas wrote: ... This is one of those times where the solution will depend on the protocol you are using. The AJP connectors will report the client's IP address so you need an alternative solution. Using the request.secret attribute is probably the simplest fix although keep in mind that AJP is clear text so the secret might not be that secret. The problem being that Apache's mod_proxy_ajp does not seem to allow setting the secret. http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass (mod_jk does) Use a custom http header? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
On 20.12.2009 21:24, André Warnier wrote: Mark Thomas wrote: ... If I recall correctly you are using Tortoise SVN. If you generate the patch from the root of the svn checkout, you will get all of the patches in a single file. You can then attach that to a new bugzilla entry. You do recall correctly, and it did generate a single patch file. Examine it carefully though, I don't really know what I'm doing yet. If that doesn't work for some reason, you can attach multiple patches to one Bugzilla entry. It did not however seem to generate anything for the new files, so I filed these separately, one per bug. One more thing : I noticed that in some of the Language_fr.properties files, not all of the labels that are present in the basic Language.properties file are present if the _fr version. Example : connector/Language.properties Should I add the missing entries, or is there a specific reason why they are not translated ? They might not have existed at the time the original translation was done (or the original author is still thinking about the right french servlet grammar ...). Missing items are automatically taken from the english files. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat not listing on ipv4
I have just upgraded my Debian server to unstable, and now find that attempt to connect to my tomcat via ajp fails. It appears from netstat is tomcat is listing on 8009 but only on ipv6 I have been unable to find out how to change this. Can someone give me a clue. -- Alan Chandler http://www.chandlerfamily.org.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat not listing on ipv4
Alan Chandler wrote: I have just upgraded my Debian server to unstable, and now find that attempt to connect to my tomcat via ajp fails. It appears from netstat is tomcat is listing on 8009 but only on ipv6 I have been unable to find out how to change this. Can someone give me a clue. As a hack : use the Address attribute of the AJP Connector and specify a V4 address ? (if only 127.0.0.1) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
Rainer Jung wrote: ... They might not have existed at the time the original translation was done (or the original author is still thinking about the right french servlet grammar ...). Der, die oder das servlet ? oder Servlet ? ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: submitting more patches
Mark Thomas wrote: And for everyone else, Tomcat currently has partial translations for German, Spanish and Japanese. Contributions to extend or correct those translations - or to add completely new translations - are always welcome. If you have the language skills but aren't sure how to get started on the translations, please do ask for help on the users list. A bit OT, but in servlets/LocaLStrings.properties, there is this line : directory.version=Tomcat Catalina version 4.0 is that still correct ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat not listing on ipv4
André Warnier wrote: Alan Chandler wrote: I have just upgraded my Debian server to unstable, and now find that attempt to connect to my tomcat via ajp fails. It appears from netstat is tomcat is listing on 8009 but only on ipv6 I have been unable to find out how to change this. Can someone give me a clue. As a hack : use the Address attribute of the AJP Connector and specify a V4 address ? (if only 127.0.0.1) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org It works at least as far as connecting to Tomcat from apache is concerned. I now have problems accessing the database from tomcat and that is throwing an exception -- Alan Chandler http://www.chandlerfamily.org.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
404 for JSPs
When I run embedded Tomcat my jsps 404, but my servlets work. When I run standard (by putting my war on the Tomcat/webapps directory) my servlets 404 but my jsps work (without any css). Can anyone shed some light on this? My startup script for embedded is here: http://gist.github.com/259737 Thanks, Clay - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 404 for JSPs
Oh, and no errors in the logs. On 12/20/09 8:32 PM, Clay McCoy cmc...@acteksoft.com wrote: When I run embedded Tomcat my jsps 404, but my servlets work. When I run standard (by putting my war on the Tomcat/webapps directory) my servlets 404 but my jsps work (without any css). Can anyone shed some light on this? My startup script for embedded is here: http://gist.github.com/259737 Thanks, Clay - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 404 for JSPs
2009/12/21 Clay McCoy cmc...@acteksoft.com: When I run embedded Tomcat my jsps 404, but my servlets work. I guess that you do not have the Jsp servlet configured. See conf/web.xml. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
Mark Thomas ma...@apache.org wrote in message news:4b2e4e77.3000...@apache.org... On 20/12/2009 16:04, André Warnier wrote: In other words : it seems that quite early in the request process, a decision is taken to *replace* the remote IP address as obtained from the socket, by the ultimate IP of the client for which this proxy request is being processed. This casts a doubt on the ability of even a servlet filter to obtain the IP address of the proxy server which has the real connection with Tomcat. All a bit beyond my dabbling capabilities, I'm afraid. This is one of those times where the solution will depend on the protocol you are using. Exactly. The AJP/1.3 protocol doesn't consider itself to be a proxy (and anyone old enough to remember it's predecessor mod_jserv will see why), but rather an integration of Tomcat with the native server (more like mod_fcgid).This means that last hop is considered to be the native server. The protocol itself is even transport agnostic, and in the past it has been possible to run Tomcat inside of IIS/Apache or even to use Unix Sockets. The AJP connectors will report the client's IP address so you need an alternative solution. Using the request.secret attribute is probably the simplest fix although keep in mind that AJP is clear text so the secret might not be that secret. Yes, AJP/1.3 assumes that the connection between the native server and the Tomcat server is secured, so that if someone can sniff AJP/1.3 packets it means that the system is already badly compromised. If using mod_jk, then yes, the 'secret' is the simplest way to go. If using mod_proxy_ajp, then you need to head on over to submit a patch for httpd to add this configuration option (most of the active developers of mod_proxy_ajp lurk on this list if you need help, but d...@httpd.a.o is the official list for this). The table of 'names' for the two supported protocols is: Name HTTP/1.1 AJP/1.3 serverNameHost header Host header remoteName last proxy server (or client if no proxies) last proxy server before native server (or client) localName The name the connector is bound to name of native server (i.e. the ServerName) Which gives a third option to the OP, which is to use the useIPVHosts=true option on the Connector ... /, and only configure Host .../s for the ones that he wants to allow to connect (and the default Host just returns 404 to every request). The HTTP connectors will report the proxy's IP address so the RemoteAddressValve can be used. Note in Tomcat 7: - where the RemoteIpValve is available you would need to make sure that the RemoteAddressVlave was earlier in the pipeline than the RemoteIpValve - you have the option of using Valves or Filters for this functionality HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 404 for JSPs
Thank you, this got me closer. I have two questions: 1) My current web.xml didn't configure the jsp servlet. I haven't had do configure that for a number of other containers. I don't understand why I had to do this specifically for Tomcat. It also seems bizarre that the jsps worked without this jsp servlet in my standard Tomcat deployment. What should I have read to know about Tomcat needing a jsp servlet and possibly other related gotchas? 2) I now get this error. I'm guessing that this means that I need to do something to configure my custom tags? javax.servlet.ServletException: javax.servlet.jsp.tagext.TagAttributeInfo.init(Ljava/lang/String;ZLjava/lang/String;ZZLjava/lang/String;ZZLjava/lang/String;Ljava/lang/String;)V at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:275) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) On 12/20/09 8:56 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2009/12/21 Clay McCoy cmc...@acteksoft.com: When I run embedded Tomcat my jsps 404, but my servlets work. I guess that you do not have the Jsp servlet configured. See conf/web.xml. - 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: 404 for JSPs
Apparently Groovy 1.7 rc2 uses an outdated jsp api (2.0) and Tomcat 6 uses 2.1 This conflict was causing me problems. Of all the libraries, I was very surprised to see the conflict between the latest Tomcat and Groovy. Things still aren't right, but I don't know how to report what I am seeing yet. Thanks, Clay On 12/20/09 10:24 PM, Clay McCoy cmc...@acteksoft.com wrote: Thank you, this got me closer. I have two questions: 1) My current web.xml didn't configure the jsp servlet. I haven't had do configure that for a number of other containers. I don't understand why I had to do this specifically for Tomcat. It also seems bizarre that the jsps worked without this jsp servlet in my standard Tomcat deployment. What should I have read to know about Tomcat needing a jsp servlet and possibly other related gotchas? 2) I now get this error. I'm guessing that this means that I need to do something to configure my custom tags? javax.servlet.ServletException: javax.servlet.jsp.tagext.TagAttributeInfo.init(Ljava/lang/String;ZLjava/lang/String;ZZLjava/lang/String;ZZLjava/lang/String;Ljava/lang/String;)V at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:275) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) On 12/20/09 8:56 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2009/12/21 Clay McCoy cmc...@acteksoft.com: When I run embedded Tomcat my jsps 404, but my servlets work. I guess that you do not have the Jsp servlet configured. See conf/web.xml. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 404 for JSPs
2009/12/21 Clay McCoy cmc...@acteksoft.com: Thank you, this got me closer. I have two questions: 1) My current web.xml didn't configure the jsp servlet. I haven't had do configure that for a number of other containers. I don't understand why I had to do this specifically for Tomcat. You do not have to do it here either. conf/web.xml provides it for you. You may say that it is merged with your web.xml. I do not know what happened in your case. Maybe you need to read that file programmatically, or maybe it just was not found. It also seems bizarre that the jsps worked without this jsp servlet in my standard Tomcat deployment. What should I have read to know about Tomcat needing a jsp servlet and possibly other related gotchas? Embedded tomcat is not a 'standard' deployment. Apparently Groovy 1.7 rc2 uses an outdated jsp api (2.0) and Tomcat 6 uses 2.1 Tomcat uses whatever version is specified in your web.xml file. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
