DO NOT REPLY [Bug 35336] - RFE: JK 1.2.13 (isapi_redirect) should be able to bypass IIS authentication, patch provided

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35336


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-07-03 11:31 ---
You should use the proper configuration for IIS. If the authorization is
required, then you should set that with IIS. It will be handled with
Tomcat.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35336] New: - RFE: JK 1.2.13 (isapi_redirect) should be able to bypass IIS authentication, patch provided

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35336>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35336

   Summary: RFE: JK 1.2.13 (isapi_redirect) should be able to bypass
IIS authentication, patch provided
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


With JK 2.0.4 it was possible to handle authentication completely within the 
webapp (for example using jCIFS) as if the tomcat http connector would be used. 
The virtual directory "jakarta" is configured to do no (basic/windows) 
authentication (i.e. anonymous). 
With JK 1.2.13 I was not able to configure the same behaviour. IIS/JK 1.2.13 
interferes with the authentication process. Authentication headers which should 
be forwarded to tomcat are removed from the request.
It should be possible to authenticate using tomcat/webapp means independent 
from 
the used connector (http or JK). That means for example the tomcat manager 
could 
be simply used over IIS/JK without doing any extra authentication configuration 
and/or usermanagement at IIS side. The userdatabase would be conf\tomcat-users.
xml. Tomcat users could use IIS, but keep the authentication process within 
Tomcat. I found some mails in the tomcat-users mailinglist about authentication 
probs with JK/IIS, so I assume this RFE would be also useful for others.

It seems when a IIS version before IIS 5 is recognized, IIS/JK will not 
interfere with authentication process. Tomcat or the webapp could do 
authentication undisturbed.
I have made a modification to jk_isapi_plugin.c, which will provide the 
functionality for doing this for me.

With this modification ISAPI_redirect will operate as if an IIS Version before 
5 
is recognized but only if the registry key 
Software\Apache Software Foundation\Jakarta Isapi Redirector\1.
0\bypass_iis5_auth = '1' exists. Without this key the modification has no 
effect, so this should not break current installations.

Could someone apply this patch or at least the functionality to the JK codebase?
Please feel free to change the patch code, if it does not fit source code 
requirements. (I am not a C developer)

*** jk-1.2.13-src\jk\native\iis\jk_isapi_plugin.c 2005-05-15 13:10:12.0 
+-0200
--- jk-1.2.13-src\jk\native\iis\jk_isapi_plugin_modified.c 2005-06-08 11:31:38.
0 +-0200
***
*** 64,69 
--- 64,71 
  #define REGISTRY_LOCATION   ("Software\\Apache Software 
Foundation\\Jakarta Isapi Redirector\\1.0")
  #define EXTENSION_URI_TAG   ("extension_uri")
  
! #define BYPASS_IIS5_AUTH   ("bypass_iis5_auth")
! 
  #define URI_SELECT_TAG  ("uri_select")
  #define URI_SELECT_PARSED_VERB  ("parsed")
  #define URI_SELECT_UNPARSED_VERB("unparsed")
***
*** 120,125 
--- 122,128 
  static int is_inited = JK_FALSE;
  static int is_mapread = JK_FALSE;
  static int iis5 = -1;
+ static int bypass_iis5 = 0;
  
  static jk_uri_worker_map_t *uw_map = NULL;
  static jk_logger_t *logger = NULL;
***
*** 694,699 
--- 697,706 
  iis5 = (atof(serverSoftware + 14) >= 5.0);
  if (iis5) {
  jk_log(logger, JK_LOG_DEBUG, "Detected IIS >= 5.0");
+   if (bypass_iis5) {
+   jk_log(logger, JK_LOG_DEBUG, "bypass_iis5_auth>0 set 
iis5=0")
;
+   iis5 = 0;
+   }
  }
  else {
  jk_log(logger, JK_LOG_DEBUG, "Detected IIS < 5.0");
***
*** 1323,1328 
--- 1330,1343 
  }
  }
  
! if (get_registry_config_parameter(hkey,
!   BYPASS_IIS5_AUTH,
!   tmpbuf, sizeof(tmpbuf))) {
!   if (tmpbuf[0]>'0')  {
!   bypass_iis5=1;
!   }
! }
! 
  RegCloseKey(hkey);
  }
  return ok;

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: rfe

[Yoav Shapira]

Hi,
First, please don't cross-post to both tomcat-user and tomcat-dev.

>  I was wondering if any one other than me has had the need to use a run-
> time
> 'before-bootstrapping' and 'cleaning-after-at-the-very-end' type of
> functionality.

If I do, there are other places for this that don't require hacking.  They
include the LifecycleListeners you can attach to Tomcat's containers, webapp
ServletContextListeners, class static initializers, and the JVM's shutdown
hooks.  Because all these are present, I don't think your RFE is needed by a
lot of people (if any, except you), so I wouldn't be gung-ho about adding it
to Tomcat.

Yoav


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

rfe

[Albretch Mueller]

 I was wondering if any one other than me has had the need to use a run-time
'before-bootstrapping' and 'cleaning-after-at-the-very-end' type of
functionality.

 I have been using it all along in my webapps and I think it is really
useful to the point that, it should be included in the Tomcat as a
'standard' hack or extra functionality.

 I have used it primarily to:
 1._ read in at run time security sensitive settings that I am not
comfortable with declaring in server.xml, web.xml or in any other config
file in the file system (yes, I am a healthy paranoid (I have plenty of
reasons to be like that))
 2._ to create RAM based tables for session handling using hsqldb (you
should still save your sessions in the back end and reload them to the front
end ram based tables)

 This is what I have been doing the monkey way:

 1._ "gone to the source" org.apache.catalina.startup.BootStrap.main and
  1.1_ inserted my code right after the method signature to make sure
absolute nothing has been previously staged by the VM
  1.2_ with the necessary import declarations if needed
  1.3_ recompile and jarred everything as 'bootstrap02.jar'

 2._ removed 'bootstrap.jar' and placed 'bootstrap02.jar' in
$CATALINA_HOME/bin/

 3._ commented out the 'CLASSPATH' setting in catalina.[bat|sh]
rem set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\bootstrap.jar
#
CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar:"$CATALINA_HOME"/b
in/commons-logging-api.jar

 changing 'bootstrap.jar' for 'bootstrap02.jar'

 4._ the line in which the JVM process is started

exec "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
  -classpath "$CLASSPATH" \
  -Dcatalina.base="$CATALINA_BASE" \
  -Dcatalina.home="$CATALINA_HOME" \
  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
  org.apache.catalina.startup.Bootstrap "$@" start

 or something similar depending on how you startup TC should be echoed (this
should be standard too)

 Interface EntryExit{
  public boolean doFirst();
  public boolean doLast();
 }

 then a class -which name should be convened upon-, say '_firstandlast',
should implement the EntryExit interface and used at tomcat bootstrapping
process as a command object and then discarded.

 If possible, no trace should be left of this object in memory and only its
actions/secondary effects should be staged for this run time only. This is
not an object to keep around

 Then people could code around inside of the doFirst() method of this
command object, which will be invoked at startup and doLast() which will be
invoked when TC shuts down

 If TC does not find this object at startup/shutdown it simply bypasses the
step in either ...Bootstrap.class or at the very end of the code segment of
org.apache.catalina.startup.Catalina$CatalinaShutdownHook(?) when
_firstandlast.doLast() should be called.

 I guess I could just do it myself in TC source code, but it is better if we
just spec out the feature and tell our hearts for people keeping a mental
map of this code base to give it some thoughts and streamline this feature,
some issues would be security relating to differing contexts and class
loaders ones.

 lbrtchx



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)





--- Additional Comments From [EMAIL PROTECTED]  2004-10-05 06:42 ---
further observations that may help others:
1) when setting CATALINA_OPTS="-verbose:gc" I see about 300 garbage collections:
[GC 18619K->3026K(260160K), 0.0217930 secs]
[GC 19218K->3011K(260160K), 0.0047730 secs]
[GC 19191K->3011K(260160K), 0.0033220 secs]
[GC 19203K->3013K(260160K), 0.0039100 secs]
[GC 19205K->3100K(260160K), 0.0047540 secs]
[GC 19292K->3125K(260160K), 0.0045940 secs]
[GC 19316K->3143K(260160K), 0.0042910 secs]
[GC 19328K->3167K(260160K), 0.0043550 secs]
...
[GC 19654K->3458K(260160K), 0.0009390 secs]
[Full GC 12290K->3530K(260160K), 0.0917670 secs]
[GC 19784K->3811K(260224K), 0.0043500 secs]
...
[GC 20465K->4217K(260224K), 0.0011250 secs]
[GC 20471K->4215K(260224K), 0.0010260 secs]
[GC 20466K->4222K(260224K), 0.0010590 secs]
[GC 20478K->4242K(260224K), 0.0013500 secs]

2) when running jprobe memorydebugger, it ends up with excessive memory use and
swapping such that a warm reboot of the machine is more promising than waiting
for the console to respond on simple key entries ... ([EMAIL PROTECTED] from
JProbe support suspects unpack=false to be the main culprit)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)





--- Additional Comments From [EMAIL PROTECTED]  2004-09-24 13:52 ---
Even if it is the problem (which I'm not sure of), it will be very difficult to
"fix".
I'd like to point out that the regular file based stuff creates as many of these
exceptions, and, generally, Struts webapps startup is extremely slow.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)

[EMAIL PROTECTED] changed:

   What|Removed |Added

URL||http://jakarta.apache.org/to
   ||mcat/tomcat-5.0-
   ||doc/config/host.html#Standar
   ||d Implementation



--- Additional Comments From [EMAIL PROTECTED]  2004-09-24 13:01 ---
my tomcat server has 4 servlets loaded multiple times by 3 connectors (in 3
different wars).

In order not to have to clean after these instances I put unpackwar=false.
As a minor security consideration, each time less the files are on the disk, the
smaller is the exposure (albeit an informed attacker would anyway be most
interested in the ./work/*/_* directories).

Anyway, being aware that this would reduce startup, time, I was surprised about
the accelerated deterioration of startup time as my application and the number
of jsp's grew. It's roughly 300 struts-related classes and 300 jsps. On an intel
machine one generation behind, it easily took 5 minutes or more to start,
especially, the super.init() method of the four servlets took ages.
As per the attached screenshot, I guess the reason for this is the unpackwar
that throws over 10'000 (probably planned?) exceptions (WARDir*...) and might
unpack the war many times.

RFE:

If these assumptions are right, I suggest to enhance the documentation at the
above URL to inform the tomcat administrator about these implications.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-09-24 12:56 ---
Let's not waste anyone's time with this "quality" metric. If you want to suggest
changes, please provide patches.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)





--- Additional Comments From [EMAIL PROTECTED]  2004-09-24 12:44 ---
Created an attachment (id=12856)
startUp.png quality analyzer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31405] New: - [Documentation RFE] unpackwar implications (slow startup)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)

   Summary: [Documentation RFE] unpackwar implications (slow
startup)
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RFE: Basic auth jmx http adapter

[Rainer Jung]

Hi,

I append a small patch, including the necessary features to support basic
and digest authentication for the mx4j JMX http connector.

The way the http adaptor is initialized in JkMX.java today gives no
possibility to restrict access to it. Since the JMX console is very
powerful
I included code n JkMx.java to parse 3 additional configuration options
from jk2.properties to the connector:

mx.authMode
mx.authUser
mx.authPassword

The patch is very local and simple. It is based on the newest version of
JkMX.java. Thank for considering.

Rainer Jung

% diff -w -c JkMX.java.orig JkMX.java
*** JkMX.java.orig  Thu Jun 17 21:03:20 2004
--- JkMX.java   Sun Aug 29 14:16:35 2004
***
*** 39,44 
--- 39,47 
  private boolean enabled=false;
  private int httpport=-1;
  private String httphost="localhost";
+ private String authmode="none";
+ private String authuser=null;
+ private String authpassword=null;
  private int jrmpport=-1;
  private String jrmphost="localhost";
  private boolean useXSLTProcessor = true;
***
*** 86,91 
--- 89,118 
  return httphost;
  }
  
+ public void setAuthMode(String mode) {
+ authmode=mode;
+ }
+ 
+ public String getAuthMode() {
+ return authmode;
+ }
+ 
+ public void setAuthUser(String user) {
+ authuser=user;
+ }
+ 
+ public String getAuthUser() {
+ return authuser;
+ }
+ 
+ public void setAuthPassword(String password) {
+ authpassword=password;
+ }
+ 
+ public String getAuthPassword() {
+ return authpassword;
+ }
+ 
  /** Enable the MX4J JRMP internal adapter
   */
  public void setJrmpPort( int i ) {
***
*** 162,167 
--- 189,205 
  mserver.setAttribute(httpServerName, new Attribute("Host", 
httphost));
  mserver.setAttribute(httpServerName, new Attribute("Port", new 
Integer(httpport)));
  
+ if( authmode!=null  && ( "none".equals(authmode) || 
"basic".equals(authmode) || "digest".equals(authmode) ) )
+ mserver.setAttribute(httpServerName, new 
Attribute("AuthenticationMethod", authmode));
+ 
+ if( authuser!=null && authpassword!=null )
+ mserver.invoke(httpServerName, "addAuthorization",
+ new Object[] {
+ authuser,
+ authpassword},
+ new String[] { "java.lang.String", "java.lang.String" });
+ 
+ 
  if(useXSLTProcessor) {
  ObjectName processorName = 
registerObject("mx4j.tools.adaptor.http.XSLTProcessor",
"Http:name=XSLTProcessor");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RFE mod_jk: cookie session tracking for load balancing with sub-domains

[Sandy McArthur]

I'm happy with the latest change to get_cookie but there is one more 
problem I've found.

We, UF, have a convention of putting production services at 
http://service.ufl.edu/ and testing beta services at 
http://test.service.ufl.edu/ .

This causes a problem with cookie based session tracking which I partly 
blame on the cookie spec. The problem is the http://service.ufl.edu/ 
JSESSIONID cookie is made available to the http://test.service.ufl.edu/ 
webapp. What happens is mod_jk takes the first JSESSIONID cookie and 
uses that for picking the jvmroute. Since the lb clusters in our 
test.service setups are smaller it's not possible for all the jvmroutes 
from the production to map to the test jvmroutes. In this case it's 
random where mod_jk sends the request and users can't get past the 
login page since their requests aren't being sent to the right clone.

What mod_jk should do is check all JSESSIONID cookies for a known 
jvmroute and use one that matches instead of just using the first one. 
(I believe I checked the source to Tomcat 5.something and it did the 
right thing in the case of many JSESSIONID cookies, so that part is 
fine.)

The problem comes from the cookie spec 
http://wp.netscape.com/newsref/std/cookie_spec.html stating that "When 
sending cookies to a server, all cookies with a more specific path 
mapping should be sent before cookies with less specific path 
mappings." but it's silent on the order of cookies when it comes to 
more specific domains. It seems Mozilla orders cookies based on the 
domain but IE doesn't. Sadly, most users use IE.

Sandy McArthur

smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 25245] - [RFE] it should be possible to stop/start/reload web-apps

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=25245>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25245

[RFE] it should be possible to stop/start/reload web-apps

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 11:20 ---
Without patches, this will not be implemented (no current Tomcat developer seems
willing to implement this).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25245] - [RFE] it should be possible to stop/start/reload web-apps

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25245>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25245

[RFE] it should be possible to stop/start/reload web-apps

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
Product|Tomcat 4|Tomcat 5
Version|4.1.29  |5.0.16

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25245] New: - [RFE] it should be possible to stop/start/reload web-apps

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25245>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25245

[RFE] it should be possible to stop/start/reload web-apps

   Summary: [RFE] it should be possible to stop/start/reload web-
apps
   Product: Tomcat 4
   Version: 4.1.29
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

it should be possible to be abled to start/stop/reload web-apps from the
tomact-administrator.
the reason is simple: in order to start/stop/reload a web-app, you have to have
a context for the manager-app on every host. that's not what an admin wants. for
example if there needs to be a servlet that need to handle _every_ request on /.
the admin-app is usually accessible through a different http1.1-host.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12605] New: - [RFE] text/xml mime type not listed in default web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12605>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12605

[RFE] text/xml mime type not listed in default web.xml

   Summary: [RFE] text/xml mime type not listed in default web.xml
   Product: Tomcat 4
   Version: 4.1.10
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I was having Tomcat serve up xml pages and I couldn't figure out why, in 
response wrapper used in my filter that the setContentType(String) that I was 
overriding was never getting called.

Turns out that Tomcat's default servlet doesn't call setContentType(String) 
unless a mime-type has been defined in either Tomcat's conf/web.xml or the 
webapps's WEB-INF/web.xml.  I didn't have it defined in my own webapp because I 
assumed that such a common file type would have been already listed in 
conf/web.xml.  When I added the text/xml mime type to my own web.xml, 
everything worked as expected.

I propose that, at the very least, the following mime types get added to 
Tomcat's conf/web.xml to avoid future confusion ...


xml
text/xml



xsl
text/xml


Jake

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>