You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Kevin Jones <ke...@develop.com> on 2000/03/07 11:52:29 UTC
Work directory not being cleared
When I shut Tomcat down the work directory isn't being cleared (I'm sure it
used to be), does the isWorkDirPersistent="false" attribute on the context
still have any meaning.
Kevin Jones
www.develop.com
RE: Work directory not being cleared
Posted by Kevin Jones <ke...@develop.com>.
Hate to reply to my own e-mails but the isWorkDirPersistent has been
depracated, so the question is, why?
Kevin Jones
www.develop.com
> -----Original Message-----
> From: Kevin Jones [mailto:kevinj@develop.com]
> Sent: 07 March 2000 10:52
> To: Tomcat-Dev
> Subject: Work directory not being cleared
>
>
> When I shut Tomcat down the work directory isn't being cleared
> (I'm sure it
> used to be), does the isWorkDirPersistent="false" attribute on the context
> still have any meaning.
>
>
> Kevin Jones
> www.develop.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Replacing default servlet in 3.1 Beta RC 1
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Two things:
1) It's no longer possible to replace the default servlet with your own
in Tomcat 3.1 Beta RC 1. I'm trying this with a new context, using
the following mappings in web.xml:
<web-app>
<servlet>
<servlet-name>
snoop
</servlet-name>
<servlet-class>
SnoopServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>
snoop
</servlet-name>
<url-pattern>
/
</url-pattern>
</servlet-mapping>
</web-app>
It used to work in a previous version. (I also tried with "/*", without success,
but I believe "/" is the correct mapping for the default servlet).
2) In an older version, where this works, the paths returned from getServletPath()
and getPathInfo() seem to be incorrect. For instance, with a context path "/grx",
the URL http://localhost:port/grx/test.cmp gives the following results:
getRequestURI() returns "/grx/test.cmp"
getPathInfo() returns "/test.cmp"
getServletPath() returns ""
The Servlet 2.2 spec says:
Servlet Path: The path section that directly corresponds to the mapping
which activated this request. This path starts with a '/' character.
Path Info: The part the request path that is not part of the Context Path or
the Servlet Path.
My interpretation of this is that when the default mapping is used, the
whole path is used for mapping and the result should therefore be
getRequestURI() returns "/grx/test.cmp"
getPathInfo() returns ""
getServletPath() returns "/test.cmp"
If you don't agree that this is a bug (rather different interpretations of the
spec), maybe Danny Coward can clarify.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
RE: Work directory not being cleared
Posted by co...@eng.sun.com.
> One thought - why not have a 'build' or 'debug' mode in which the context's
> work directory gets cleared?
We can have a command to remove the work directory, or use the admin
context.
I would like to keep it simple - how can we explain the "debug" mode ?
( you don't want the directory removed anyway for debug mode - to be able
to look at the files and debug )
I don't think automatic removal is very intuitive, and even if we had it,
you shouldn't use it in most cases.
Costin
>
> Kevin Jones
> www.develop.com
>
> > -----Original Message-----
> > From: costin@eng.sun.com [mailto:costin@eng.sun.com]
> > Sent: 07 March 2000 17:07
> > To: Tomcat-Dev
> > Subject: Re: Work directory not being cleared
> >
> >
> > > When I shut Tomcat down the work directory isn't being cleared
> > (I'm sure it
> > > used to be), does the isWorkDirPersistent="false" attribute on
> > the context
> > > still have any meaning.
> >
> > I can't find any reference to removing the work dir in the specifications.
> > It is also bad for performance - the code generated from jsps will be
> > removed and will have to be reloaded again. It's also bad for servlets -
> > the workdir is a place where servlets are allowed to write ( all other
> > directories should not have write permission - we still have to add the
> > policy ) - and removing the files is unexpected.
> >
> > It's easy to add add back the remove code, it's a trivial interceptor, but
> > I can't think of any good reason to have that. Fill a bug if you need that
> > and we can have it back.
> >
> >
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
RE: Work directory not being cleared
Posted by Kevin Jones <ke...@develop.com>.
I spent half a day trying to track down various issues I had with Taglibs.
In the end it all came down to files in the work directory being out of date
with files in my context (including .jar files). Once I realised what the
problem was I worked around it - If I get time this week I'll go back and
see if I can repeat the problem - if I can repeat it I'll document what
happend.
One problem I did have was to do with case sensitivity (and this is
repeatable). If I had a taglib directive in a jsp reference SimpleTags.jar,
Jasper (I assume) copied that Jar file to the worj directory, then created
and compiled the java code. If I change the reference to simpleTags.jar
(with a lowercase 's'), then the JSP wouldn't work - it doesn't copy over a
simpleTags.jar beacuse it does (I assume) a case insensitive compare, but
for some reason can#t find the files in the SimpleTags.jar it put there
before! I haven't got to the bottom of this (and if somebody could confirm
this behaviour to prove I'm not going mad I'd be grateful), but, again I'll
try and get back to this later in the week.
One thought - why not have a 'build' or 'debug' mode in which the context's
work directory gets cleared?
Kevin Jones
www.develop.com
> -----Original Message-----
> From: costin@eng.sun.com [mailto:costin@eng.sun.com]
> Sent: 07 March 2000 17:07
> To: Tomcat-Dev
> Subject: Re: Work directory not being cleared
>
>
> > When I shut Tomcat down the work directory isn't being cleared
> (I'm sure it
> > used to be), does the isWorkDirPersistent="false" attribute on
> the context
> > still have any meaning.
>
> I can't find any reference to removing the work dir in the specifications.
> It is also bad for performance - the code generated from jsps will be
> removed and will have to be reloaded again. It's also bad for servlets -
> the workdir is a place where servlets are allowed to write ( all other
> directories should not have write permission - we still have to add the
> policy ) - and removing the files is unexpected.
>
> It's easy to add add back the remove code, it's a trivial interceptor, but
> I can't think of any good reason to have that. Fill a bug if you need that
> and we can have it back.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Work directory not being cleared
Posted by co...@eng.sun.com.
> When I shut Tomcat down the work directory isn't being cleared (I'm sure it
> used to be), does the isWorkDirPersistent="false" attribute on the context
> still have any meaning.
I can't find any reference to removing the work dir in the specifications.
It is also bad for performance - the code generated from jsps will be
removed and will have to be reloaded again. It's also bad for servlets -
the workdir is a place where servlets are allowed to write ( all other
directories should not have write permission - we still have to add the
policy ) - and removing the files is unexpected.
It's easy to add add back the remove code, it's a trivial interceptor, but
I can't think of any good reason to have that. Fill a bug if you need that
and we can have it back.
Costin