date:20030113

what places can I define  in?
actually casting request as HttpRequest seems to work fine,
((HttpRequest)request).getContext().getManager() seems to be just dandy :)

but I would still like where I can define valve, you are saying I can define
it under a specific context and under the entire engine for all requests?

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net

>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Monday, January 13, 2003 8:42 PM
>To: Tomcat Developers List
>Subject: Re: Valve question
>
>
>
>
>On Mon, 13 Jan 2003, Filip Hanik wrote:
>
>> Date: Mon, 13 Jan 2003 20:00:13 -0800
>> From: Filip Hanik <[EMAIL PROTECTED]>
>> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
>> To: Tomcat Developers List <[EMAIL PROTECTED]>
>> Subject: Valve question
>>
>> hi,
>> is it possible from the valve to get hold of the Manager for the
>context the
>> request is in?
>>
>> getContainer().getManager() returns null in the invoke method.
>> Filip
>>
>>
>
>If the Valve making this call is associated with the Context itself, this
>should work fine.  If the Valve making this call is associated with an
>Engine or a Host, the appropriate Context won't have been identified yet,
>so getManager() will fail.  Where is the Valve you are trying this from?
>
>Craig
>
>
>
>--
>To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Valve question

2003-01-13 Thread Craig R. McClanahan

On Mon, 13 Jan 2003, Filip Hanik wrote:

> Date: Mon, 13 Jan 2003 20:00:13 -0800
> From: Filip Hanik <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Valve question
>
> hi,
> is it possible from the valve to get hold of the Manager for the context the
> request is in?
>
> getContainer().getManager() returns null in the invoke method.
> Filip
>
>

If the Valve making this call is associated with the Context itself, this
should work fine.  If the Valve making this call is associated with an
Engine or a Host, the appropriate Context won't have been identified yet,
so getManager() will fail.  Where is the Valve you are trying this from?

Craig

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16049] - jsp compiler doesn't create directory structure that matches package name

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16049

jsp compiler doesn't create directory structure that matches package name





--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 04:00 ---
Created an attachment (id=4414)
patch

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Valve question

hi,
is it possible from the valve to get hold of the Manager for the context the
request is in?

getContainer().getManager() returns null in the invoke method.
Filip


~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16049] New: - jsp compiler doesn't create directory structure that matches package name

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16049

jsp compiler doesn't create directory structure that matches package name

   Summary: jsp compiler doesn't create directory structure that
matches package name
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


example 1
jspc.sh -uriroot .  -p com.mycompany -d /outdir  bar.jsp
creates bar_jsp.java in /outdir instead in /outdir/com/mycompany 

example 2
jspc.sh -uriroot .  -p com.mycompany -d /outdir  jsp/bar.jsp
creates bar_jsp.java in /outdir/jsp instead in /outdir/com/mycompany 

Also -dd option behaves exactly the same as -d

Proposed patch brings behaviour of jspc in tomcat-4.1.18 in line
with tomcat-3.3 in respect to output directory.

After applying the patch, and running either example, generated bar_jsp_java is 
created in /outdir/com/mycompany 

Running either example with -dd instead of -d will put the file in /outdir

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

2003-01-13 Thread Glenn Nielsen

Remy Maucherat wrote:

Remy Maucherat wrote:


Glenn Nielsen wrote:

With a few details. I may be against the change which adds POST 
support; I don't know what it does, and it adds a dependency. I'm 
reviewing all changes to the 4.1.x branch, at the moment (and that big 
patch is giving me trouble).


I do see what it does now. This is fancy.


Thanks. This should make life easier for sysads who do application
web hosting for multiple virtual hosted customers. :-)


There's a dumb bug which prevents correct startup of the default 
configuration. This seems quite obvious. Did you test the patch 
extensively ?


Looks like you fixed that bug from your commit.  Yes, I tested it on
my system with my config.  But I don't have Windows.  So today a coworker
did some more exhaustive testing on windows and with different configs.
Plus did a review of the docs. :-)  I fixed a couple more bugs and made
some minor updates to the docs.

The manager changes look pretty stable now.

I'll start work on porting them to Tomcat 5.


Sorry, I should have mentioned that I was working on the manager and
the bug fixes required one method addition to the interface for 
Deployer.

I will port the changes to Tomcat 5.



Indeed, you must do that.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 13205] - Tomcat Web Application Manager; config parameter is not null.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13205

Tomcat Web Application Manager; config parameter is not null.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 13205] - Tomcat Web Application Manager; config parameter is not null.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13205

Tomcat Web Application Manager; config parameter is not null.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 03:08 ---
Thanks for reporting this.  The xml context config is optional and
the NPE has been fixed.  This will be available in the next Tomcat 4.1 release.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 5629] - web.xml is not re-read using manager reload

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5629

web.xml is not re-read using manager reload

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 03:06 ---
The updated documenation will be available in the next Tomcat 4.1 release.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 5629] - web.xml is not re-read using manager reload

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5629

web.xml is not re-read using manager reload

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 03:06 ---
Thanks for reporting this.  The documentation for the web application
manager has been updated to note that a reload does not check the web.xml
and reload it.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 13893] - /manager/install ... add a /manager/uninstall

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13893

/manager/install ... add a /manager/uninstall

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 13893] - /manager/install ... add a /manager/uninstall

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13893

/manager/install ... add a /manager/uninstall

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 03:04 ---
Thanks for reporting this. In general the manager application has been
overhauled. The manager /remove has been enhanced to remove
the web application temporary work directory. This will be available in the
next Tomcat 4.1 release.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 8969] - Manager - remove does not delete the webapps/application/ Dir

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=8969

Manager - remove does not delete the webapps/application/ Dir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 8969] - Manager - remove does not delete the webapps/application/ Dir

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=8969

Manager - remove does not delete the webapps/application/ Dir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 03:00 ---
The manager has been patched so that it will remove the web application
directory and/or war file if it exists in the Host appBase and either
the Host autoDeploy=true or liveDeploy=true.

Thanks for reporting this.

The bug fix will be in the next Tomcat 4.1 release.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 7826] - ManagerServlet response is garbled

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=7826

ManagerServlet response is garbled

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 7826] - ManagerServlet response is garbled

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=7826

ManagerServlet response is garbled

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 02:58 ---
Thanks for reporting this. I have committed a patch which makes sure
setContentType includes the localized charset.  It should be in the
next release of Tocmat 4.1.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime BodyContentImpl.java

2003-01-13 Thread luehe

luehe   2003/01/13 17:56:05

  Modified:jasper2/src/share/org/apache/jasper/runtime
BodyContentImpl.java
  Log:
  Removed redundant 'isBodyContent' and added comment about 'bufferSizeSave'
  
  Revision  ChangesPath
  1.8   +24 -19
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
  
  Index: BodyContentImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- BodyContentImpl.java  10 Oct 2002 15:33:29 -  1.7
  +++ BodyContentImpl.java  14 Jan 2003 01:56:05 -  1.8
  @@ -83,13 +83,7 @@
   // Enclosed writer to which any output is written
   private Writer writer;
   
  -/*
  - * Indicates whether this BodyContentImpl is returned as the result of a
  - * call to JspContext.pushBody(java.io.Writer) (FALSE) or
  - * PageContext.pushBody() (TRUE)
  - */
  -private boolean isBodyContent;
  -
  +// See comment in setWriter()
   private int bufferSizeSave;
   
   /**
  @@ -505,10 +499,10 @@
* @throws IOException If an I/O error occurs
*/
   public void clear() throws IOException {
  - if (isBodyContent) {
  - nextChar = 0;
  - } else {
  + if (writer != null) {
throw new IOException();
  + } else {
  + nextChar = 0;
}
   }
   
  @@ -521,7 +515,9 @@
* @throws IOException If an I/O error occurs
*/
   public void clearBuffer() throws IOException {
  -if (isBodyContent) this.clear();
  +if (writer == null) {
  + this.clear();
  + }
   }
   
   /**
  @@ -544,7 +540,7 @@
* @return the number of bytes unused in the buffer
*/
   public int getRemaining() {
  - return isBodyContent ? bufferSize-nextChar : 0;
  + return (writer == null) ? bufferSize-nextChar : 0;
   }
   
   /**
  @@ -555,7 +551,7 @@
* @return the value of this BodyJspWriter as a Reader
*/
   public Reader getReader() {
  - return isBodyContent ? new CharArrayReader (cb, 0, nextChar) : null;
  + return (writer == null) ? new CharArrayReader (cb, 0, nextChar) : null;
   }
   
   /**
  @@ -566,7 +562,7 @@
* @return the value of the BodyJspWriter as a String
*/
   public String getString() {
  - return isBodyContent ? new String(cb, 0, nextChar) : null;
  + return (writer == null) ? new String(cb, 0, nextChar) : null;
   }

   /**
  @@ -578,7 +574,7 @@
* evaluation
*/
   public void writeOut(Writer out) throws IOException {
  - if (isBodyContent) {
  + if (writer == null) {
out.write(cb, 0, nextChar);
// Flush not called as the writer passed could be a BodyContent and
// it doesn't allow to flush.
  @@ -600,11 +596,20 @@
   void setWriter(Writer writer) {
this.writer = writer;
if (writer != null) {
  - isBodyContent = false;
  - bufferSizeSave = bufferSize;
  - bufferSize = 0;
  + // According to the spec, the JspWriter returned by 
  + // JspContext.pushBody(java.io.Writer writer) must behave as
  + // though it were unbuffered. This means that its getBufferSize()
  + // must always return 0. The implementation of
  + // JspWriter.getBufferSize() returns the value of JspWriter's
  + // 'bufferSize' field, which is inherited by this class. 
  + // Therefore, we simply save the current 'bufferSize' (so we can 
  + // later restore it should this BodyContentImpl ever be reused by
  + // a call to PageContext.pushBody()) before setting it to 0.
  + if (bufferSize != 0) {
  + bufferSizeSave = bufferSize;
  + bufferSize = 0;
  + }
} else {
  - isBodyContent = true;
bufferSize = bufferSizeSave;
clearBody();
}
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15105

pushBody()/popBody() error on tomcat 4.1.12

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 00:32 ---
Notice that the behaviour your are experiencing indeed used to be a
bug, but it's been fixed.

In Tomcat 4.1.x, any BodyContent that is being reused is cleared in
the generated servlet code right after the call to pushBody(), like
this:

 javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
 _bc.clear();
 out = _bc;
 _jspx_th_xxx.setBodyContent(_bc);
 _jspx_th_xxx.doInitBody();

In Tomcat 5, the contents of a reused BodyContent are cleared inside
of org.apache.jasper.runtime.BodyContentImpl.setWriter(), so the
BodyContent returned by pushBody() has already been cleared.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16030] - Incorrected error message generated when jsp:body is used to provide the body of a jsp:attribute action

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16030

Incorrected error message generated when jsp:body is used to provide the body of a 
jsp:attribute action

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16027] - Misleading error message generated when jsp:body is nested within another jsp:body element.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16027

Misleading error message generated when jsp:body is nested within another jsp:body 
element.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties

2003-01-13 Thread kinman

kinman  2003/01/13 15:50:48

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
  Log:
  - Fix 15851, 16027, and 1600: output appropiate message when a jsp:attribute
or jsp:body is nested in another jsp:attribute or jsp:body.
  
  Revision  ChangesPath
  1.56  +14 -9 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- Parser.java   11 Jan 2003 00:51:36 -  1.55
  +++ Parser.java   13 Jan 2003 23:50:48 -  1.56
  @@ -1568,10 +1568,6 @@
   err.jspError( reader.mark(), "jsp.error.not.in.template",
"Expression language" );
   } else if (reader.matches("mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs manager-howto.xml

glenn   2003/01/13 15:25:45

  Modified:webapps/tomcat-docs manager-howto.xml
  Log:
  Trim down the length of the install source
  
  Revision  ChangesPath
  1.20  +3 -3  jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml
  
  Index: manager-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- manager-howto.xml 13 Jan 2003 21:13:54 -  1.19
  +++ manager-howto.xml 13 Jan 2003 23:25:45 -  1.20
  @@ -416,15 +416,15 @@
   Here is an example of installing an application using a Context
   configuration ".xml" file.
   
  -http://localhost:8080/manager/install?config=file:/path/to/context.xml
  +http://localhost:8080/manager/install?config=file:/path/context.xml
   
   
   
   Here is an example of installing an application using a Context
   configuration ".xml" file and a web application ".war" file located
   on the server.
  -  
  
-http://localhost:8080/manager/install?config=file:/path/to/context.xml&war=jar:file:/path/to/bar.war!/
  +
  
+http://localhost:8080/manager/install?config=file:/path/context.xml&war=jar:file:/path/bar.war!/
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java

glenn   2003/01/13 15:23:28

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
  Log:
  Fix a bug when appBase was relative, fix remove of work dir when Context already 
stopped
  
  Revision  ChangesPath
  1.13  +26 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- StandardHostDeployer.java 13 Jan 2003 17:34:25 -  1.12
  +++ StandardHostDeployer.java 13 Jan 2003 23:23:28 -  1.13
  @@ -79,6 +79,7 @@
   import org.apache.catalina.Lifecycle;
   import org.apache.catalina.LifecycleException;
   import org.apache.catalina.LifecycleListener;
  +import org.apache.catalina.core.StandardContext;
   import org.apache.catalina.startup.ContextRuleSet;
   import org.apache.catalina.startup.ExpandWar;
   import org.apache.catalina.startup.NamingRuleSet;
  @@ -251,6 +252,9 @@
   // Determine if directory/war to install is in the host appBase
   boolean isAppBase = false;
   File appBase = new File(host.getAppBase());
  +if (!appBase.isAbsolute())
  +appBase = new File(System.getProperty("catalina.base"),
  +host.getAppBase());
   File contextFile = new File(docBase);
   File baseDir = contextFile.getParentFile();
   if (appBase.getCanonicalPath().equals(baseDir.getCanonicalPath())) {
  @@ -522,6 +526,9 @@
   // Determine if directory/war to remove is in the host appBase
   boolean isAppBase = false;
   File appBase = new File(host.getAppBase());
  +if (!appBase.isAbsolute())
  +appBase = new File(System.getProperty("catalina.base"),
  +   host.getAppBase());
   File contextFile = new File(context.getDocBase());
   File baseDir = contextFile.getParentFile();
   if (appBase.getCanonicalPath().equals(baseDir.getCanonicalPath())) {
  @@ -532,7 +539,6 @@
   if (contextFile.getName().toLowerCase().endsWith(".war")) {
   isWAR = true;
   }
  -
   // Only remove directory and/or war if they are located in the
   // Host's appBase and autoDeploy or liveDeploy are true
   if (isAppBase && (host.getAutoDeploy() || host.getLiveDeploy())) {
  @@ -563,6 +569,21 @@
   }
   
   // Remove the work directory for the Context
  +if (workDir == null &&
  +context instanceof StandardContext &&
  +((StandardContext)context).getWorkDir() != null) {
  +workDir = new File(((StandardContext)context).getWorkDir());
  +if (!workDir.isAbsolute()) {
  +File catalinaHome = new 
File(System.getProperty("catalina.base"));
  +String catalinaHomePath = null;
  +try {
  +catalinaHomePath = catalinaHome.getCanonicalPath();
  +workDir = new File(catalinaHomePath,
  +   
((StandardContext)context).getWorkDir());
  +} catch (IOException e) {
  +}
  +}
  +}
   if (workDir != null && workDir.exists()) {
   deleteDir(workDir);
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Connector-HOWTO

2003-01-13 Thread Amy Roh

Bishr Tabbaa wrote:

Tomcat-Dev,

I am trying to develop my own connector for Tomcat 4.x.  I have strived to
follow the programmatic conventions in the Coyote package such that my
package contains a connectorimpl, connectionprocessorimpl,
servletoutputstreamimpl, servletinputstream, requestimpl, and responseimpl.
I added an entry to server.xml, started tomcat, and encountered the
following error:

ServerLifecycleListener: createMBeans: MBeanException
java.lang.Exception: ManagedBean is not found with VigilentConnector
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:224
)
...
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

Then, I added an entry to 'mbeans-descriptors.xml' inside catalina.jar
associating an MBean with my connector.



  

I started tomcat again and encountered the following error:

ServerLifecycleListener: createMBeans: Throwable
javax.management.MalformedObjectNameException: Cannot create object name for
com.netiq.servlet.VigilentConnector@3db503
at
org.apache.catalina.mbeans.MBeanUtils.createObjectName(MBeanUtils.jav
a:873)
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:231
)

at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

I looked at the 4.1.18 src code of MBeanUtils.java and discovered that the
instanceof operator is applied to concrete classes!  I prefer not to change
the source, but it appears that this is the only available fork in the road.
Is there something that I am missing?


You'll have to change createObjectName for connectors to handle your 
specific connector if you like JMX support as you can see if you looked 
at the code.  Even if you do that, admin webapp won't be able to support 
editing your own connector since it's connector specific.  You can fully 
disable JMX by commenting out Listeners if you don't want to change any 
code.

Amy


Thanks,
Bishr

-
Bishr Tabbaa
NetIQ Corporation
1233 West Loop South # 1800
Houston, TX 77027
Toll Free: 1-888-400-2834
Fax:   713-523-6393
Direct:713-860-9726
Mobile:832-651-0610
[EMAIL PROTECTED]
- 
Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  Thank you.  NetIQ, Inc.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: JSR77 names for Context ( and ServletWrapper )

2003-01-13 Thread Amy Roh

Costin Manolache wrote:

I'm not very familiar with the /admin - how difficult 
would it be to change the naming format for Contexts ? 

It's not TOO difficult.  You'll need to change createObjectName() for 
context in MBeanUtils and also in context actions classes so that they 
query for the right mbean name.  There're quiet a few places... :-(


JSR77 defines some pretty clear names for Context and Servet -
and I think we should use that where possible. 

Another issue I have is the name of the Valves, which uses
the hashcode of the valve object. I would preffer to have 
an easier form - a counter indicating the position of the valve
in the chain ( unique for the container where the valve is attached ).

same for valves.



Again - need help with the /admin.

Finally, the issue of "domain". In JSR77 ( and in general ) 
the domain can be used to create separate namespaces - and I think
the "domain" should match the engine name and the jsrRoute. That
would simplify a lot:
 - a domain represents a particular tomcat Engine. 
 - each engine must have a unique identifier
 - this will be used for load balancing ( as jvmRoute - no longer separate 
config )
 - it will also be visible in the JMX console. Assuming remote-JMX
is supported - each tomcat will be visible in a separate domain.
 - you can have multiple Engines in the same VM ( just like today ),
but each will have a separate domain and will be completely separated
from each other.

Not sure if the /admin is using the domain somehere.

I don't think admin uses domain currently.



Opinions ? Anyone willing to help ? 

I'm willing to help if you send new mbean name formats for context and 
valves.  I can't promise anything quick since I'm in the middle of 
different things.  :-)

Thanks,
Amy



Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 






--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16044] New: - problems with gifs and jpegs - HTML are ok

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16044

problems with gifs and jpegs - HTML are ok

   Summary: problems with gifs and jpegs - HTML are ok
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,
I installed tomcat 4.1.18 this morning.  I have been unable to display gif 
files or jpegs on my website, although I can display HTML files.
Thanks
Mikael

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java

2003-01-13 Thread costin

costin  2003/01/13 14:08:58

  Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
  Log:
  NPE with empty files
  
  Revision  ChangesPath
  1.20  +4 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
  
  Index: PageDataImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- PageDataImpl.java 5 Dec 2002 17:56:43 -   1.19
  +++ PageDataImpl.java 13 Jan 2003 22:08:58 -  1.20
  @@ -611,6 +611,7 @@
 * within the given text, so it can be included in a CDATA section.
 */
private String escapeCDATA(String text) {
  +if( text==null ) return "";
int len = text.length();
CharArrayWriter result = new CharArrayWriter(len);
for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail:

ServletException and JDK1.4

2003-01-13 Thread Costin Manolache

Could we change the ServletException class to pass up the Throwable ?
This way JDK1.4 getCause() and the better stack trace would work.


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

2003-01-13 Thread Costin Manolache

Jeanfrancois Arcand wrote:

>>Actually - this is a different story ( JMX-enabling different componets).
>>I'll check in similar additions to ValveBase, BaseContainer,
>>CoyoteConnector.
>>
> Humm..I would like to be able to support hooks/Valves also using one
> approach. I'm not an expert with JMX, but it seems we can do it.

Regardless of the hook type - all components should know their name and
domain and should know when they are registered - so MBeanRegistration must
be implemented in all root components.

> StandardPipeline and ValveBase can be ported to support JMX notification
> also. We can add support for JMX notification in ValveContext.next() or
> port that method inside StandardPipeline and then use JMX notification
> without making major design change (the Digester will register the Valve
> mostly the same way, but this time using the jmx NotificationListener
> interface ). That should "JMX"-enabled StandardPipeline and valve that
> extends ValveBase

The main problem - the notification in JMX works in the same way as 
Event/Listener - i.e. iterate over listeners and call each one. 
Valves are recursive, each valve calls the next. I don't want to reopen
the discussion on what's better - we ( tomcat-dev) know both are valid and 
we agreed to disagree on this :-) That's why I added the recursive 
mechansim in BaseHook.

We could register Vavles using addNotification - and even modify modeler
to support both models ( right now it supports none - notification doesn't
seem to be completely implemented ). Not sure it's a big priority - but
if you have the time it would be great to at least see how it looks.

>>I'm ok with that too. Valves have a Next - and I assumed many people
>>preffer this model ( and it involves fewer interfaces :-).
>>My only requirement is to be able to use it in iterative mode too
>>( I don't like the long stack traces and I feel better with iterative).
>>
> It is ValveContext that have a next :-), which is similar to an
> HandlerChain (Pipeline is starting the process, ValveContext is doing
> the rest).

I have a bad habbit to try to simplify some things :-) ( bad because 
sometimes things need to be complex - and it takes a lot of time ).
Doesn't matter how many classes are involved in this procept - the
concept is that you have a list and each element calls the next.

>>For configuration: I would be -1 for any new API / tomcat-specific config
>>format.
>>  
>>
> Then my question is: how do we specify, as an example, that the JSR 115
> authorization valve should be invoked before, let say, JNDI
> authorization valve? We are currently doing that implicitly in
> server.xml, but all valves are associated with the same pipeline
> implementation (or I'm missing something here). I would like to be able
> to configure more that one chain (one for connector, one for valve,
> etc.). As an example, an  may have a different chain behaviour
> than a  element when an exception occurs.

There are 2 ( or 3 ) solutions:

- explicit Chain MBean. You configure each module as a MBean, and you have 
one Chain MBean, where you specify the names of each mbean. A variation - in 
modeler we could add some modeler-specific mbean to control the 
notification chain of each modeled mbean. 

- next ( or "after" ) attribute in the valve. Something like that is done in 
jk2. You configure the JSR115 mbean, the JNDIAuth mbean - and you specify
the name of the first in the "after" attribute of the second. The base class
can easily take care of this - it'll just jmx.invoke "setNext".

 (???)

Of course, things get interesting if you want to insert ( or remove ) 
mbeans at runtime ( without completely stoping the server if possible ).
Both mechanisms support that ( with either sync or with a "server pause"). 

>>All configuration should be done using JMX. I have no doubt about
>>it ( well, JMX has its limitations, but the general model of
>>manageable components with light coupling is essential ).
>>
> I agree.

>>Instead of param-name/value - use JMX attributes. The handler is a JMX
>>component. For registration - I think we should use the standard JMX
>>notifications ( or your proposed API if JMX proves too complicated or
>>we can't get around its limitations )
>>
> That's true. But where do we get the initial value of those objects?

Configurable objects == mbeans.
You configure and name them, then use the reference ( name ) in the 
chain mbean configuration.

>>We could use a Chain MBean component where you declare ( as attributes )
>>the various hooks in the chain. ActionCode will correspond to a Chain.
>>That may be very nice - allowing hooks to be inserted at runtime, etc.
>>
> This is where I would like to go. Being able to set hooks at runtime
> using some descriptors. Or have an extension folder where JMX enabled
> hooks will be discovered and added, by default, to the end of the chain.

I like discovery - but for the server I preffer some explicit configuration.
Ei

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs html-manager-howto.xml manager-howto.xml

glenn   2003/01/13 13:13:55

  Modified:webapps/tomcat-docs html-manager-howto.xml manager-howto.xml
  Log:
  Minor grammar fixes to docs
  
  Revision  ChangesPath
  1.3   +19 -20jakarta-tomcat-4.0/webapps/tomcat-docs/html-manager-howto.xml
  
  Index: html-manager-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/html-manager-howto.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- html-manager-howto.xml12 Jan 2003 17:26:46 -  1.2
  +++ html-manager-howto.xml13 Jan 2003 21:13:54 -  1.3
  @@ -15,12 +15,10 @@
   
   
   
  -In many production environments, it is very useful to have the capability
  -to manage your web applications without having to shut down and restart the
  -entire Tomcat container.  The manager web
  -application provides this capability. This documentation is for the HTML web
  -interface version of the manager which makes administering web applications
  -easier.
  +In many production environments it is very useful to have the capability
  +to manage your web applications without having to shut down and restart
  +Tomcat.  This document is for the HTML web interface to the web application
  +manager.
   
   The interface is divided into five sections:
   
  @@ -41,9 +39,9 @@
   
   
   Displays information about the success or failure of the last web application
  -manager command you performed. If it suceeded OK is displayed
  +manager command you performed. If it succeeded OK is displayed
   and may be followed by a success message. If it failed FAIL
  -is displayed followed by an error message. Common failure messages will be
  +is displayed followed by an error message. Common failure messages are
   documented below for each command.  The complete list of failure messages for
   each command can be found in the manager web
   application documentation.
  @@ -105,7 +103,7 @@
   Signal a stopped application to restart, and make itself available again.
   Stopping and starting is useful, for example, if the database required by
   your application becomes temporarily unavailable.  It is usually better to
  -stop the web application that relies on this database, rather than letting
  +stop the web application that relies on this database rather than letting
   users continuously encounter database exceptions.
   
   If this command succeeds, you will see a Message like this:
  @@ -190,7 +188,8 @@
   /WEB-INF/lib directory.
   
   NOTE: The /WEB-INF/web.xml
  -web application configuration file is not reread on a reload.
  +web application configuration file is not checked on a reload;
  +the previous web.xml configuration is used.
   If you have made changes to your web.xml file you must stop
   then start the web application.
   
  @@ -240,7 +239,7 @@
   
   
   WARNING - This command will delete the
  -contents of the web application directory and/or ".war fileif it exists within
  +contents of the web application directory and/or ".war" file if it exists within
   the appBase directory (typically "webapps") for this virtual host
   .  The web application temporary work directory is also deleted.  If
   you simply want to take an application out of service, you should use the
  @@ -292,7 +291,7 @@
   on the Tomcat server or you can upload a web application archive (WAR)
   file to the server.
   
  -To install an application fill in the appropriate fields for the type
  +To install an application, fill in the appropriate fields for the type
   of install you want to do and then submit it using the Install
   button.
   
  @@ -307,9 +306,9 @@
   Install a Directory or WAR by URL
   
   Install a web application directory or ".war" file located on the Tomcat
  -server. If no Context Path: is specified the directory name or the
  +server. If no Context Path is specified, the directory name or the
   war file name without the ".war" extension is used as the path. The
  -WAR or Directory URL: specifies a URL (including the file:
  +WAR or Directory URL specifies a URL (including the file:
   scheme) for either a directory or a web application archive (WAR) file. The
   supported syntax for a URL referring to a WAR file is described on the Javadocs
   page for the java.net.JarURLConnection class.  Use only URLs that
  @@ -337,10 +336,10 @@
   Install a Directory or War from the Host appBase
   
   Install a web application directory or ".war" file located in your Host
  -appBase directory. If no Context Path: is specified the directory name
  +appBase directory. If no Context Path is specified the directory name
   or the war file name without the ".war" extension is used as the path.
   
  -In this example the web application located in a sub directory named
  +In this example the web application located in a subdirectory named
   foo in the Host appBase directory of the Tomcat server is
   installed as the web applicat

DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15672

DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 20:40 ---
It does work indeed. At least the MySQL setup. My bad part was that I didn't
notice the  and  were not included
in the  but were its siblings because the  tag line
was long and didn't wrap.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

[JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteBaseHook.java

2003-01-13 Thread Jeanfrancois Arcand

Sorry for the delay

Costin Manolache wrote:


Jeanfrancois Arcand wrote:

 

Hi Costin, (you beat me on the proposal :-) )
   


Actually - this is a different story ( JMX-enabling different componets).
I'll check in similar additions to ValveBase, BaseContainer, 
CoyoteConnector.

Humm..I would like to be able to support hooks/Valves also using one 
approach. I'm not an expert with JMX, but it seems we can do it.


The idea is for each component to be aware of its name and domain, 
and to "bridge" whatever notification/hook mechanism into JMX
notifications.

I don't think we need an additional extension mechansim - for all
that I need I think JMX notifications are good enough. I don't
know how hard ( or usefull ) it is to bridge all existing extension
points, but at least the connector should be able to send JMX notifications
and it can easily use this model for its own needs.

StandardPipeline and ValveBase can be ported to support JMX notification 
also. We can add support for JMX notification in ValveContext.next() or 
port that method inside StandardPipeline and then use JMX notification 
without making major design change (the Digester will register the Valve 
mostly the same way, but this time using the jmx NotificationListener 
interface ). That should "JMX"-enabled StandardPipeline and valve that 
extends ValveBase




 

what about having a concept of a chain somewhere (meaning hooks chain
(handler :-) ). This way handler doesn't need to know which comes next
(or previous), but the handler chain knows it. What I was having in mind
was being able to define somewhere:
   


I'm ok with that too. Valves have a Next - and I assumed many people 
preffer this model ( and it involves fewer interfaces :-).
My only requirement is to be able to use it in iterative mode too
( I don't like the long stack traces and I feel better with iterative).

It is ValveContext that have a next :-), which is similar to an 
HandlerChain (Pipeline is starting the process, ValveContext is doing 
the rest).


For configuration: I would be -1 for any new API / tomcat-specific config
format.
 

Then my question is: how do we specify, as an example, that the JSR 115 
authorization valve should be invoked before, let say, JNDI 
authorization valve? We are currently doing that implicitly in 
server.xml, but all valves are associated with the same pipeline 
implementation (or I'm missing something here). I would like to be able 
to configure more that one chain (one for connector, one for valve, 
etc.). As an example, an  may have a different chain behaviour 
than a  element when an exception occurs.


All configuration should be done using JMX. I have no doubt about
it ( well, JMX has its limitations, but the general model of 
manageable components with light coupling is essential ).

I agree.



Instead of param-name/value - use JMX attributes. The handler is a JMX 
component. For registration - I think we should use the standard JMX 
notifications ( or your proposed API if JMX proves too complicated or
we can't get around its limitations )

That's true. But where do we get the initial value of those objects?



We could use a Chain MBean component where you declare ( as attributes )
the various hooks in the chain. ActionCode will correspond to a Chain.
That may be very nice - allowing hooks to be inserted at runtime, etc.


This is where I would like to go. Being able to set hooks at runtime 
using some descriptors. Or have an extension folder where JMX enabled 
hooks will be discovered and added, by default, to the end of the chain.




 


  

   



 

Using that information, an HandlerChainDispatcher can generically load
that information and then instanciate the proper HandlerChain/Handler.
In the code, that will result in

public interface HandlerChain{
   public void addHandler(Handler);
   public void addHandler(int index, Handler);
   public boolean contains(Handler);
   public boolean  handle(HandlerChainContext);
// remove handler(Handler)
}
   


+0 - sounds good, but I would rather use NotificationBroadcaster :-)
( or some specialized version in modeler - to get around Filters ).
 

True. Filtering will certaintly be a performance hit... the question is 
do we want to be able to fully support jmx notification mechanism or 
part of it (by skipping the filter invokation). In modeler, you seems to 
have a solution for the filtering invocation. Have you make some test to 
see if it is faster?




 

public interface Handler{
   public boolean handle(HandlerContext);
   public void setHandlerInfo(HandlerInfo);   // Same as ActionCode
   public HandlerInfo getHandlerInfo(HandlerInfo);
  
   public void init();
   public void destroy()
   public void recycle();
}
   


Again - I would rather use 

interface javax.management.NotificationListener {
 handleNotification( Notification n, Object handBack );
}
 

I agree. The concept stay the same, but we should use JMX 
NotifcationListener for implementing the concept.

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java

2003-01-13 Thread luehe

luehe   2003/01/13 12:09:46

  Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
  Log:
  Added support for new 'version' attribute of  element, which
  has been added in JSP 2.0 to replace the  subelement
  
  Revision  ChangesPath
  1.32  +10 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- TagLibraryInfoImpl.java   18 Dec 2002 23:18:21 -  1.31
  +++ TagLibraryInfoImpl.java   13 Jan 2003 20:09:44 -  1.32
  @@ -248,11 +248,16 @@
   // Create an iterator over the child elements of our  element
   ParserUtils pu = new ParserUtils();
   TreeNode tld = pu.parseXMLDocument(uri, in);
  -Iterator list = tld.findChildren();
  +
  + // Check to see if the  root element contains a 'version'
  + // attribute, which was added in JSP 2.0 to replace the 
  + // subelement
  + this.jspversion = tld.findAttribute("version");
   
   // Process each child element of our  element
  -while (list.hasNext()) {
  +Iterator list = tld.findChildren();
   
  +while (list.hasNext()) {
   TreeNode element = (TreeNode) list.next();
   String tname = element.getName();
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java

glenn   2003/01/13 11:51:55

  Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java
  Log:
  Fix form action misspelling which crept in during final interface tweaks
  
  Revision  ChangesPath
  1.15  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- HTMLManagerServlet.java   11 Jan 2003 01:17:31 -  1.14
  +++ HTMLManagerServlet.java   13 Jan 2003 19:51:55 -  1.15
  @@ -442,7 +442,7 @@
   args = new Object[7];
   args[0] = sm.getString("htmlManagerServlet.installTitle");
   args[1] = sm.getString("htmlManagerServlet.installServer");
  -args[2] = response.encodeURL(request.getContextPath() + "/html/intall");
  +args[2] = response.encodeURL(request.getContextPath() + "/html/install");
   args[3] = sm.getString("htmlManagerServlet.installPath");
   args[4] = sm.getString("htmlManagerServlet.installConfig");
   args[5] = sm.getString("htmlManagerServlet.installWar");
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 19:42 ---
According to the spec, the release() method is guaranteed to be called on any 
tag handler, this is to say, even when the tag handler instance is pooled, it 
still should invoke release() to release any state the tag handler may posess.

In my case, I have a tag handler super class that needs to get a state value 
from session and set it for the child class to construct business view object. 
I agree that it is feasible to clean it up in doStartTag() since my tag is not 
an iteration tag. But still it would be ideal to use release() to clean up 
private invocation-specific state.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16034] - doAfterBody is not called in iterating tag

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16034

doAfterBody is not called in iterating tag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 19:41 ---
Works for me.

I added this line

  pageContext.getOut().print("DO_AFTER_BODY CALLED!");

to your tag handler's doAfterBody() implementation, and did get the expected
output. What makes you believe that doAfterBody() is not being called?
Note that in order for doAfterBody() to be called, your custom action must *not*
be empty.

As an aside, since your tag handler already extends BodyTagSupport, it
automatically implements IterationTag.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 18:52 ---
The following is regarding bug 16031:

I assume you are referring to the tag handler's release() method when you talk
about resetting its state?

Note that according to the spec, the release() method is guaranteed to
be called on any tag handler, "but there may be multiple invocations
on doStartTag() and doEndTag() in between."

Therefore, your tag handler should not rely on its release() method to
reset any private invocation-specific state. This state is best
initialized in doStartTag(). This means that in your specific example, you
should clear your "key" and "value" objects in your tag handler's doStartTag()
method.

See important tips for tag-handler lifecycle management at

 http://jakarta.apache.org/taglibs/guidelines.html

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 18:40 ---
*** Bug 16031 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16031] - Custom tag pools does not reset its handler state when returned to pool.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16031

Custom tag pools does not reset its handler state when returned to pool.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 18:40 ---


*** This bug has been marked as a duplicate of 16001 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: jdk support in Tomcat 5

>If possible, it would be nice to also have fallback code - i.e. code that
>works ( slower ) on JDK1.3.

yes it is, it should be in there now, but that code is dog slow and only
works for small clusters :)

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net

>-Original Message-
>From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Costin Manolache
>Sent: Monday, January 13, 2003 10:02 AM
>To: [EMAIL PROTECTED]
>Subject: Re: jdk support in Tomcat 5
>
>
>Filip Hanik wrote:
>
>> hi there,
>> I am rewriting the session replication for tomcat 5 to be more efficient.
>> Can I use jdk1.4 features such as java.nio packages for that ?
>
>Sure. Just make sure conditional compilation will work ( i.e. someone with
>JDK1.3 will still be able to build tomcat ).
>
>If possible, it would be nice to also have fallback code - i.e. code that
>works ( slower ) on JDK1.3.
>
>Costin
>
>
>--
>To unsubscribe, e-mail:
>
>For additional commands, e-mail:
>
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16034] New: - doAfterBody is not called in iterating tag

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16034

doAfterBody is not called in iterating tag

   Summary: doAfterBody is not called in iterating tag
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My code goes like this:

public class ListElementsTag extends BodyTagSupport implements IterationTag {
   ...
   public int doStartTag() throws JspException {
   ...
   return (EVAL_BODY_INCLUDE);
   }

   public int doAfterBody() throws JspException {
   ...
   return (EVAL_BODY_AGAIN);
   }
}

Because no variables are created, no TEI exists.

To my understanding, doAfterBody() should be called automatically, because 
doStartTag returns EVAL_BODY_INCLUDE.

But doAfterBody() is never called!

This worked flawlessly under Tomcat 4.0.6.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: jdk support in Tomcat 5

2003-01-13 Thread Costin Manolache

Filip Hanik wrote:

> hi there,
> I am rewriting the session replication for tomcat 5 to be more efficient.
> Can I use jdk1.4 features such as java.nio packages for that ?

Sure. Just make sure conditional compilation will work ( i.e. someone with 
JDK1.3 will still be able to build tomcat ). 

If possible, it would be nice to also have fallback code - i.e. code that
works ( slower ) on JDK1.3.

Costin

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

2003-01-13 Thread remm

remm2003/01/13 09:57:57

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  1.47  +66 -7 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- RELEASE-NOTES-4.1.txt 12 Jan 2003 17:26:46 -  1.46
  +++ RELEASE-NOTES-4.1.txt 13 Jan 2003 17:57:56 -  1.47
  @@ -117,6 +117,9 @@
Added support for using an alternateURL if a socket connection
can not be made to the provider at the connectionURL.
   
  +[4.1.19] CoyoteConnector:
  + Add HTTP/1.1 GZIP compression support.
  +
   
   ---
   Jasper New Features:
  @@ -169,6 +172,7 @@
compile so that it is run in a different JVM from the one Tomcat
is running in. Please refer to the Jasper-HOWTO for more information.
   
  +
   ==
   BUG FIXES AND IMPROVEMENTS:
   ==
  @@ -225,6 +229,10 @@
See the Manager App HOW-TO and HTML Manager App HOW-TO
documentation for more information.
   
  +[4.1.19] Administration Webapp:
  + Add a check for empty validation query before setting it.
  +
  +
   --
   Catalina Bug Fixes:
   --
  @@ -590,6 +598,35 @@
DataSourceRealm:
Fixed the Realm-HOWTO docs for the DataSourceRealm.
   
  +[4.1.19] #10383
  + Ajp13:
  + Fix hanging Ajp13Processor and web server request when invalid 
  + Cookie sent. An HTTP status code 400 - Bad Request is now returned.
  +
  +[4.1.19] ApplicationFilterConfig:
  + Wrap filter initialization with swallow output.
  +
  +[4.1.19] #15819
  + StandardServer:
  + Don't write out listeners for StandardDefaultContext.
  +
  +[4.1.19] #15762
  + StandardServer:
  + Filter special characters in DataSource URL.
  +
  +[4.1.19] #15890
  + DefaultServlet:
  + Invalid date headers should be ignored.
  +
  +[4.1.19] ManagerBase:
  + Add code to guarantee uniqueness of a session ID (even though the
  + probability that this event occurs is negligible, some people feel
  + more comfortable with that code enabled).
  +
  +[4.1.19] RequestFilterValve:
  + Catch null pointer property to match on, deny by default if found.
  +
  +
   
   Coyote Bug Fixes:
   
  @@ -734,10 +771,24 @@
JK 2 CoyoteHandler:
Fix NPE occurring in SSL mode.
   
  -[4.1.19] #10383
  - Ajp13
  - Fix hanging Ajp13Processor and web server request when invalid Cookie sent.
  - An HTTP status code 400 - Bad Request is now returned.
  +[4.1.19] ActionCode:
  + Fix incorrect number which could cause bad matching.
  +
  +[4.1.19] HTTP/1.1 Http11Processor:
  + Fix case sensitivity matching of some special header values, which 
  + could prevent HTTP/1.0 keep alive with some clients.
  +
  +[4.1.19] PoolTcpEndpoint:
  + Fix incorrect handling when an exception occurs during a SSL 
  + handshake.
  +
  +[4.1.19] PoolTcpEndpoint:
  + More robust socket restart code for the case where an exception occurs
  + during an accept.
  +
  +[4.1.19] ThreadPool:
  + Remove thread from active thread list when it ends.
  +
   
   
   Jasper Bug Fixes:
  @@ -964,8 +1015,16 @@
Background Thread Recompile:
Fixed a thread synchronization bug which could cause the thread which
does background JSP recompiles (development=false) to die.
  -
  - 
  +
  +[4.1.19] #14200
  + TldLocationCache:
  + TLDs under WEB-INF are not scanned for URI mappings.
  +
  +[4.1.19] JspWriterImpl:
  + Remove custom flushing, which caused client disconnects to log
  + stack traces with Jasper.
  +
  +
   
   KNOWN ISSUES IN THIS RELEASE:
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: jdk support in Tomcat 5

Filip Hanik wrote:

hi there,
I am rewriting the session replication for tomcat 5 to be more efficient.
Can I use jdk1.4 features such as java.nio packages for that ?


+1.
Cluster is a separate module, so I'm fine with that dependency.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

jdk support in Tomcat 5

hi there,
I am rewriting the session replication for tomcat 5 to be more efficient.
Can I use jdk1.4 features such as java.nio packages for that ?

thanks
Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld

2003-01-13 Thread kinman

kinman  2003/01/13 09:36:14

  Modified:jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld
  Log:
  - Undo the patch, as it was unnecessary.
  
  Revision  ChangesPath
  1.3   +0 -1  
jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld
  
  Index: jsp2-example-taglib.tld
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jsp2-example-taglib.tld   10 Jan 2003 18:21:38 -  1.2
  +++ jsp2-example-taglib.tld   13 Jan 2003 17:36:13 -  1.3
  @@ -6,7 +6,6 @@
   version="2.0">
   A tag library exercising SimpleTag handlers.
   1.0
  -2.0
   SimpleTagLibrary
   /SimpleTagLibrary
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

Remy Maucherat wrote:

Glenn Nielsen wrote:

With a few details. I may be against the change which adds POST support; 
I don't know what it does, and it adds a dependency. I'm reviewing all 
changes to the 4.1.x branch, at the moment (and that big patch is giving 
me trouble).

I do see what it does now. This is fancy.
There's a dumb bug which prevents correct startup of the default 
configuration. This seems quite obvious. Did you test the patch 
extensively ?

Sorry, I should have mentioned that I was working on the manager and
the bug fixes required one method addition to the interface for Deployer.

I will port the changes to Tomcat 5.


Indeed, you must do that.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java

2003-01-13 Thread remm

remm2003/01/13 09:34:26

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
  Log:
  - Fix bad test which causes a string out of bounds exception.
  
  Revision  ChangesPath
  1.12  +9 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- StandardHostDeployer.java 10 Jan 2003 15:52:18 -  1.11
  +++ StandardHostDeployer.java 13 Jan 2003 17:34:25 -  1.12
  @@ -271,9 +271,11 @@
   if (isWAR) {
   filename = filename.substring(0,filename.length()-4);
   }
  -if (contextPath.length() == 0 && !filename.equals("ROOT")) {
  -throw new IllegalArgumentException
  -(sm.getString("standardHost.pathMatch", "/", "ROOT"));
  +if (contextPath.length() == 0) {
  +if (!filename.equals("ROOT")) {
  +throw new IllegalArgumentException
  +(sm.getString("standardHost.pathMatch", "/", "ROOT"));
  +}
   } else if (!filename.equals(contextPath.substring(1))) {
   throw new IllegalArgumentException
   (sm.getString("standardHost.pathMatch", contextPath, filename));
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Craig R. McClanahan

On Mon, 13 Jan 2003, Michael Wyraz wrote:

> Date: Mon, 13 Jan 2003 16:00:45 +0100
> From: Michael Wyraz <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Strange Cookie behavior with ie 6 and subdomains
>
> Hi!
>
> I did the test:
> mozilla returns only one session-id per domain.
> ie returns both: the id of the parent domain and the new one.
>
> So it's not a browser bug. It's a tomcat bug ;-)
> I think tomcat (HttpProcessor.java?) has to be modified to
> check all of the session-ids returnd from the browser to find the
> right one.
>

The cookie spec (RFC 2109) says that if a browser has two cookies with the
same name and overlapping domains like this, they need to send the most
specific one first (i.e. the session cookie for test.mydomain.com before
the cookie for mydomain.com).  Tomcat relies on this behavior to get the
correct session id -- if the browser doesn't behave this way, the browser
is broken.

> My personal workaround (until the bug is fixed) is to move the content from 
>mydomain.com
> to www.mydomain.com. so the cookie does not conflict with the cookie
> from test.mydomain.com.
>
> Could one please add this bug to the bug database since i don't have an
> account there?
>

You can make your own account if you need to submit a but.

> Thanks a lot.
> Michael.

Craig

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

Glenn Nielsen wrote:



Remy Maucherat wrote:


I am grateful for the fixes introduced with the patch, however:
- could you please post something about modifying the base interfaces, 
before you actually do so ? The change was probably needed, but may 
break custom extensions.
- this is code which changes a lot of things; as such, it should have 
been committed in the development branch first.

Remy


Glad you like the changes and bug fixes. :-)


With a few details. I may be against the change which adds POST support; 
I don't know what it does, and it adds a dependency. I'm reviewing all 
changes to the 4.1.x branch, at the moment (and that big patch is giving 
me trouble).

Sorry, I should have mentioned that I was working on the manager and
the bug fixes required one method addition to the interface for Deployer.

I will port the changes to Tomcat 5.

If you feel that backward compatability of the Deployer interface in
Tomcat 4.1 is required, I can remove the new method from the Deployer
interface and change the ManagerServlet to use the new remove method
only if it detects an instance of StandardHostDeployer.


This part of the change looks like it's fixing an issue, so I think I am 
ok with it. This should be case by case, though (please don't try to 
sneak it in a big patch).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16032] New: - Not all attributes get copied when the request is forwarded

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16032

Not all attributes get copied when the request is forwarded

   Summary: Not all attributes get copied when the request is
forwarded
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The attribute "javax.servlet.request.X509Certificate" doesn't get copied with
the request when the request is forwarded. To reproduce it, follow these steps:

- Create an HTTPS connector and enable client authentication.

  


- Generate a CA certificate for the server:
> openssl -genrsa -out ca.key 1024
> openssl req -new -key ca.key -out ca.csr
> openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

- Import the CA certificate (ca.crt) to the tru sted CA certificates keystore in
your JVM:
> keytool -import -file ca.crt -keystore /lib/security/cacerts

- Generate a certificate to the client:
> openssl -genrsa -out client.key 1024
> openssl req -new -key client.key -out client.csr
> openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in
client.csr -out client.crt
(you may want to leave -CAcreateserial out).
> openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out
client.p12

- Import the client certificate and key (client.p12) into the browser.
- Import the CA certificate (ca.crt) into the browser.
- Generate a certificate for the server:
> keytool -genkey -keystore server.jks -alias tomcat

- Run the following servlet:

package test;

import javax.servlet.ServletException;
import javax.servlet.http.*;
import java.io.*;

public class TestCertServlet extends HttpServlet {

protected void service(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
Integer curTmp = (Integer)req.getAttribute("value");
int cur = curTmp == null ? 0 : curTmp.intValue()+1;

Object certs = req.getAttribute("javax.servlet.request.X509Certificate");
//System.out.println("Cur: "+cur+" - certs: "+certs);

if(cur==5) {
printInfo(res, req, cur);
return;
}

req.setAttribute("Other"+cur, "Set");
req.setAttribute("Certs"+cur, certs);
req.setAttribute("value", new Integer(cur));
this.getServletContext().getRequestDispatcher("/TestCert").forward(req,
res);
}

private void printInfo(HttpServletResponse res, HttpServletRequest req, int
cur) throws IOException {
PrintWriter w = res.getWriter();
w.write("Testing...");
for(int i=0; i"+i+"");
w.write("Other"+i+"="+req.getAttribute("Other"+i)+"");
w.write("Certs"+i+"="+req.getAttribute("Certs"+i)+"");
}
w.write("");
}
}

The output will be this:
0
Other0=Set
Certs0=[Ljava.security.cert.X509Certificate;@1ae939f

1
Other1=Set
Certs1=null
...

The attribute "javax.servlet.request.X509Certificate" is not set after the
request is forwarded. This makes our login schema fail, as we would always
forward the request to the login servlet if the user has not been authenticated
yet. Note that optionally we could redirect the page to the login servlet and
then redirect it back to the requested page after authentication, however as we
don't need any information from the user other than the certificate (already
sent in SSL handshake), there would be no need for redirection, as it would have
been the case if the user had to type his/her username and password.

Workaround

A quick fix for this problem is to set the attribute "again" in a filter for
everypage (refer to Solution to understand why):

public void doFilter(ServletRequest req, ServletResponse res, FilterChain
chain) throws IOException, ServletException {
req.setAttribute("javax.servlet.request.X509Certificate",
req.getAttribute("javax.servlet.request.X509Certificate"));
chain.doFilter(req, res);
}


Solution

The attribute "javax.servlet.request.X509Certificate" is set in a Request
object. This object is wrapped by a CoyoteRequest object, which is wrapped by
CoyoteRequestFacade. CoyoteRequestFacade only forwards all calls. CoyoteRequest
stores attribute sets to this object and getAttribute(String) first looks up on
its own attribute map and then forward the call to the Request. When the request
is forwarded, a ApplicationHttpRequest is created as the new request and it's
wrapped around the CoyoteRequestFacade. The ApplicationHttpRequest works a
little differ

DO NOT REPLY [Bug 16031] New: - Custom tag pools does not reset its handler state when returned to pool.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16031

Custom tag pools does not reset its handler state when returned to pool.

   Summary: Custom tag pools does not reset its handler state when
returned to pool.
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Custom tag pools does not reinitalize its handler state when it is returned to
the pool.

That is, we associate a value with a key for a custom tag. The problem comes the
next time the tag is reused, the associated value and its key still remains on
the handler tag, and thus the previous status is reused.

We think that when the tag work is finished and tomcat returns it to the custom
tag pool, it should be done a reset.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

2003-01-13 Thread Glenn Nielsen



Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:


glenn   2003/01/10 07:52:19

  Modified:.RELEASE-NOTES-4.1.txt build.properties.sample
   catalina build.xml
   catalina/src/share/org/apache/catalina Deployer.java
   catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardHost.java
StandardHostDeployer.java
   catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties ManagerServlet.java
   catalina/src/share/org/apache/catalina/startup
HostConfig.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties
   webapps/manager build.xml
   webapps/manager/WEB-INF web.xml
   webapps/tomcat-docs index.xml manager-howto.xml 
project.xml
   webapps/tomcat-docs/config host.xml
  Added:   catalina/src/share/org/apache/catalina/startup
ExpandWar.java
   webapps/tomcat-docs html-manager-howto.xml
  Log:
  Bug fixes and minor improvements to the manager and html manager web
  applications.  These patches fix as many of the 11 bugs I found for
  the manager in bugzilla that I could reproduce.


Glenn,

I am grateful for the fixes introduced with the patch, however:
- could you please post something about modifying the base interfaces, 
before you actually do so ? The change was probably needed, but may 
break custom extensions.
- this is code which changes a lot of things; as such, it should have 
been committed in the development branch first.

Remy


Glad you like the changes and bug fixes. :-)

Sorry, I should have mentioned that I was working on the manager and
the bug fixes required one method addition to the interface for Deployer.

I will port the changes to Tomcat 5.

If you feel that backward compatability of the Deployer interface in
Tomcat 4.1 is required, I can remove the new method from the Deployer
interface and change the ManagerServlet to use the new remove method
only if it detects an instance of StandardHostDeployer.

Regards,

Glenn


--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16030] New: - Incorrected error message generated when jsp:body is used to provide the body of a jsp:attribute action

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16030

Incorrected error message generated when jsp:body is used to provide the body of a 
jsp:attribute action

   Summary: Incorrected error message generated when jsp:body is
used to provide the body of a jsp:attribute action
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The JSP 2.0 specification states that a translation-time error must occur if
jsp:body is used to provide the body of a jsp:attribute action.

While Jasper does generate a translation-time error for this case, the error
message is incorrect:

"The action is not a recognizable standard action."

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:


glenn   2003/01/10 07:52:19

  Modified:.RELEASE-NOTES-4.1.txt build.properties.sample
   catalina build.xml
   catalina/src/share/org/apache/catalina Deployer.java
   catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardHost.java
StandardHostDeployer.java
   catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties ManagerServlet.java
   catalina/src/share/org/apache/catalina/startup
HostConfig.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties
   webapps/manager build.xml
   webapps/manager/WEB-INF web.xml
   webapps/tomcat-docs index.xml manager-howto.xml 
project.xml
   webapps/tomcat-docs/config host.xml
  Added:   catalina/src/share/org/apache/catalina/startup
ExpandWar.java
   webapps/tomcat-docs html-manager-howto.xml
  Log:
  Bug fixes and minor improvements to the manager and html manager web
  applications.  These patches fix as many of the 11 bugs I found for
  the manager in bugzilla that I could reproduce.


Glenn,

I am grateful for the fixes introduced with the patch, however:
- could you please post something about modifying the base interfaces, 
before you actually do so ? The change was probably needed, but may 
break custom extensions.
- this is code which changes a lot of things; as such, it should have 
been committed in the development branch first.

And actually, I missed the additional dependency added on fileupload.
It also seems you recoded install to respond to a POST, as well as 
duplicate the functionality of upload (it seems).

Maybe that seems good to you, but:
- this has not been discussed before
- the deployer behavior needs some thinking, and IMO consensus, to avoid 
making more mistakes, or ending in a jspc situation, where there are 
plenty of features nobody can or is willing to maintain anymore

I'll have to veto the patch until this gets discussed further.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15105

pushBody()/popBody() error on tomcat 4.1.12

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.1.12  |4.1.18



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 16:51 ---
I have reviewed 4.1.18 to see if this error has been fixed, but there is no
change. Is there any update about this bug ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

[EMAIL PROTECTED] wrote:

glenn   2003/01/10 07:52:19

  Modified:.RELEASE-NOTES-4.1.txt build.properties.sample
   catalina build.xml
   catalina/src/share/org/apache/catalina Deployer.java
   catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardHost.java
StandardHostDeployer.java
   catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties ManagerServlet.java
   catalina/src/share/org/apache/catalina/startup
HostConfig.java LocalStrings.properties
LocalStrings_fr.properties
LocalStrings_ja.properties
   webapps/manager build.xml
   webapps/manager/WEB-INF web.xml
   webapps/tomcat-docs index.xml manager-howto.xml project.xml
   webapps/tomcat-docs/config host.xml
  Added:   catalina/src/share/org/apache/catalina/startup
ExpandWar.java
   webapps/tomcat-docs html-manager-howto.xml
  Log:
  Bug fixes and minor improvements to the manager and html manager web
  applications.  These patches fix as many of the 11 bugs I found for
  the manager in bugzilla that I could reproduce.


Glenn,

I am grateful for the fixes introduced with the patch, however:
- could you please post something about modifying the base interfaces, 
before you actually do so ? The change was probably needed, but may 
break custom extensions.
- this is code which changes a lot of things; as such, it should have 
been committed in the development branch first.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Tim Funk

I still think its not a bug in tomcat. All servlet engines have this 
issue. I first suffered this same issue with Weblogic 2 years ago. The 
key is managing your domains or not using cookies to hold sessionid.

Anyone can enter a enhancement request into bugzilla since anyone may 
create a bugzilla account. If you supply a patch it has a better chance 
of being addressed, but you might have a hard argument to prove the 
patch does not open a security hole or cause another unintended session 
related bug.


-Tim

Michael Wyraz wrote:
Hi!

I did the test:
mozilla returns only one session-id per domain.
ie returns both: the id of the parent domain and the new one.

So it's not a browser bug. It's a tomcat bug ;-)
I think tomcat (HttpProcessor.java?) has to be modified to
check all of the session-ids returnd from the browser to find the
right one.

My personal workaround (until the bug is fixed) is to move the content from mydomain.com
to www.mydomain.com. so the cookie does not conflict with the cookie
from test.mydomain.com.

Could one please add this bug to the bug database since i don't have an account there?

Thanks a lot.
Michael.


On Mon, 13 Jan 2003 09:13:12 -0500, Tim Funk wrote:



If a cookie is set for mydomain.com. Then the cookie is also sent to:




www.mydomain.com
foo.mydomain.com
test.mydomain.com




If Mozilla is NOT doing that. Then Mozilla has a bug.




In reality - what is really happening is you have 2 cookies set:
One for test.mydomain.com and one for mydomain.com. It just so happens 
that Mozilla is sending both cookies in such a way that tomcat gets 
lucky and picks up the right one for sessionid. IE sends it an 
incompatiable (but probably correct) way. Who knows what happens if you 
try using Opera.



Write a test page from www.mydomain.com and dump all your request 
headers and you'll probably see that you are getting sent 2 jsessionid 
cookies.




-Tim




[...]





--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16028] New: - JNI safety framework mechanism required

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16028

JNI safety framework mechanism required

   Summary: JNI safety framework mechanism required
   Product: Tomcat 5
   Version: 5.0.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

   I would like the following officially clarified. Please think on it .. don't
just close the issue as INVALID.

   Specifically, it is impossible to *safely* use JNI under Tomcat 4.x (I assume
the same is true for 5.x) because of a JVM limitation whereby a native shared
library may only be loaded once per JVM. This leads to the following problem:

- class A uses library L
- Since Tomcat makes use of multiple classloaders and might load the same bean
multiple times in different classloaders, System.loadLibrary() (which is
required for JNI) might get executed multiple times across different classloaders.
- This isn't a problem if we know for a fact that the old bean was unloaded
before the new one was loaded. I believe the shared library is unloaded with the
old instance.
- Sun's Bug Parades suggests the only way to solve this problem is to make sure
that across all classloaders, all instances of class A make use of a utility
class B which does the actual System.loadLibrary() call. It is suggested that
the developer guarantee that class B (System.loadLibrary()) is only loaded once
per JVM whereas class A may be loaded multiple times in multiple classloaders.
That is, as long as class B is loaded in a parent classloader to class A's
classloader everything will be fine. Furthermore, only one instance of B may
exist per JVM.
- The problem with the above workaround is that Tomcat provides no framework
mecanism that guarantees JNI library loaders (as mentioned above as class B)
will only be loaded once.
- I urge you to contact Sun engineers for more details so you're aware of all
the issues before responding.

Thank you,
Gili

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15904] - UnsupportedEncodingException not thrown if invalid charset (from content type) is set and a call to ServletResponse.getWriter() is made.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15904

UnsupportedEncodingException not thrown if invalid charset (from content type) is set 
and a call to ServletResponse.getWriter() is made.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 15:05 ---
Fixed in CVS (a few days ago).

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16026] - Tag's body appears inside other tags

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16026

Tag's body appears inside other tags





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 15:04 ---
try turning off tag pooling and see if you still have this problem.  You are 
probably not handling your tags correctly.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Michael Wyraz

Hi!

I did the test:
mozilla returns only one session-id per domain.
ie returns both: the id of the parent domain and the new one.

So it's not a browser bug. It's a tomcat bug ;-)
I think tomcat (HttpProcessor.java?) has to be modified to
check all of the session-ids returnd from the browser to find the
right one.

My personal workaround (until the bug is fixed) is to move the content from 
mydomain.com
to www.mydomain.com. so the cookie does not conflict with the cookie
from test.mydomain.com.

Could one please add this bug to the bug database since i don't have an account there?

Thanks a lot.
Michael.

On Mon, 13 Jan 2003 09:13:12 -0500, Tim Funk wrote:

>If a cookie is set for mydomain.com. Then the cookie is also sent to:

>www.mydomain.com
>foo.mydomain.com
>test.mydomain.com

>If Mozilla is NOT doing that. Then Mozilla has a bug.

>In reality - what is really happening is you have 2 cookies set:
>One for test.mydomain.com and one for mydomain.com. It just so happens 
>that Mozilla is sending both cookies in such a way that tomcat gets 
>lucky and picks up the right one for sessionid. IE sends it an 
>incompatiable (but probably correct) way. Who knows what happens if you 
>try using Opera.

>Write a test page from www.mydomain.com and dump all your request 
>headers and you'll probably see that you are getting sent 2 jsessionid 
>cookies.

>-Tim

[...]

DO NOT REPLY [Bug 16027] New: - Misleading error message generated when jsp:body is nested within another jsp:body element.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16027

Misleading error message generated when jsp:body is nested within another jsp:body 
element.

   Summary: Misleading error message generated when jsp:body is
nested within another jsp:body element.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the case described in the summary, a translation error is generated, but
error message returned by the translation time error is misleading:

   "jsp:body must be the subelement of a standard or custom action"

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16026] New: - Tag's body appears inside other tags

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16026

Tag's body appears inside other tags

   Summary: Tag's body appears inside other tags
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have some custom tags that worked fine in tomcat 3. When moving to tomcat 4 
our pages got corrupted. It looks as if the buffer of a tag is not cleared and 
popups in different tags accross the page. I am using the BodyTag interface and 
have a tag that functions as an iterator.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Tim Funk

If a cookie is set for mydomain.com. Then the cookie is also sent to:

www.mydomain.com
foo.mydomain.com
test.mydomain.com

If Mozilla is NOT doing that. Then Mozilla has a bug.

In reality - what is really happening is you have 2 cookies set:
One for test.mydomain.com and one for mydomain.com. It just so happens
that Mozilla is sending both cookies in such a way that tomcat gets
lucky and picks up the right one for sessionid. IE sends it an
incompatiable (but probably correct) way. Who knows what happens if you
try using Opera.

Write a test page from www.mydomain.com and dump all your request
headers and you'll probably see that you are getting sent 2 jsessionid
cookies.

-Tim

Michael Wyraz wrote:
Hi!

The user _is_ on the correct domain. The problem is, that
the browser does not recognize, that "test.mydomain.com"
and "mydomain.com" are different.
BTW: Mozilla doesn't have this bug...

On Mon, 13 Jan 2003 08:54:54 -0500, Tim Funk wrote:

[
This is more suited for tomcat-user
Please post followups to: [EMAIL PROTECTED]
]

This is not isolated to IE6 but all browsers. If you are using apache -
add the appropriate redirects to your httpd config to force the user to
the correct domain.

-Tim

Michael Wyraz wrote:

Hi!

I found a strange bug in internet explorer cookie handling that could possibile
workarounded in tomcat:

I have 2 different webapps on 2 different domains (a domain and a subdomain of this domain), e.g.:
mydomain.com
test.mydomain.com

When I enter the first domain, a session cookie for this domain is set.
The session then works fine for this domain.
Then I view a page from the second domain. IE returns the cookie
that was set in the first domain. Tomcat does'nt know that session id
in the second context and sets a new cookie.
Now the strange thing: The new Cookie is never returned from ie. So the
new Session in the second domain is not valid and after each click a
new SessionID is generated (i think IE always returns the cookie set in the first domain).

A possible solution:
If the name of the session cookie would be configurable (per host or per webapp),
the hostname could added to that cookie. This would fix this issue on IE.

Michael.

--
To unsubscribe, e-mail:
For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Michael Wyraz

Hi!

The user _is_ on the correct domain. The problem is, that
the browser does not recognize, that "test.mydomain.com"
and "mydomain.com" are different.
BTW: Mozilla doesn't have this bug...

On Mon, 13 Jan 2003 08:54:54 -0500, Tim Funk wrote:

>[
>This is more suited for tomcat-user
>Please post followups to: [EMAIL PROTECTED]
>]

>This is not isolated to IE6 but all browsers. If you are using apache - 
>add the appropriate redirects to your httpd config to force the user to 
>the correct domain.

>-Tim

>Michael Wyraz wrote:
>> Hi!
>> 
>> I found a strange bug in internet explorer cookie handling that could possibile
>> workarounded in tomcat:
>> 
>> I have 2 different webapps on 2 different domains (a domain and a subdomain of this 
>domain), e.g.:
>> mydomain.com
>> test.mydomain.com
>> 
>> When I enter the first domain, a session cookie for this domain is set.
>> The session then works fine for this domain.
>> Then I view a page from the second domain. IE returns the cookie
>> that was set in the first domain. Tomcat does'nt know that session id
>> in the second context and sets a new cookie.
>> Now the strange thing: The new Cookie is never returned from ie. So the
>> new Session in the second domain is not valid and after each click a
>> new SessionID is generated (i think IE always returns the cookie set in the first 
>domain).
>> 
>> A possible solution:
>> If the name of the session cookie would be configurable (per host or per webapp),
>> the hostname could added to that cookie. This would fix this issue on IE.
>> 
>> Michael.
>> 
>> 



>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail:

Re: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Tim Funk

[
   This is more suited for tomcat-user
   Please post followups to: [EMAIL PROTECTED]
]

This is not isolated to IE6 but all browsers. If you are using apache - 
add the appropriate redirects to your httpd config to force the user to 
the correct domain.

-Tim

Michael Wyraz wrote:
Hi!

I found a strange bug in internet explorer cookie handling that could possibile
workarounded in tomcat:

I have 2 different webapps on 2 different domains (a domain and a subdomain of this domain), e.g.:
mydomain.com
test.mydomain.com

When I enter the first domain, a session cookie for this domain is set.
The session then works fine for this domain.
Then I view a page from the second domain. IE returns the cookie
that was set in the first domain. Tomcat does'nt know that session id
in the second context and sets a new cookie.
Now the strange thing: The new Cookie is never returned from ie. So the
new Session in the second domain is not valid and after each click a
new SessionID is generated (i think IE always returns the cookie set in the first domain).

A possible solution:
If the name of the session cookie would be configurable (per host or per webapp),
the hostname could added to that cookie. This would fix this issue on IE.

Michael.






--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Kevin Jones

Unfortunately the name of the session cookie isn't configurable - it's
set by the Servlet specification to be jsessionid,

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: Michael Wyraz [mailto:[EMAIL PROTECTED]] 
> Sent: 13 January 2003 13:26
> To: [EMAIL PROTECTED]
> Subject: Strange Cookie behavior with ie 6 and subdomains
> 
> 
> Hi!
> 
> I found a strange bug in internet explorer cookie handling 
> that could possibile
> workarounded in tomcat:
> 
> I have 2 different webapps on 2 different domains (a domain 
> and a subdomain of this domain), e.g.:
> mydomain.com
> test.mydomain.com
> 
> When I enter the first domain, a session cookie for this 
> domain is set.
> The session then works fine for this domain.
> Then I view a page from the second domain. IE returns the cookie
> that was set in the first domain. Tomcat does'nt know that session id
> in the second context and sets a new cookie.
> Now the strange thing: The new Cookie is never returned from 
> ie. So the
> new Session in the second domain is not valid and after each click a
> new SessionID is generated (i think IE always returns the 
> cookie set in the first domain).
> 
> A possible solution:
> If the name of the session cookie would be configurable (per 
> host or per webapp),
> the hostname could added to that cookie. This would fix this 
> issue on IE.
> 
> Michael.
> 
> 
> 
> __
> 
> 
> 
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> 
> Bis zu 100 MB Speicher bei http://premiummail.yahoo.de
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Strange Cookie behavior with ie 6 and subdomains

2003-01-13 Thread Michael Wyraz

Hi!

I found a strange bug in internet explorer cookie handling that could possibile
workarounded in tomcat:

I have 2 different webapps on 2 different domains (a domain and a subdomain of this 
domain), e.g.:
mydomain.com
test.mydomain.com

When I enter the first domain, a session cookie for this domain is set.
The session then works fine for this domain.
Then I view a page from the second domain. IE returns the cookie
that was set in the first domain. Tomcat does'nt know that session id
in the second context and sets a new cookie.
Now the strange thing: The new Cookie is never returned from ie. So the
new Session in the second domain is not valid and after each click a
new SessionID is generated (i think IE always returns the cookie set in the first 
domain).

A possible solution:
If the name of the session cookie would be configurable (per host or per webapp),
the hostname could added to that cookie. This would fix this issue on IE.

Michael.



__

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 10407] - Tomcat Memory Management

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=10407

Tomcat Memory Management

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 11:53 ---
I encounter the same problem, the garbage collection is not done properly when 
I run Tomcat as a service in W2K but it seems to be ok when I do it in command 
prompt. Any suggestions ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16015] - Unable to access Form Fields from JSP Page

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16015

Unable to access Form Fields from JSP Page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 09:42 ---
Perhaps if you attach your file for us to see. This definitelly works for me.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 16015] New: - Unable to access Form Fields from JSP Page