Tomcat-6.0.6 - path attribute not honored in Context descriptor files.
Problem: The "path" attribute in the Context descriptor file no used in TC 5.5 and 6.0. Background: In an application deployment you whish to be able to install and upgrade both tomcat and your WARS individually. In TC 4.1 this was easily done by dropping a Context descriptor file in the webapps directory. This Context descriptor contained beside local configurations mainly what was deployed (docBase - which WAR) and where it should be deployed (path - mount point for the WAR). Name of the Context descriptor file was arbitrary except it had an '.xml' extension. The ability to drop Context descriptor files are now moved to the $CATALINA_HOME/conf/[enginename]/[hostname] directory OK. The problem is that the "path" attribute is ignored in the Context read from this directory. Only Contexts defined in the server.xml file honors the path attribute. Defining the Contexts in the server.xml file is though discouraged of obvious reasons. Boris -- \\V// (o o) --ooO--(_)--Ooo- You know you've achieved perfection in design, NOT when you have nothing more to add, but when you have nothing more to remove. ..... Boris Prochazka E-mail: [EMAIL PROTECTED] Arenavagen 23, Box 101 60 http://www.ipunplugged.com SE-121 28 Stockholm Globen [home] +46 8 - 6040786 [office] +46 8 - 7255919 SWEDEN [mobile] +46 70 - 5125122 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat-6.0.6 - path attribute not honored in Context descriptor files.
I know that it works according to the documentation but I can't
ignore the fact that I believe it's wrong. If you look closer in
the code of HostConfig.deployDescriptors() you note that others has
missed the ability to set the context path and has hidden it in the
filename which is neither portable nor documented.
File contextXml = new File(configBase, files[i]);
if (files[i].toLowerCase().endsWith(".xml")) {
// Calculate the context path and make sure it is unique
String nameTmp = files[i].substring(0, files[i].length() - 4);
String contextPath = "/" + nameTmp.replace('#', '/');
if (nameTmp.equals("ROOT")) {
contextPath = "";
}
If you understand me I believe it's a mistake to tie the Context
descriptors file name to the context path while there is a clean and
documented way of defining the path in the context tag. In this aspect
I believe the way it worked in TC-4.1 is to prefer and I ask you
to reconsider it.
Boris
Markus Schönhaber wrote:
> boris wrote:
>
>> The problem
>> is that the "path" attribute is ignored in the Context read from this
>> directory. Only Contexts defined in the server.xml file honors the
>> path attribute.
>
> That's not a problem. It's exactly the way it's meant to be:
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>
> | The value of this field must not be set except when statically defining a
> | Context in server.xml, as it will be infered from the filenames used for
> | either the .xml context file or the docBase.
>
> BTW: for support questions you should post to the users list.
>
> Regards
> mks
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
\\V//
(o o)
--ooO--(_)--Ooo-
You know you've achieved perfection in design,
NOT when you have nothing more to add,
but when you have nothing more to remove.
.
Boris Prochazka E-mail: [EMAIL PROTECTED]
Arenavagen 23, Box 101 60 http://www.ipunplugged.com
SE-121 28 Stockholm Globen [home] +46 8 - 6040786
[office] +46 8 - 7255919
SWEDEN [mobile] +46 70 - 5125122
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hanging threads on JIoEndpoint$Worker.await() in TC-6.0.13 JRE-1.6.0u1
To start with I am not sure this is the right place for posting this problem/behaviur and I am not claiming nither that it is a bug, just something that may bee fragile in Tomcat-6. What I have noticed is that after a couple of hours traffic I get a large number (20 or more) of threads that are hanging on JIoEndpoint$Worker.await() With Jconsole I get the following stack trace: Name: http-8443-14 State: WAITING on [EMAIL PROTECTED] Total blocked: 0 Total waited: 1 Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:485) org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442) java.lang.Thread.run(Thread.java:619) I don't know what's the origin for this. There are no special messages in the logs and I can't see any stackdumps from exception during the time when the threads were created. The major traffic during the time has been requesting the same jsp page (pings for validating that the TC is up) that involves very little application code. I suspect that number of worker threads are limited and if this keeps on increasing this will finally crash the TC. It may be a good approach to set a time limit on the worker threads and thereby get it self healing or this may be a TC bug that of course is best if it's fixed. OpenSUSE-10.2, kernel 2.6.18.8-0.3-default #1 SMP TC-6.0.13 JDK 1.6.0 u1 /Boris ..... Boris Prochazka E-mail: [EMAIL PROTECTED] Arenavagen 23, Box 101 60 http://www.ipunplugged.com SE-121 28 Stockholm Globen [home] +46 8 - 6040786 [office] +46 8 - 7255919 SWEDEN [mobile] +46 70 - 5125122 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
exception in tomcat 5.5.23
Hi I'm getting the following exception in tomcat 5.5.23: Aug 17, 2007 3:31:20 PM org.apache.coyote.http11.Http11Processor process SEVERE: Error finishing request java.lang.ArrayIndexOutOfBoundsException: -45 at org.apache.coyote.http11.filters.ChunkedInputFilter.parseChunkHeader(ChunkedInputFilter.java:257) at org.apache.coyote.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:130) at org.apache.coyote.http11.filters.ChunkedInputFilter.end(ChunkedInputFilter.java:180) at org.apache.coyote.http11.InternalInputBuffer.endRequest(InternalInputBuffer.java:369) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:895) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) In this request I transfer binary data inside the request/response any ideas? -- View this message in context: http://www.nabble.com/exception-in-tomcat-5.5.23-tf4285817.html#a12200014 Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
