You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Preston L. Bannister" <pr...@home.com> on 1999/11/09 20:29:30 UTC
Patch to WARConnection.java to remove compile error.
Commented out a unused function containing a compile error.
Index: src/share/org/apache/tomcat/protocol/WARConnection.java
===================================================================
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/protocol/WARC
onnection.java,v
retrieving revision 1.1.1.1
diff -u -b -r1.1.1.1 WARConnection.java
--- WARConnection.java 1999/10/09 00:20:47 1.1.1.1
+++ WARConnection.java 1999/11/09 19:18:32
@@ -150,12 +150,14 @@
}
}
+/* XXX -- Not compilable and not used. What was the intent here?
public String getContentType() {
// XXX
// hmmm .. what about the mimeTypes associated with
// this context
return getFileNameMap().getContentTypeFor(path);
}
+XXX */
public int getContentLength() {
Long l = new Long(this.size);
--
Preston L. Bannister
http://members.home.com/preston
preston@home.com
Re: Feature: port 80
Posted by James Todd <ja...@eng.sun.com>.
David Brownell wrote:
> I'd have to check, but I seem to recall another issue in that area.
> It was along the lines of needing to be able to switch the port and
> docroot on the command line, without munging "server.xml". If KHTTPD
> isn't available (wrong kernel or somesuch) then tomcat needs to switch
> over and use a different port. A few weeks ago, I seem to recall that
> I believed port switching (and associated UID switch issue) didn't seem
> like it could be done without changing "server.xml" ... undesirable.
>
about 3 months back i had it such that the command line args
would superceed the server.xml config data. i was actually
pretty happy with how it worked out. that said, i believe something
may have shaken loose when renaming some of the config
element names, dropping some, adding others, etc.
regardless, it shouldn't be too difficult a task to get the command
line switches to completely cover the present server.xml config
data.
hope this helps,
- james
Re: Feature: port 80
Posted by David Brownell <da...@pacbell.net>.
Jason Hunter wrote:
>
> One feature I haven't seen mentioned oddly enough is the ability for
> Tomcat standalone to listen on port 80 under Unix as a non-root user.
> JWS did this using native code to change the user id after attaching to
> the socket. What's the feeling out there of providing that native code
> to Tomcat for standalone use?
That's where a split personality comes in handy:
- Using Linux KHTTPD feeding nonstatic requests to tomcat ...
no need for it, port 80 is KHTTPD, tomcat uses some other one.
- But maybe I don't want to run two servers ... highly desirable
as an option..
I'm not sure the JWS code was quite the right model; as I recall it
could change _back_ to root (administrative restart) which isn't the
most secure way to go. In principle, I'd like the option; but in a
"no servlet component can _possibly_ grab root privs" mode. Also,
it should be a general purpose class, not specific to jakarta code.
Yes, there's a slot for switching UID in my tomcat startup script,
but filling it in hasn't gotten to my priority list yet.
I'd have to check, but I seem to recall another issue in that area.
It was along the lines of needing to be able to switch the port and
docroot on the command line, without munging "server.xml". If KHTTPD
isn't available (wrong kernel or somesuch) then tomcat needs to switch
over and use a different port. A few weeks ago, I seem to recall that
I believed port switching (and associated UID switch issue) didn't seem
like it could be done without changing "server.xml" ... undesirable.
- Dave
Re: Feature: port 80
Posted by Craig McClanahan <cm...@mytownnet.com>.
Jason Hunter wrote:
> One feature I haven't seen mentioned oddly enough is the ability for
> Tomcat standalone to listen on port 80 under Unix as a non-root user.
> JWS did this using native code to change the user id after attaching to
> the socket. What's the feeling out there of providing that native code
> to Tomcat for standalone use?
>
> -jh-
>
Feature: port 80
Posted by Jason Hunter <jh...@acm.org>.
One feature I haven't seen mentioned oddly enough is the ability for
Tomcat standalone to listen on port 80 under Unix as a non-root user.
JWS did this using native code to change the user id after attaching to
the socket. What's the feeling out there of providing that native code
to Tomcat for standalone use?
-jh-
--
Jason Hunter
jhunter@acm.org
Book: http://www.servlets.com/book
2.0 to 2.1: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
2.1 to 2.2: http://www.javaworld.com/jw-10-1999/jw-10-servletapi.html
Re: Patch to WARConnection.java to remove compile error.
Posted by James Todd <ja...@eng.sun.com>.
the intent is that when serving contents from a war directly
(vs internal exapansion) the mime types specified in the
associated web.xml file must be accounted for when resolving
URLConnection.getContentType() invocations.
my thoughts, as transcribed from my whiteboard, are:
create a "war manager" which will server as a
bridge between the hosting context and serving
war connection handler. the war manager can/should
cache the zip file and provide the war connection
handler a reference to the context specified (web.xml)
mime types.
all of the above was placed on the shelf due to more
pending and critical items. that said, i'm confident that
running from a compressed war is achievable. some
other items to keep in mind are:
DefaultServlet needs to generalize the welcome file
and directory listing methods to work for both
expanded and compressed war enviroments
hope this helps,
- james
"Preston L. Bannister" wrote:
> Commented out a unused function containing a compile error.
>
> Index: src/share/org/apache/tomcat/protocol/WARConnection.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/protocol/WARC
> onnection.java,v
> retrieving revision 1.1.1.1
> diff -u -b -r1.1.1.1 WARConnection.java
> --- WARConnection.java 1999/10/09 00:20:47 1.1.1.1
> +++ WARConnection.java 1999/11/09 19:18:32
> @@ -150,12 +150,14 @@
> }
> }
>
> +/* XXX -- Not compilable and not used. What was the intent here?
> public String getContentType() {
> // XXX
> // hmmm .. what about the mimeTypes associated with
> // this context
> return getFileNameMap().getContentTypeFor(path);
> }
> +XXX */
>
> public int getContentLength() {
> Long l = new Long(this.size);
>
> --
> Preston L. Bannister
> http://members.home.com/preston
> preston@home.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org