Re: API for user authentication

[Bill Barker]

It will bind you forever to a particular Tomcat version, but the following
should work:

The authenticating Servlet can't be protected, so that servlet saves off the
Principal as a special session variable.  You then write a (Context level)
Valve & Realm. The Valve looks for the special session varaible, and if
found, calls setUserPrincipal on the HttpRequest with the value.  Now, the
FormAuthenticator will say that you are already authenticated.  The Realm
can then check against any required roles to allow you access to your
protected pages.

- Original Message -
From: "Johann Uhrmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 10, 2002 2:57 AM
Subject: API for user authentication


> Hi,
>
> as far as I know, there is only one possible way to use form based
> authentication with Tomcat:
>
> - sending a request to a restricted site
> - getting the login form instead
> - logging in and getting the restricted site
>
>
> However, the following scenario seems more common in web applications:
>
> - having a welcome page that offers a user name and
>   password field
> - after submitting that form the user gets the index page
>   of the web application
>
> It seems to me that there is no way to provide the second scenario with
> tomcat. Therefore, I ask You whether there is an API call that can
> verify a username/password combination and create a user session.
>
> That kind of api call would be handy in the second scenario as the index
> page could easily check the given user/pass and send a redirect to the
> error page if it was wrong or show up the index page if the login
> succeeded.
>
> I know that this kind of functionality could be simulated by
> implementing a proprietary login mechanism. However, that would mean to
> throw away the security-constraint mechanisms (web.xml), the built-in
> user verification (jdbc-realm, ldap,...) and would require every site to
> check whether the user is logged in or not.
>
> If there is no API call to verify user/password then please treat this
> message as a feature request.
>
>
> Thank You very much,
>
> Johann Uhrmann
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

DO NOT REPLY [Bug 14438] New: - Can't configure referrals in JNDI Realm

[bugzilla]

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

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

Can't configure referrals in JNDI Realm

   Summary: Can't configure referrals in JNDI Realm
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


With the current JNDIRealm, there is no way to configure how JNDI should handle 
referrals returned by the server.  This is a problem when authenticating 
against Active Directory, because you must configure JNDI to follow all 
referrals (otherwise you get an exception).  I have a patch that I will submit 
to the mailing list after I file this bug.

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

DO NOT REPLY [Bug 14438] - Can't configure referrals in JNDI Realm

[bugzilla]

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

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

Can't configure referrals in JNDI Realm





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 08:09 ---
Created an attachment (id=3796)
Patch to add referral support to JNDIRealm

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

DO NOT REPLY [Bug 14405] - Tomcat uses 90% of CPU

[bugzilla]

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

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

Tomcat uses 90% of CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 09:03 ---
It seems to be a problem with your web application.

Could you tell use what it does and use (jdbc connections, kind of SQL database).

Could you try it on another platform with another SDK (ie an IBM SDK) ?

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

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

[hgomez]

hgomez  2002/11/11 01:03:56

  Modified:jasper2/src/share/org/apache/jasper/resources
messages_fr.properties
  Log:
  Update french translation
  
  Revision  ChangesPath
  1.4   +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties
  
  Index: messages_fr.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- messages_fr.properties8 Nov 2002 19:42:56 -   1.3
  +++ messages_fr.properties11 Nov 2002 09:03:56 -  1.4
  @@ -297,4 +297,4 @@
   jasper.error.emptybodycontent.nonempty=D''après la TLD, le tag {0} doit être vide, 
mais ne l''est pas
   jsp.error.tagfile.var_name_given_equals_attr_name=Dans le fichier de tag {0}, 
l''attribut name-given ({1}) de la directive variable est égal au nom d''attribut de 
la directive attribute
   jsp.error.useBean.noSession=Il est illégal pour useBean d''utiliser une portée de 
session (session scope) quand la page JSP indique (via la directive de page) qu''elle 
ne participe pas aux sessions
  -jsp.error.attributes.not.allowed=
  +jsp.error.attributes.not.allowed = {0} ne doit avoir aucun attribut
  
  
  

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

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparserXMLEncodingDetector.java

[Henri Gomez]

[EMAIL PROTECTED] wrote:

remm2002/11/07 07:23:43

  Modified:jasper2/src/share/org/apache/jasper/xmlparser
XMLEncodingDetector.java
  Log:
  - This appreas to fix the stack overflow.


is the xerces dependencie is normal ?

import org.apache.xerces.util.EncodingMap;
import org.apache.xerces.util.SymbolTable;
import org.apache.xerces.util.XMLChar;
import org.apache.xerces.util.XMLStringBuffer;
import org.apache.xerces.xni.XMLString;





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

cvs commit: jakarta-tomcat-catalina/webapps/docs/images jakarta-logo.gif

[hgomez]

hgomez  2002/11/11 01:27:59

  Modified:webapps/ROOT jakarta-banner.gif
   webapps/docs/images jakarta-logo.gif
  Log:
  Update to latest jakarta logo
  
  Revision  ChangesPath
  1.2   +77 -50jakarta-tomcat-catalina/webapps/ROOT/jakarta-banner.gif
  
<>
  
  
  1.2   +77 -50jakarta-tomcat-catalina/webapps/docs/images/jakarta-logo.gif
  
<>
  
  

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

DO NOT REPLY [Bug 14405] - Tomcat uses 90% of CPU

[bugzilla]

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

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

Tomcat uses 90% of CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 09:52 ---
Thankx a lot for your prompt response.

Yes..we are using oracle database in solaris 2.8. We do not see any i/o wait or 
swapping. I read a couple of articles in mailing lists. They claim that, mod_jk 
might run into a race condition when tomcat is not able to respond for whatever 
reason.

We are also using mod_jk which was shipped with tomact 3.2.1. We use this for 
tomcat 3.3 with ajp12 protocol.

>From the mailing list, i got the following code.

static int ajpv12_handle_response(ajp12_endpoint_t *p,
  jk_ws_service_t *s,
  jk_logger_t *l)
{
while(1) {
unsigned to_read = READ_BUF_SIZE;
unsigned acc = 0;
char *buf = NULL;

if(!jk_sb_read(&p->sb, &buf, to_read, &acc)) {
jk_log(l, JK_LOG_ERROR, "ajpv12_handle_response, error
reading
 from \n"); return JK_FALSE;
}

if(!acc) {
jk_log(l, JK_LOG_DEBUG, "ajpv12_handle_response, response
body is
 done\n"); break;
}

if(write_to_ws) {
if(!s->write(s, buf, acc)) {
jk_log(l, JK_LOG_ERROR, "ajpv12_handle_response, error
 writing back to server\n"); write_to_ws = JK_FALSE;mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: 

DO NOT REPLY [Bug 14405] - Tomcat uses 90% of CPU

[bugzilla]

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

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

Tomcat uses 90% of CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 09:53 ---
Please have a look at the following link to know more about the mod_jk bug.

http://marc.theaimsgroup.com/?l=tomcat-user&m=99112351628144&w=2

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java OutputBuffer.java

[remm]

remm2002/11/11 03:01:05

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteResponse.java OutputBuffer.java
   coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java OutputBuffer.java
  Log:
  - Properly compute the size of the content sent (previously, only the bytes
were counted).
  - Fix bug 14281.
  - Patch submitted by Eloy Lafuente 
  
  Revision  ChangesPath
  1.29  +5 -5  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- CoyoteResponse.java   6 Nov 2002 09:26:42 -   1.28
  +++ CoyoteResponse.java   11 Nov 2002 11:01:04 -  1.29
  @@ -330,7 +330,7 @@
* Return the number of bytes actually written to the output stream.
*/
   public int getContentCount() {
  -return outputBuffer.getBytesWritten();
  +return outputBuffer.getContentWritten();
   }
   
   
  
  
  
  1.9   +5 -0  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- OutputBuffer.java 6 Nov 2002 09:26:42 -   1.8
  +++ OutputBuffer.java 11 Nov 2002 11:01:04 -  1.9
  @@ -639,6 +639,11 @@
   }
   
   
  +public int getContentWritten() {
  +return bytesWritten + charsWritten;
  +}
  +
  +
   /** 
* True if this buffer hasn't been used ( since recycle() ) -
* i.e. no chars or bytes have been added to the buffer.  
  
  
  
  1.11  +5 -5  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- CoyoteResponse.java   5 Nov 2002 18:44:55 -   1.10
  +++ CoyoteResponse.java   11 Nov 2002 11:01:04 -  1.11
  @@ -330,7 +330,7 @@
* Return the number of bytes actually written to the output stream.
*/
   public int getContentCount() {
  -return outputBuffer.getBytesWritten();
  +return outputBuffer.getContentWritten();
   }
   
   
  
  
  
  1.3   +5 -0  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- OutputBuffer.java 5 Nov 2002 18:44:55 -   1.2
  +++ OutputBuffer.java 11 Nov 2002 11:01:05 -  1.3
  @@ -639,6 +639,11 @@
   }
   
   
  +public int getContentWritten() {
  +return bytesWritten + charsWritten;
  +}
  +
  +
   /** 
* True if this buffer hasn't been used ( since recycle() ) -
* i.e. no chars or bytes have been added to the buffer.  
  
  
  

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

ServletOutputStreamWrapper

[Paul Hunnisett]

I have been examining the source code for
org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
a writeTo() method that writes the current buffer to the OutputStream. 
What I can't quite see is how this method would be called.  It is not
part of the servlet spec, so the web application won't be calling it. 
So I assume that the server calls it, but how does the server know when
to write the buffer out? 

Any information would be appreciated.

Paul Hunnisett





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

Re: JSPC refactoring/documentation

[Remy Maucherat]

Bill Barker wrote:


>Based on problems reported by users of JSPC Remy made a proposal
>to deprecate it.
>
>This resulted in a number of people responding that they used JSPC
>and strongly felt it should be kept.
>
>There did seem to be some consensus that JSPC could beneifit from
>a review and refactoring to make it easier to use.
>
>It could also benefit from better documentation if it is to remain
>part of Tomcat.
>
>Perhaps those who so strongly support JSPC should take the lead to
>review, refactor, simplify, and better document JSPC.  Perhaps a
>JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
>
>
>This could be part of a Tomcat 4.2 development effort.
>There has been some discussion about other possible new features.
>
>Some new features/changes that have been discussed:
>
>A SecurityManager XML Policy file that allows secure delegation
>to web applications for setting their own policies (within a sandbox).
>
>Using JMX to instrument Tomcat for production runtime monitoring.
>
>Possibly a JSPC refactoring.
>
>Audit the SecurityManager web application sandbox.
>
>Are there other changes/features that could be part of Tomcat 4.2

development?


>From previous posts, I gather that Remy isn't interested in RMing a 4.2
release.  Unless Remy jumps in and tells me that I don't know what I'm
talking about :), the biggest change would be to find someone to volunteer
to RM it.



I think we have too many dev branches already, and this is causing 
maintenance problems.  I'd like to have those things go in either 4.1 or 
5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and 
not really usable to a normal Tomcat user, it needs to be fixed in 
4.1.x. Please :)

I'd also like to point out that the servlet API changes are very 
limited, and it will be possible to use Tomcat 5.0 with the Jasper from 
Tomcat 4.1. So I think "major" new features should go in the 5.0 codebase.

Rémy


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

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

[remm]

remm2002/11/11 03:53:01

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  1.29  +9 -1  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.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- RELEASE-NOTES-4.1.txt 8 Nov 2002 14:58:38 -   1.28
  +++ RELEASE-NOTES-4.1.txt 11 Nov 2002 11:53:01 -  1.29
  @@ -573,6 +573,14 @@
Fix possible loop scenarios which could happen if an invalid 0 length
read was made.
   
  +[4.1.15] Coyote Response:
  + Improve special header handling to allow protocol handler to enforce
  + the protocol.
  +
  +[4.1.15] #14281
  + Tomcat 4 Adapter OutputBuffer:
  + Properly compute the total size of the content written.
  +
   
   
   Jasper Bug Fixes:
  
  
  

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

[4.1.15] Tag tomorrow

[Remy Maucherat]

I plan to tag and package the Tomcat 4.1.15 milestone tomorrow.

Rémy


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

TagHandlerPool doesn't release Tags on reuse

[Torsten Fohrer]

I have some jsp sites which taglibs. With pooling enabled, some problems
occures. 

Samples:

  Customer Registration: all fields have the same values???
  Sessions Values are used together

After reading the jsp spezifikation and source of the
jasper/runtime/TagHandlerPool, i see that the pool doesn't call release in
his reuse method? 

After adding a general release in the reuse methode, which perhaps breaks
the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's working.

/**
 * Adds the given tag handler to this tag handler pool, unless this tag
 * handler pool has already reached its capacity, in which case the tag
 * handler's release() method is called.
 *
 * @param handler Tag handler to add to this tag handler pool
 */
public synchronized void reuse(Tag handler) {

// Releasing Tags, see jsp spec 1.2-fcs, page 172
handler.release();

if (current < (handlers.length - 1))
handlers[++current] = handler;
}

Torsten Fohrer

**
* DCSI AG* Tel.: +49 7131 155 88-0   *
* Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
* D-74076 Heilbronn  * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
** 

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

DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

[bugzilla]

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

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

Resubmit to j_security_check mistakenly fetches a page of that name





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 12:48 ---
Created an attachment (id=3797)
proposed fix

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

DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

[bugzilla]

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

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

Resubmit to j_security_check mistakenly fetches a page of that name





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 13:00 ---
Supplied a patch, tested with IE6, Mozilla and the admin webapp in the released
TC 4.1.

The behaviour with this patch is that when you attempt to access a secure
resource, you are forwarded to the login page. The login URL does not appear
in the browser. Logging in with correct credentials works, clicking back 
does not bring up the login screen (to me this looks contrary to the 
specced behaviour for user-agents, but it works).

Logging in with incorrect credentials brings up the error page (the URL /is/
shown here), clicking back takes you to the login page, if you correct your
credentials logging in works.

This means that -
- bookmarking login pages is no longer a problem as the login URL is never displayed
- clicking back to get to login pages never causes a problem - you never get to
see it unless its useful.

Seems like a winner?

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

Re: JSPC refactoring/documentation

[Glenn Nielsen]

Remy Maucherat wrote:

Bill Barker wrote:


>Based on problems reported by users of JSPC Remy made a proposal
>to deprecate it.
>
>This resulted in a number of people responding that they used JSPC
>and strongly felt it should be kept.
>
>There did seem to be some consensus that JSPC could beneifit from
>a review and refactoring to make it easier to use.
>
>It could also benefit from better documentation if it is to remain
>part of Tomcat.
>
>Perhaps those who so strongly support JSPC should take the lead to
>review, refactor, simplify, and better document JSPC.  Perhaps a
>JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
>
>
>This could be part of a Tomcat 4.2 development effort.
>There has been some discussion about other possible new features.
>
>Some new features/changes that have been discussed:
>
>A SecurityManager XML Policy file that allows secure delegation
>to web applications for setting their own policies (within a sandbox).
>
>Using JMX to instrument Tomcat for production runtime monitoring.
>
>Possibly a JSPC refactoring.
>
>Audit the SecurityManager web application sandbox.
>
>Are there other changes/features that could be part of Tomcat 4.2

development?


>From previous posts, I gather that Remy isn't interested in RMing a 4.2
release.  Unless Remy jumps in and tells me that I don't know what I'm
talking about :), the biggest change would be to find someone to 
volunteer
to RM it.



I think we have too many dev branches already, and this is causing 
maintenance problems.  I'd like to have those things go in either 4.1 or 
5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and 
not really usable to a normal Tomcat user, it needs to be fixed in 
4.1.x. Please :)


Doing development in the 4.1 branch would limit the ability to do bug
fix releases on 4.1.  Perhaps if an effort to resolve all know 4.1
bugs was made we would see the number of bug reports for 4.1 decrease.
That would make a 4.2 development branch easier to do while still maintaining 4.1.

We could try to keep the time 4.2 is in development to a minimum,
perhaps a couple of months.  Once 4.2 was released the 4.1 branch
could be retired with all bug fixes going in 4.2 (HEAD).

Why not wait and see if there are more signficant changes/new features
proposed for a possible 4.2 release. And if there are committers willing
to assist porting bug fixes between the branches while 4.2 is under
development.


I'd also like to point out that the servlet API changes are very 
limited, and it will be possible to use Tomcat 5.0 with the Jasper from 
Tomcat 4.1. So I think "major" new features should go in the 5.0 codebase.

Rémy


What is a realistic timeline for 5.0 being released?

Regards,

Glenn


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

Re: DO NOT REPLY [Bug 14405] - Tomcat uses 90% of CPU

[Henri Gomez]

[EMAIL PROTECTED] wrote:

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=14405

Tomcat uses 90% of CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 09:53 ---
Please have a look at the following link to know more about the mod_jk bug.

http://marc.theaimsgroup.com/?l=tomcat-user&m=99112351628144&w=2

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



ajp12 is deprecated and you should consider switching to ajp13


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

DO NOT REPLY [Bug 14445] New: - Not Support for arabic

[bugzilla]

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

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

Not Support for arabic

   Summary: Not Support for arabic
   Product: Tomcat 4
   Version: 4.1.9
  Platform: All
   URL: http://163.121.19.135:8080/voice/registerx.jsp
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Always the page generated is in western language incoding .. when i force the 
web browser to make the encoding in Arabic ()it fails 
when i come back to Tomcat 4.0.x .. everything go fine .. but with Tomcat 4.1.x 
the encoding not change at all .. all that had been tested on Linux and Windows 
Platform as a servers 
i hope that u can help me soon as possible.

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_handler_response.c jk_workerEnv.c

[jfclere]

jfclere 2002/11/11 07:40:34

  Modified:jk/native2/common jk_handler_response.c jk_workerEnv.c
  Log:
  We have 3 msg's in the end point. request for request, post for post and msg
  for what Tomcat sends us. I have changed msg into post where needed.
  
  Revision  ChangesPath
  1.24  +2 -1  
jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c
  
  Index: jk_handler_response.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_handler_response.c 8 Jul 2002 13:39:12 -   1.23
  +++ jk_handler_response.c 11 Nov 2002 15:40:34 -  1.24
  @@ -227,6 +227,7 @@
 jk_endpoint_t *ae, jk_msg_t   *msg )
   {
   jk_ws_service_t  *r=target;
  +jk_msg_t *post = ae->post;
   int len = msg->getInt(env, msg);
   
   if(len > AJP13_MAX_SEND_BODY_SZ) {
  @@ -242,7 +243,7 @@
   /* env->l->jkLog(env, env->l, JK_LOG_INFO, */
   /*   "handler_request.getChunk() - read len=%d\n",len); */
   
  -len=msg->appendFromServer( env, msg, r, ae, len );
  +len=post->appendFromServer( env, post, r, ae, len );
   /* the right place to add file storage for upload */
   if (len >= 0) {
   r->content_read += len;
  
  
  
  1.57  +3 -2  jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
  
  Index: jk_workerEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- jk_workerEnv.c8 Jul 2002 13:32:14 -   1.56
  +++ jk_workerEnv.c11 Nov 2002 15:40:34 -  1.57
  @@ -524,7 +524,8 @@
   if( ep->worker->mbean->debug > 10 )
   msg->dump( env, msg, "Apache->tomcat" );
   
  -rc = ep->worker->channel->send(env, ep->worker->channel, ep, msg );
  +rc = ep->worker->channel->send(env, ep->worker->channel, ep,
  +   ep->post );
   if (rc < 0) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "ajp14.processCallbacks() error sending response 
data\n");
  
  
  

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

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

[jfarcand]

jfarcand2002/11/11 08:08:33

  Modified:webapps/docs security-manager-howto.xml
  Log:
  Add a section on package protection. Add minor change to the introduction.
  
  Revision  ChangesPath
  1.3   +67 -29jakarta-tomcat-catalina/webapps/docs/security-manager-howto.xml
  
  Index: security-manager-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/security-manager-howto.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- security-manager-howto.xml30 Jul 2002 03:58:28 -  1.2
  +++ security-manager-howto.xml11 Nov 2002 16:08:33 -  1.3
  @@ -8,6 +8,7 @@
   
   
   Glenn Nielsen
  +Jean-Francois Arcand
   Security Manager HOW-TO
   
   
  @@ -35,12 +36,13 @@
 Using the Java SecurityManager is just one more line of defense a
 system administrator can use to keep the server secure and reliable.
   
  -  WARNING - Implementation of a SecurityManager in
  -  Tomcat has not been fully tested or had a security audit.  Make sure that
  -  you are satisfied with your SecurityManager configuration before allowing
  -  untrusted users to publish web applications, JSPs, servlets, beans, or
  -  tag libraries.  However, running with a SecurityManager is definitely
  -  better than running without one.
  +  WARNING - A security audit
  +  have been conducted using the Tomcat 5 codebase. Most of the critical
  +  package have been protected and a new security package protection mechanism 
  +  has been implemented. Still, make sure that you are satisfied with your 
SecurityManager 
  +  configuration before allowing untrusted users to publish web applications, 
  +  JSPs, servlets, beans, or tag libraries.  However, running with a 
  +  SecurityManager is definitely better than running without one.
   
   
   
  @@ -66,7 +68,7 @@
   access to JVM properties such as java.home.
   java.lang.RuntimePermission - Controls use of
   some System/Runtime functions like exit() and
  -exec().
  +exec(). Also control the package access/definition.
   java.io.FilePermission - Controls read/write/execute
   access to files and directories.
   java.net.SocketPermission - Controls use of
  @@ -103,6 +105,14 @@
   but disallow it from using file access to read any other files (unless
   permissions for those files are explicitly granted).
   
  +If you starts Tomcat with the -nonaming argument, 
  +Tomcat always dynamically creates the following file permission:
  +  
  +permission java.io.FilePermission "** your application context**", "read";
  +  
  +Where **your application context** equals the folder(or WAR file) under 
which 
  +your application has been deployed.   
  +
 
   
   
  @@ -186,6 +196,11 @@
   // == CATALINA CODE PERMISSIONS ===
   
   
  +// These permissions apply to the launcher code
  +grant codeBase "file:${catalina.home}/bin/commons-launcher.jar" {
  +permission java.security.AllPermission;
  +};
  +
   // These permissions apply to the server startup code
   grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
   permission java.security.AllPermission;
  @@ -204,24 +219,6 @@
   permission java.security.AllPermission;
   };
   
  -// These permissions apply to the jasper page compiler
  -// located in the "jasper" directory.
  -grant codeBase "file:${catalina.home}/jasper/-" {
  -permission java.security.AllPermission;
  -};
  -
  -// These permissions apply to shared web application libraries
  -// including the Jasper runtime library installed in the "lib" directory
  -grant codeBase "file:${catalina.home}/lib/-" {
  -permission java.security.AllPermission;
  -};
  -
  -// These permissions apply to shared web application classes
  -// located in the "classes" directory
  -grant codeBase "file:${catalina.home}/classes/-" {
  -permission java.security.AllPermission;
  -};
  -
   // == WEB APPLICATION PERMISSIONS =
   
   
  @@ -262,6 +259,9 @@
   // Required for getting BeanInfo
   permission java.lang.RuntimePermission "accessClassInPackage.sun.beans.*";
   
  +// Required for OpenJMX
  +permission java.lang.RuntimePermission "getAttribute";
  +
// Allow read of JAXP compliant XML parser debug
permission java.util.PropertyPermission "jaxp.debug", "read";
   };
  @@ -291,14 +291,13 @@
   // };
   //
   // The permission granted to your JDBC driver
  -// grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar" {
  +// grant codeBase 
"jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" {
   //  permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
   // };
   // The permissi

Re: [4.1.15] Tag tomorrow

[Glenn Nielsen]

There is a nastly little bug that crept into the manager context reload in the last
month or two.

If you do a manager reload of a context any JNDI named ressources that exist disappear.
This breaks use of the manager to reload a context which uses named resources.

I haven't found when/where this got broken yet. But it should probably be fixed
before the next release.  I filed a bugzilla report on this.

Regards,

Glenn

Remy Maucherat wrote:

I plan to tag and package the Tomcat 4.1.15 milestone tomorrow.

Rémy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

DO NOT REPLY [Bug 14192] - setclasspath.bat does not set classpath correctly

[bugzilla]

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

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

setclasspath.bat does not set classpath correctly





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 17:34 ---
It sounds like the jars you moved into the ext directory were in your CLASSPATH
originally? This behaviout is by design and is documented, see
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html :

"# System - This class loader is normally initialized from the contents of the
CLASSPATH environment variable. All such classes are visible to both Tomcat
internal classes, and to web applications. However, the standard Tomcat 4
startup scripts ($CATALINA_HOME/bin/catalina.sh or
%CATALINA_HOME%\bin\catalina.bat) 

totally ignore the contents of the CLASSPATH environment variable itself

, and instead build the System class loader from the following repositories: ..."

extra space added for emphasis.

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

Re: TagHandlerPool doesn't release Tags on reuse

[Kin-Man Chung]

According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler.  Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag.  See p164 and p166.


> Date: Mon, 11 Nov 2002 13:32:31 +0100
> From: Torsten Fohrer <[EMAIL PROTECTED]>
> Subject: TagHandlerPool doesn't release Tags on reuse
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> 
> 
> I have some jsp sites which taglibs. With pooling enabled, some problems
> occures. 
> 
> Samples:
> 
>   Customer Registration: all fields have the same values???
>   Sessions Values are used together
> 
> After reading the jsp spezifikation and source of the
> jasper/runtime/TagHandlerPool, i see that the pool doesn't call release in
> his reuse method? 
> 
> After adding a general release in the reuse methode, which perhaps breaks
> the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's working.
> 
> /**
>  * Adds the given tag handler to this tag handler pool, unless this tag
>  * handler pool has already reached its capacity, in which case the tag
>  * handler's release() method is called.
>  *
>  * @param handler Tag handler to add to this tag handler pool
>  */
> public synchronized void reuse(Tag handler) {
> 
> // Releasing Tags, see jsp spec 1.2-fcs, page 172
> handler.release();
> 
> if (current < (handlers.length - 1))
> handlers[++current] = handler;
> }
> 
> Torsten Fohrer
> 
> **
> * DCSI AG* Tel.: +49 7131 155 88-0   *
> * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> * D-74076 Heilbronn  * [EMAIL PROTECTED]*
> * GERMANY* http://www.dcsi.de*
> ** 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

Re: JSPC refactoring/documentation

[Remy Maucherat]

Glenn Nielsen wrote:


Remy Maucherat wrote:

> Bill Barker wrote:
>
>
>
> I think we have too many dev branches already, and this is causing
> maintenance problems.  I'd like to have those things go in either 4.1
> or 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1
> and not really usable to a normal Tomcat user, it needs to be fixed in
> 4.1.x. Please :)
>

Doing development in the 4.1 branch would limit the ability to do bug
fix releases on 4.1.  Perhaps if an effort to resolve all know 4.1
bugs was made we would see the number of bug reports for 4.1 decrease.
That would make a 4.2 development branch easier to do while still
maintaining 4.1.

We could try to keep the time 4.2 is in development to a minimum,
perhaps a couple of months.  Once 4.2 was released the 4.1 branch
could be retired with all bug fixes going in 4.2 (HEAD).

Why not wait and see if there are more signficant changes/new features
proposed for a possible 4.2 release. And if there are committers willing
to assist porting bug fixes between the branches while 4.2 is under
development.



So far, I'm not in favor of a 4.2 branch, as I would like to avoid 
fragmentation. If:
- 4.1 is put in a security-fix only mode
- all new features are ported to 5.0
- all relevant bugfixes are ported to 5.0
Then fragmentation cannot happen, and I would be in favor of it, and 
could maybe RM it (since I wouldn't be doing anything on 4.1), if 4.2 is 
proven to be useful.

On the features list:
- A SecurityManager XML Policy file that allows secure delegation
to web applications for setting their own policies (within a sandbox): 
as far as I can remember, this recieved negative feedback. This is sort 
of something which IMHO should be part of a future JDK. I don't really 
see what it has to do with Tomcat (except if would be a useful JDK 
feature to use). It could be developped in the Commons sandbox if you're 
interested.
- jspc: it should be done in 4.1 (it is not really usable at the moment 
unless you know the code). Even if it's a major refactoring, we have to 
do it there *or* we have to remove the feature for now. Given the 
different view everyone has on jspc (and me who doesn't really care 
about what it does ;-) ), I think someone should start a poll on which 
committers would vote.
- Using JMX to instrument Tomcat for production runtime monitoring: I 
have no idea what you want to do. I think it might be better in 5.0.
- Audit the SecurityManager web application sandbox: This has been done 
in 5.0, and the result could be ported to 4.1, esp if the sandbox is 
somewhat deficient.


> I'd also like to point out that the servlet API changes are very
> limited, and it will be possible to use Tomcat 5.0 with the Jasper
> from Tomcat 4.1. So I think "major" new features should go in the 5.0
> codebase.
>
> Rémy
>

What is a realistic timeline for 5.0 being released?



I'm now independent and unemployed, so I'm not aware of the Sun 
schedules for the spec anymore :-P Probably within 3-6 months given J2EE 
1.4 is in beta. The rule is we cannot release a stable version of 5.0.x 
until the specs are final.

Rémy


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

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

[bugzilla]

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

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

If-Modified-Since results in incorrect headers





--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 18:52 ---
I looked into this 'cos I was skeptical, but you're right, this breaks the spec.
206 (Partial) responses to If-Range requests, and 304 (Not Modified) responses
shouldn't include entity-headers in most circumstances, and /must not/ include
them in every other circumstance. i.e. the best thing to do is remove any of
them from a response. Sections 10.2.7 and 10.3.5 of the http 1.1 spec; the
entity headers that shouldn't be sent are listed in sec 7.1.

Near as I can tell the problem is in
org.apache.coyote.http11.Http11Processor.prepareResponse(), where it only
excludes a couple of entity headers on the basis that they're disallowed (should
remove all of them). What's in there is a hack round the inability to remove
headers from org.apache.tomcat.util.http.MimeHeaders, and it smells. A better
idea might be to have a 'MimeHeaderFilter' than applies the rules (eg
EntityHeaderFilter); whats more is it doesn't handle the 206 case at all.

FWIW, I'd also agree that the default content type shouldn't be being added
after the headers have already been 'validated' (since thats what
prepareResponse claims to do) - that doesn't make a lick of sense.

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

DO NOT REPLY [Bug 14413] - NPE while using jsp:attribute in JSP Document

[bugzilla]

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

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

NPE while using jsp:attribute in JSP Document

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 19:27 ---
Fixed.
A more meaningful exception (consistent with the exception thrown in the
standard syntax case) is now thrown (notice that it is illegal for
 to specify a 'value' attribute).

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

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

[luehe]

luehe   2002/11/11 11:26:29

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
  Log:
  Fixed 14413: NPE while using jsp:attribute in JSP Document
  
  Revision  ChangesPath
  1.29  +22 -15
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- JspDocumentParser.java8 Nov 2002 19:55:47 -   1.28
  +++ JspDocumentParser.java11 Nov 2002 19:26:28 -  1.29
  @@ -435,19 +435,26 @@
return;
}
   
  - if (current instanceof Node.NamedAttribute
  - && ((Node.NamedAttribute) current).isTrim()) {
  - // Ignore any whitespace (including spaces, carriage returns,
  - // line feeds, and tabs, that appear at the beginning and at the
  - // end of the body of the  action.
  + if (current instanceof Node.NamedAttribute) {
Node.Nodes subelems = ((Node.NamedAttribute) current).getBody();
  - Node firstNode = subelems.getNode(0);
  - if (firstNode instanceof Node.TemplateText) {
  - ((Node.TemplateText) firstNode).ltrim();
  + if (subelems == null) {
  +throw new SAXParseException(
  + err.getString("jsp.error.empty.body.not.allowed",
  +   "
For additional commands, e-mail: 

Re: TagHandlerPool doesn't release Tags on reuse

[Torsten Fohrer]

But if i looking into the generated jsp/servlet sources, i see the following:

--- example ---
  /*   tools:simpleCell  */
  de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
_jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell) 
_jspx_
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.get(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
  _jspx_th_tools_simpleCell_0.setPageContext(pageContext);
  _jspx_th_tools_simpleCell_0.setParent(null);
  _jspx_th_tools_simpleCell_0.setErrorName("messages");
  _jspx_th_tools_simpleCell_0.setMessageName("login");
  _jspx_th_tools_simpleCell_0.setHeight("30");
  _jspx_th_tools_simpleCell_0.setValign("top");
  _jspx_th_tools_simpleCell_0.setWidth("14%");
  _jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
  int _jspx_eval_tools_simpleCell_0 = 
_jspx_th_tools_simpleCell_0.doStartTag();
  if (_jspx_th_tools_simpleCell_0.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;


 example

If i now reset my tag to a initial state in doStartTag() i haven't any 
properties set

Who call the release method in reaction of the GC, finalize can't it.

On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
> According to the JSP 1.2 Spec, the release method is not invoked between
> tag usages, but is invoked before GC of the tag handler.  Therefore
> it should not be used to reset the tag handler to its initial state;
> you should do that in doStartTag.  See p164 and p166.
>
> > Date: Mon, 11 Nov 2002 13:32:31 +0100
> > From: Torsten Fohrer <[EMAIL PROTECTED]>
> > Subject: TagHandlerPool doesn't release Tags on reuse
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >
> >
> > I have some jsp sites which taglibs. With pooling enabled, some problems
> > occures.
> >
> > Samples:
> >
> >   Customer Registration: all fields have the same values???
> >   Sessions Values are used together
> >
> > After reading the jsp spezifikation and source of the
> > jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
> > in his reuse method?
> >
> > After adding a general release in the reuse methode, which perhaps breaks
> > the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
> > working.
> >
> > /**
> >  * Adds the given tag handler to this tag handler pool, unless this
> > tag * handler pool has already reached its capacity, in which case the
> > tag * handler's release() method is called.
> >  *
> >  * @param handler Tag handler to add to this tag handler pool
> >  */
> > public synchronized void reuse(Tag handler) {
> >
> > // Releasing Tags, see jsp spec 1.2-fcs, page 172
> > handler.release();
> >
> > if (current < (handlers.length - 1))
> > handlers[++current] = handler;
> > }
> >
> > Torsten Fohrer
> >
> > **
> > * DCSI AG* Tel.: +49 7131 155 88-0   *
> > * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> > * D-74076 Heilbronn  * [EMAIL PROTECTED]*
> > * GERMANY* http://www.dcsi.de*
> > **
> >
> > --
> > To unsubscribe, e-mail:  
> >  For additional
> > commands, e-mail: 
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


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

Re: TagHandlerPool doesn't release Tags on reuse

[Torsten Fohrer]

Here is the same source code for taglib call, generated with a tomcat 4.0.4

   /*   tools:simpleCell  */
de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
_jspx_th_tools_simpleCell_32 = new de.dcsi.util.jsp.taglibs.Validator_Simp
leCell();
_jspx_th_tools_simpleCell_32.setPageContext(pageContext);
_jspx_th_tools_simpleCell_32.setParent(null);
_jspx_th_tools_simpleCell_32.setErrorName("messages");
_jspx_th_tools_simpleCell_32.setMessageName("password");
_jspx_th_tools_simpleCell_32.setWidth("38%");
_jspx_th_tools_simpleCell_32.setErrorColor( errorColor );
try {
int _jspx_eval_tools_simpleCell_32 = 
_jspx_th_tools_simpleCell_32.doStartTag();
if (_jspx_eval_tools_simpleCell_32 == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_BUFFERED)
throw new JspTagException("Since tag handler class 
de.dcsi.util.jsp.taglibs.Validator_SimpleCell does not implem
ent BodyTag, it can't return BodyTag.EVAL_BODY_TAG");
if (_jspx_eval_tools_simpleCell_32 != 
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
// end
// begin } while 
(_jspx_th_tools_simpleCell_32.doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
}
if (_jspx_th_tools_simpleCell_32.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
} finally {
_jspx_th_tools_simpleCell_32.release();
}



On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
> According to the JSP 1.2 Spec, the release method is not invoked between
> tag usages, but is invoked before GC of the tag handler.  Therefore
> it should not be used to reset the tag handler to its initial state;
> you should do that in doStartTag.  See p164 and p166.
>
> > Date: Mon, 11 Nov 2002 13:32:31 +0100
> > From: Torsten Fohrer <[EMAIL PROTECTED]>
> > Subject: TagHandlerPool doesn't release Tags on reuse
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >
> >
> > I have some jsp sites which taglibs. With pooling enabled, some problems
> > occures.
> >
> > Samples:
> >
> >   Customer Registration: all fields have the same values???
> >   Sessions Values are used together
> >
> > After reading the jsp spezifikation and source of the
> > jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
> > in his reuse method?
> >
> > After adding a general release in the reuse methode, which perhaps breaks
> > the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
> > working.
> >
> > /**
> >  * Adds the given tag handler to this tag handler pool, unless this
> > tag * handler pool has already reached its capacity, in which case the
> > tag * handler's release() method is called.
> >  *
> >  * @param handler Tag handler to add to this tag handler pool
> >  */
> > public synchronized void reuse(Tag handler) {
> >
> > // Releasing Tags, see jsp spec 1.2-fcs, page 172
> > handler.release();
> >
> > if (current < (handlers.length - 1))
> > handlers[++current] = handler;
> > }
> >
> > Torsten Fohrer
> >
> > **
> > * DCSI AG* Tel.: +49 7131 155 88-0   *
> > * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> > * D-74076 Heilbronn  * [EMAIL PROTECTED]*
> > * GERMANY* http://www.dcsi.de*
> > **
> >
> > --
> > To unsubscribe, e-mail:  
> >  For additional
> > commands, e-mail: 
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


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

RE: TagHandlerPool doesn't release Tags on reuse

[Becker, Michael]

If you clean up in the doEndTag(), it works great...  We had the same
problem with our tags.

-Original Message-
From: Torsten Fohrer [mailto:TFohrer@;t-online.de] 
Sent: Monday, November 11, 2002 1:39 PM
To: Tomcat Developers List
Subject: Re: TagHandlerPool doesn't release Tags on reuse


Here is the same source code for taglib call, generated with a tomcat
4.0.4

   /*   tools:simpleCell  */
de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
_jspx_th_tools_simpleCell_32 = new
de.dcsi.util.jsp.taglibs.Validator_Simp
leCell();
 
_jspx_th_tools_simpleCell_32.setPageContext(pageContext);
_jspx_th_tools_simpleCell_32.setParent(null);
_jspx_th_tools_simpleCell_32.setErrorName("messages");
_jspx_th_tools_simpleCell_32.setMessageName("password");
_jspx_th_tools_simpleCell_32.setWidth("38%");
_jspx_th_tools_simpleCell_32.setErrorColor( errorColor
);
try {
int _jspx_eval_tools_simpleCell_32 = 
_jspx_th_tools_simpleCell_32.doStartTag();
if (_jspx_eval_tools_simpleCell_32 == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_BUFFERED)
throw new JspTagException("Since tag handler
class 
de.dcsi.util.jsp.taglibs.Validator_SimpleCell does not implem
ent BodyTag, it can't return BodyTag.EVAL_BODY_TAG");
if (_jspx_eval_tools_simpleCell_32 != 
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
// end
// begin } while 
(_jspx_th_tools_simpleCell_32.doAfterBody() == 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
}
if (_jspx_th_tools_simpleCell_32.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
} finally {
_jspx_th_tools_simpleCell_32.release();
}



On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
> According to the JSP 1.2 Spec, the release method is not invoked
between
> tag usages, but is invoked before GC of the tag handler.  Therefore
> it should not be used to reset the tag handler to its initial state;
> you should do that in doStartTag.  See p164 and p166.
>
> > Date: Mon, 11 Nov 2002 13:32:31 +0100
> > From: Torsten Fohrer <[EMAIL PROTECTED]>
> > Subject: TagHandlerPool doesn't release Tags on reuse
> > To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
> >
> >
> > I have some jsp sites which taglibs. With pooling enabled, some
problems
> > occures.
> >
> > Samples:
> >
> >   Customer Registration: all fields have the same values???
> >   Sessions Values are used together
> >
> > After reading the jsp spezifikation and source of the
> > jasper/runtime/TagHandlerPool, i see that the pool doesn't call
release
> > in his reuse method?
> >
> > After adding a general release in the reuse methode, which perhaps
breaks
> > the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
> > working.
> >
> > /**
> >  * Adds the given tag handler to this tag handler pool, unless
this
> > tag * handler pool has already reached its capacity, in which case
the
> > tag * handler's release() method is called.
> >  *
> >  * @param handler Tag handler to add to this tag handler pool
> >  */
> > public synchronized void reuse(Tag handler) {
> >
> > // Releasing Tags, see jsp spec 1.2-fcs, page 172
> > handler.release();
> >
> > if (current < (handlers.length - 1))
> > handlers[++current] = handler;
> > }
> >
> > Torsten Fohrer
> >
> > **
> > * DCSI AG* Tel.: +49 7131 155 88-0   *
> > * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> > * D-74076 Heilbronn  * [EMAIL PROTECTED]*
> > * GERMANY* http://www.dcsi.de*
> > **
> >
> > --
> > To unsubscribe, e-mail:  
> >  For additional
> > commands, e-mail: 
>
> --
> To unsubscribe, e-mail:  
>  For additional
commands,
> e-mail: 


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Re: TagHandlerPool doesn't release Tags on reuse

[Kin-Man Chung]

Use doStartTag for inits, doEndTag for cleanups.  release will be invoked
from destroy.


> Date: Mon, 11 Nov 2002 20:34:13 +0100
> From: [EMAIL PROTECTED] (Torsten Fohrer)
> Subject: Re: TagHandlerPool doesn't release Tags on reuse
> X-Sender: [EMAIL PROTECTED]
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Content-disposition: inline
> 
> 
> But if i looking into the generated jsp/servlet sources, i see the following:
> 
> --- example ---
>   /*   tools:simpleCell  */
>   de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
> _jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell) 
> _jspx_
> 
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.ge
t(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
>   _jspx_th_tools_simpleCell_0.setPageContext(pageContext);
>   _jspx_th_tools_simpleCell_0.setParent(null);
>   _jspx_th_tools_simpleCell_0.setErrorName("messages");
>   _jspx_th_tools_simpleCell_0.setMessageName("login");
>   _jspx_th_tools_simpleCell_0.setHeight("30");
>   _jspx_th_tools_simpleCell_0.setValign("top");
>   _jspx_th_tools_simpleCell_0.setWidth("14%");
>   _jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
>   int _jspx_eval_tools_simpleCell_0 = 
> _jspx_th_tools_simpleCell_0.doStartTag();
>   if (_jspx_th_tools_simpleCell_0.doEndTag() == 
> javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> return;
> 
> 
>  example
> 
> If i now reset my tag to a initial state in doStartTag() i haven't any 
> properties set
> 
> Who call the release method in reaction of the GC, finalize can't it.
> 
> On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
> > According to the JSP 1.2 Spec, the release method is not invoked between
> > tag usages, but is invoked before GC of the tag handler.  Therefore
> > it should not be used to reset the tag handler to its initial state;
> > you should do that in doStartTag.  See p164 and p166.
> >
> > > Date: Mon, 11 Nov 2002 13:32:31 +0100
> > > From: Torsten Fohrer <[EMAIL PROTECTED]>
> > > Subject: TagHandlerPool doesn't release Tags on reuse
> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > >
> > >
> > > I have some jsp sites which taglibs. With pooling enabled, some problems
> > > occures.
> > >
> > > Samples:
> > >
> > >   Customer Registration: all fields have the same values???
> > >   Sessions Values are used together
> > >
> > > After reading the jsp spezifikation and source of the
> > > jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
> > > in his reuse method?
> > >
> > > After adding a general release in the reuse methode, which perhaps breaks
> > > the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
> > > working.
> > >
> > > /**
> > >  * Adds the given tag handler to this tag handler pool, unless this
> > > tag * handler pool has already reached its capacity, in which case the
> > > tag * handler's release() method is called.
> > >  *
> > >  * @param handler Tag handler to add to this tag handler pool
> > >  */
> > > public synchronized void reuse(Tag handler) {
> > >
> > > // Releasing Tags, see jsp spec 1.2-fcs, page 172
> > > handler.release();
> > >
> > > if (current < (handlers.length - 1))
> > > handlers[++current] = handler;
> > > }
> > >
> > > Torsten Fohrer
> > >
> > > **
> > > * DCSI AG* Tel.: +49 7131 155 88-0   *
> > > * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> > > * D-74076 Heilbronn  * [EMAIL PROTECTED]*
> > > * GERMANY* http://www.dcsi.de*
> > > **
> > >
> > > --
> > > To unsubscribe, e-mail:  
> > >  For additional
> > > commands, e-mail: 
> >
> > --
> > To unsubscribe, e-mail:  
> >  For additional commands,
> > e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

Re: TagHandlerPool doesn't release Tags on reuse

[Hans Bergsten]

Torsten,

You may want to read the section about the tag handler lifecycle in an
article I wrote for ONJava.com:

  

It explains how the methods are called and how to deal with attribute
values.

Hans
Torsten Fohrer wrote:

But if i looking into the generated jsp/servlet sources, i see the following:

--- example ---
  /*   tools:simpleCell  */
  de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
_jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell) 
_jspx_
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.get(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
  _jspx_th_tools_simpleCell_0.setPageContext(pageContext);
  _jspx_th_tools_simpleCell_0.setParent(null);
  _jspx_th_tools_simpleCell_0.setErrorName("messages");
  _jspx_th_tools_simpleCell_0.setMessageName("login");
  _jspx_th_tools_simpleCell_0.setHeight("30");
  _jspx_th_tools_simpleCell_0.setValign("top");
  _jspx_th_tools_simpleCell_0.setWidth("14%");
  _jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
  int _jspx_eval_tools_simpleCell_0 = 
_jspx_th_tools_simpleCell_0.doStartTag();
  if (_jspx_th_tools_simpleCell_0.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;


 example

If i now reset my tag to a initial state in doStartTag() i haven't any 
properties set

Who call the release method in reaction of the GC, finalize can't it.

On Monday 11 November 2002 18:44, Kin-Man Chung wrote:

According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler.  Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag.  See p164 and p166.



Date: Mon, 11 Nov 2002 13:32:31 +0100
From: Torsten Fohrer <[EMAIL PROTECTED]>
Subject: TagHandlerPool doesn't release Tags on reuse
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>


I have some jsp sites which taglibs. With pooling enabled, some problems
occures.

Samples:

 Customer Registration: all fields have the same values???
 Sessions Values are used together

After reading the jsp spezifikation and source of the
jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
in his reuse method?

After adding a general release in the reuse methode, which perhaps breaks
the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
working.

   /**
* Adds the given tag handler to this tag handler pool, unless this
tag * handler pool has already reached its capacity, in which case the
tag * handler's release() method is called.
*
* @param handler Tag handler to add to this tag handler pool
*/
   public synchronized void reuse(Tag handler) {

   // Releasing Tags, see jsp spec 1.2-fcs, page 172
   handler.release();

   if (current < (handlers.length - 1))
   handlers[++current] = handler;
   }

Torsten Fohrer

**
* DCSI AG* Tel.: +49 7131 155 88-0   *
* Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
* D-74076 Heilbronn  * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
**

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

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



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



--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


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

Re: [4.1.15] Tag tomorrow

[Glenn Nielsen]

Doesn't this require a vote?

Glenn

Remy Maucherat wrote:

I plan to tag and package the Tomcat 4.1.15 milestone tomorrow.

Rémy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



--
--
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: 

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

[jfarcand]

jfarcand2002/11/11 13:37:37

  Modified:webapps/docs security-manager-howto.xml
  Log:
  Fix a wrong description of a dynamically added permission.
  
  Revision  ChangesPath
  1.4   +2 -3  jakarta-tomcat-catalina/webapps/docs/security-manager-howto.xml
  
  Index: security-manager-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/security-manager-howto.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- security-manager-howto.xml11 Nov 2002 16:08:33 -  1.3
  +++ security-manager-howto.xml11 Nov 2002 21:37:37 -  1.4
  @@ -105,8 +105,7 @@
   but disallow it from using file access to read any other files (unless
   permissions for those files are explicitly granted).
   
  -If you starts Tomcat with the -nonaming argument, 
  -Tomcat always dynamically creates the following file permission:
  +Also, Tomcat always dynamically creates the following file permission:
 
   permission java.io.FilePermission "** your application context**", "read";
 
  
  
  

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

Re: ServletOutputStreamWrapper

[Paul Hunnisett]

Is anyone familiar with this class?  

On Mon, 2002-11-11 at 11:14, Paul Hunnisett wrote:
> I have been examining the source code for
> org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
> a writeTo() method that writes the current buffer to the OutputStream. 
> What I can't quite see is how this method would be called.  It is not
> part of the servlet spec, so the web application won't be calling it. 
> So I assume that the server calls it, but how does the server know when
> to write the buffer out? 
> 
> Any information would be appreciated.
> 
> Paul Hunnisett
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 




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

Tomcat 4.1.14/jasper/JspRuntimeLibrary/ exception

[Nitin Lamba]

Hi:

I'm a new Tomcat user not yet active in tomcat development. I've spent quite some time 
trying to debug my JSP code that works fine with Tomcat 3.2.4 but gets this cryptic 
error with Tomcat 4.1.14:

- Root Cause -
org.apache.jasper.JasperException: error in invoking method
 at 
org.apache.jasper.runtime.JspRuntimeLibrary.createTypedArray(JspRuntimeLibrary.java:440)
 at 
org.apache.jasper.runtime.JspRuntimeLibrary.internalIntrospecthelper(JspRuntimeLibrary.java:263)
 at 
org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRuntimeLibrary.java:220)
 at org.apache.jasper.runtime.JspRuntimeLibrary.introspect(JspRuntimeLibrary.java:198)
...

I looked at the source; and this part of JspRuntimeLibrary eats-up the actual 
exception. I could not find much help on the web (mail archives, Google, etc) except 
for  http://w4.metronet.com/~wjm/tomcat/2000/Dec/msg01012.html an outdated related 
issue/suggested enhancement for Tomcat 3.2.x ...

Sending a sample code that shows this behavior could be more involved so I don't 
expect a direct solution to the problem. Nevertheless, could someone please:

(a) tell me if this is a known (non-critical) issue and has been there for a long time.

(b) let me know if there's a quick fix to this. I'm guessing that if I intent to debug 
my problem (to get the actual exception), I'll need to build Tomcat locally on my 
machine in the worst case (sigh!).

(c) tell me if I should post a bug/enhancement for this.

Thanks in advance,

Nitin


__
Outgrown your current e-mail service? Get 25MB Storage, POP3 Access,
Advanced Spam protection with LYCOS MAIL PLUS.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

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

/admin 404

[Amy Roh]

I did a clean build and tried to access admin webapp 
(http://localhost:8080/admin).  However, I get 404 "The request resource 
(/admin) is not available."  Am I missing something obvious?

Thanks,
Amy



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

Re: ServletOutputStreamWrapper

[Dan Sandberg]

Hi Paul.

That class is specific to the server-side include code, so the server 
doesn't need to know anything about the writeTo method.  

Basically, the ServletOutputStreamWrapper is used so that we can capture 
the result of Tomcat processing a page, so that we may include the 
contents of one page within another.

o.a.c.servlets.SsiInvokerServlet calls the writeTo method.  If you have 
any questions after looking at the source-code, let us know.

Is anyone familiar with this class?  

Yup.

-Dan

Paul Hunnisett wrote:


I have been examining the source code for
org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
a writeTo() method that writes the current buffer to the OutputStream. 
What I can't quite see is how this method would be called.  It is not
part of the servlet spec, so the web application won't be calling it. 
So I assume that the server calls it, but how does the server know when
to write the buffer out? 

Any information would be appreciated.

Paul Hunnisett





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


 




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

Re: /admin 404

[Bill Barker]

If you're using the default xerces-2.0.2, then the admin context won't load
(or at least it won't for me).  You should see the error in catalina.out.

- Original Message -
From: "Amy Roh" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, November 11, 2002 3:23 PM
Subject: /admin 404


> I did a clean build and tried to access admin webapp
> (http://localhost:8080/admin).  However, I get 404 "The request resource
> (/admin) is not available."  Am I missing something obvious?
>
> Thanks,
> Amy
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

DO NOT REPLY [Bug 14461] New: - init() in servlet does not get called in tomcat4.1.12

[bugzilla]

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

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

init() in servlet does not get called in tomcat4.1.12

   Summary: init() in servlet does not get called in tomcat4.1.12
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Tester
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,
I tried a sample servlet in tomcat 4.1.12. I found that the init() method was 
never called.Is it a bug?
Please find the servlet code mentioned below:
import javax.servlet.http.HttpServlet;
import javax.servlet.ServletConfig;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import javax.servlet.ServletException;
import java.io.PrintWriter;
import java.io.IOException;
import java.sql.*;
 
public class RegisterUser extends HttpServlet{
 
 public void init()
  throws ServletException {
  
  System.out.println("**444**");
  
  System.out.println("**444**");
 }
 
 public void service(HttpServletRequest req,HttpServletResponse res)
  throws ServletException,IOException{
  
  res.setContentType("text/html");
  PrintWriter out = res.getWriter();
  out.println("Cool Man");
 
  
 }
 
}
 
The line System.out.println("**444**"); did not get printed.
Can u pls tell me what's the problem?
Thanks in advance.
Regards,
G.Dinesh.
Programmer,
Infravio Inc.
www.infravio.com

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

Tomcat memory management

[Scott Johnson]

Hello,

We've got an application that is replicated for clients, each 
replication runs in its own context. We're running jdk1.4.1, RH7.2, 
Tomcat 4.0.6

Even though the application itself can run fine on 10mb RAM, as each 
context initializes, EVERY thread allocates more memory until we get 
20-30 contexts up with each context taking 60-90mb RAM:

An example process output will have one entry like this for every 
context:
root  2900  0.0  6.6 257624 68556 pts/1  S18:32   0:00 
/usr/java/jdk1.4.1_01/bin/java -Xmx10m 
-Djava.endorsed.dirs=/usr/java/tomcat/bin:/usr/java/tomcat/common/lib 
-classpath 
/usr/java/jdk1.4.1_01/lib/tools.jar:/usr/java/tomcat/bin/bootstrap.jar -

As you can see, the -Xmx... argument is of no effect as these processes 
are taking 68mb.

For us the optimal solution would be to have a single process handling 
all of the contexts, or have each context limited to 10mb.

I've searched for a configuration to allow the former, and the Xmx arg 
isn't working on the latter. Does anyone have any ideas?

Thanks!
__
Scott Johnson
AtTask, Inc.
http://www.attask.com
Work Smart, Work Happy™

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

Re: /admin 404

[Jeanfrancois Arcand]

Xerces 2.2, not 2.0.2 (2.0.2 does not work at all) :-)

It should work if you use 2.1.

-- Jeanfrancois

Bill Barker wrote:


If you're using the default xerces-2.0.2, then the admin context won't load
(or at least it won't for me).  You should see the error in catalina.out.

- Original Message -
From: "Amy Roh" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, November 11, 2002 3:23 PM
Subject: /admin 404


 

I did a clean build and tried to access admin webapp
(http://localhost:8080/admin).  However, I get 404 "The request resource
(/admin) is not available."  Am I missing something obvious?

Thanks,
Amy



--
To unsubscribe, e-mail:
   


 

For additional commands, e-mail:
   


 



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


 

Re: Tomcat memory management

[Michael Smith]

Scott Johnson wrote:
> 
> Hello,
> 
> We've got an application that is replicated for clients, each
> replication runs in its own context. We're running jdk1.4.1, RH7.2,
> Tomcat 4.0.6
> 
> Even though the application itself can run fine on 10mb RAM, as each
> context initializes, EVERY thread allocates more memory until we get
> 20-30 contexts up with each context taking 60-90mb RAM:
> 
> An example process output will have one entry like this for every
> context:
> root  2900  0.0  6.6 257624 68556 pts/1  S18:32   0:00
> /usr/java/jdk1.4.1_01/bin/java -Xmx10m
> -Djava.endorsed.dirs=/usr/java/tomcat/bin:/usr/java/tomcat/common/lib
> -classpath
> /usr/java/jdk1.4.1_01/lib/tools.jar:/usr/java/tomcat/bin/bootstrap.jar -
> 
> As you can see, the -Xmx... argument is of no effect as these processes
> are taking 68mb.
> 
> For us the optimal solution would be to have a single process handling
> all of the contexts, or have each context limited to 10mb.
> 
> I've searched for a configuration to allow the former, and the Xmx arg
> isn't working on the latter. Does anyone have any ideas?

Under linux, the distinction between threads and processes is fairly
small - and ps doesn't (in that version) display threads differently.

What you _actually_ have here are threads - but only a single process.
The memory usage you see on each of these threads is actually shared
across all of the threads for that JVM (the JVM is a single process). So
this isn't really a problem - you have 70 megs (or whatever) used _in
total_ by the JVM, across 20-30 threads. 

Michael

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JNDIRealm.java

[amyroh]

amyroh  2002/11/11 17:13:37

  Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
  Log:
  Add the possibility to use SSL with the JNDIRealm.
  
  This patch allows two more parameters to be set for the JNDIRealm.
  If they are not explicitly set the JNDIRealm will behave in the same way as before.
  
  Submitted by Fredrik Westermarck & Jonathan Eric Miller.
  
  Revision  ChangesPath
  1.9   +58 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JNDIRealm.java11 Jun 2002 15:32:28 -  1.8
  +++ JNDIRealm.java12 Nov 2002 01:13:37 -  1.9
  @@ -188,6 +188,10 @@
   
   // - Instance Variables
   
  +/**
  + *  The type of authentication to use
  + */
  +protected String authentication = null;
   
   /**
* The connection username for the server we will contact.
  @@ -233,6 +237,10 @@
*/
   protected static final String name = "JNDIRealm";
   
  +/**
  + * The protocol that will be used in the communication with the directory 
server.
  + */
  +protected String protocol = null;
   
   /**
* The base element for user searches.
  @@ -320,10 +328,28 @@
   protected boolean roleSubtree = false;
   
   
  -
   // - Properties
   
  +/**
  + * Return the type of authentication to use.
  + */  
  +public String getAuthentication() {
   
  +return authentication;
  +
  +}
  + 
  +/**
  + * Set the type of authentication to use.
  + *
  + * @param authentication The authentication
  + */
  +public void setAuthentication(String authentication) {
  +
  +this.authentication = authentication;
  +
  +}
  +  
   /**
* Return the connection username for this Realm.
*/
  @@ -411,6 +437,28 @@
   
   }
   
  +
  +/**
  + * Return the protocol to be used.
  + */
  +public String getProtocol() {
  + 
  +return protocol;
  + 
  +}
  +
  +/**
  + * Set the protocol for this Realm.
  + *
  + * @param protocol The new protocol.
  + */
  +public void setProtocol(String protocol) {
  + 
  +this.protocol = protocol;
  +
  +}
  +
  +
   /**
* Return the base element for user searches.
*/
  @@ -1294,6 +1342,11 @@
   env.put(Context.SECURITY_CREDENTIALS, connectionPassword);
   if (connectionURL != null)
   env.put(Context.PROVIDER_URL, connectionURL);
  +if (authentication != null)
  +env.put(Context.SECURITY_AUTHENTICATION, authentication);
  +if (protocol != null)
  +env.put(Context.SECURITY_PROTOCOL, protocol);
  +
   context = new InitialDirContext(env);
   return (context);
   
  @@ -1378,4 +1431,3 @@
   }
   
   }
  -
  
  
  

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

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

[amyroh]

amyroh  2002/11/11 17:15:36

  Modified:webapps/tomcat-docs/config realm.xml
  Log:
  Document the additions to newly supported SSL in JNDIRealm.
  
  Submitted by Fredrik Westermarck.
  
  Revision  ChangesPath
  1.6   +11 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/config/realm.xml
  
  Index: realm.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/realm.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- realm.xml 8 Sep 2002 23:01:16 -   1.5
  +++ realm.xml 12 Nov 2002 01:15:36 -  1.6
  @@ -191,7 +191,12 @@
   information from the directory:
   
   
  -
  +   
  + A string specifying the type of authentication to use.
  + "none", "simple", "strong" or a provider specific definition
  + can be used. If no value is given the providers default is used.
  +   
  +   
 
   The directory username to use when establishing a
   connection to the directory for LDAP search operations. If not
  @@ -219,6 +224,11 @@
   assumes that the standard JNDI LDAP provider will be utilized.
 
   
  +  
  + A string specifying the security protocol to use. If not given
  + the providers default is used.
  +  
  +  
 
   The base directory entry for performing role searches. If
   not specified the top-level element in the directory context
  
  
  

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

DO NOT REPLY [Bug 9702] - JNDIRealm StartTLS/SSL support request

[bugzilla]

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

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

JNDIRealm StartTLS/SSL support request

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-12 01:18 ---
Enhancement added.

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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JNDIRealm.java

[Amy Roh]

I don't use SSL with JNDIRealm so I didn't test this out.  However, the
patch seems ok and has been ignored long enough (with a few complaints).
;-)  Let me know if there're any issues.

Thanks,
Amy
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 11, 2002 5:13 PM
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm
JNDIRealm.java


> amyroh  2002/11/11 17:13:37
>
>   Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
>   Log:
>   Add the possibility to use SSL with the JNDIRealm.
>
>   This patch allows two more parameters to be set for the JNDIRealm.
>   If they are not explicitly set the JNDIRealm will behave in the same way
as before.
>
>   Submitted by Fredrik Westermarck & Jonathan Eric Miller.
>
>   Revision  ChangesPath
>   1.9   +58 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.ja
va
>
>   Index: JNDIRealm.java
>   ===
>   RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JN
DIRealm.java,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- JNDIRealm.java 11 Jun 2002 15:32:28 - 1.8
>   +++ JNDIRealm.java 12 Nov 2002 01:13:37 - 1.9
>   @@ -188,6 +188,10 @@
>
>// - Instance
Variables
>
>   +/**
>   + *  The type of authentication to use
>   + */
>   +protected String authentication = null;
>
>/**
> * The connection username for the server we will contact.
>   @@ -233,6 +237,10 @@
> */
>protected static final String name = "JNDIRealm";
>
>   +/**
>   + * The protocol that will be used in the communication with the
directory server.
>   + */
>   +protected String protocol = null;
>
>/**
> * The base element for user searches.
>   @@ -320,10 +328,28 @@
>protected boolean roleSubtree = false;
>
>
>   -
>// -
Properties
>
>   +/**
>   + * Return the type of authentication to use.
>   + */
>   +public String getAuthentication() {
>
>   +return authentication;
>   +
>   +}
>   +
>   +/**
>   + * Set the type of authentication to use.
>   + *
>   + * @param authentication The authentication
>   + */
>   +public void setAuthentication(String authentication) {
>   +
>   +this.authentication = authentication;
>   +
>   +}
>   +
>/**
> * Return the connection username for this Realm.
> */
>   @@ -411,6 +437,28 @@
>
>}
>
>   +
>   +/**
>   + * Return the protocol to be used.
>   + */
>   +public String getProtocol() {
>   +
>   +return protocol;
>   +
>   +}
>   +
>   +/**
>   + * Set the protocol for this Realm.
>   + *
>   + * @param protocol The new protocol.
>   + */
>   +public void setProtocol(String protocol) {
>   +
>   +this.protocol = protocol;
>   +
>   +}
>   +
>   +
>/**
> * Return the base element for user searches.
> */
>   @@ -1294,6 +1342,11 @@
>env.put(Context.SECURITY_CREDENTIALS, connectionPassword);
>if (connectionURL != null)
>env.put(Context.PROVIDER_URL, connectionURL);
>   +if (authentication != null)
>   +env.put(Context.SECURITY_AUTHENTICATION, authentication);
>   +if (protocol != null)
>   +env.put(Context.SECURITY_PROTOCOL, protocol);
>   +
>context = new InitialDirContext(env);
>return (context);
>
>   @@ -1378,4 +1431,3 @@
>}
>
>}
>   -
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

Re: /admin 404

[Amy Roh]

I switched from 2.2.0 to 2.1.0.  Still no admin.  :-(

I'm attaching the error logs for tomcat 4 and tomcat 5.  The same 
following errors are displayed running Tomcat 5.

Jeanfrancois,
admin works for you with 2.1.0??

Thanks,
Amy


Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Exception processing TLD at resource path /WEB-INF/struts-logic.tld
javax.servlet.ServletException: Exception processing TLD at resource 
path /WEB-I
NF/struts-logic.tld
at 
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja
va:1159)
at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:
1011)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78
3)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi
g.java:260)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
eSupport.java:166)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3
718)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:822)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80
8)
at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)

at 
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe
ployer.java:624)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav
a:250)
at 
org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260)
at org.apache.commons.digester.Rule.end(Rule.java:276)
at 
org.apache.commons.digester.Digester.endElement(Digester.java:1063)
at 
org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar
ser.java:585)
at 
org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind
er.java:647)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(
XMLDocumentFragmentScannerImpl.java:1008)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM
LDocumentFragmentScannerImpl.java:329)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:525)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:581)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at 
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.j
ava:1175)
at org.apache.commons.digester.Digester.parse(Digester.java:1561)
at 
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDep
loyer.java:430)
at 
org.apache.catalina.core.StandardHost.install(StandardHost.java:856)
at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j
ava:504)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461
)
at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:930)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
:420)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
eSupport.java:166)
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1203)

at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:791)
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1195)

at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347
)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:4
97)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:229
0)
at org.apache.catalina.startup.Catalina.start(Catalina.java:587)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:285)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:371)
Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Marking this application unavailable due to previous error(s)
Nov 11, 2002 5:59:59 PM org.apache.catalina.core.ContainerBase log
INFO: Context startup failed due to previous errors
Nov 11, 2002 6:00:00 PM org.apache.catalina.core.Contain

Re: /admin 404

[Jeanfrancois Arcand]

Yes, everythings works fine with the current build.

-- Jeanfrancois

Amy Roh wrote:


I switched from 2.2.0 to 2.1.0.  Still no admin.  :-(

I'm attaching the error logs for tomcat 4 and tomcat 5.  The same 
following errors are displayed running Tomcat 5.

Jeanfrancois,
admin works for you with 2.1.0??

Thanks,
Amy


Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Exception processing TLD at resource path 
/WEB-INF/struts-logic.tld
javax.servlet.ServletException: Exception processing TLD at resource 
path /WEB-I
NF/struts-logic.tld
at 
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja
va:1159)
at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:
1011)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78
3)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi
g.java:260)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
eSupport.java:166)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3
718)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:822)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80
8)
at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)

at 
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe
ployer.java:624)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav
a:250)
at 
org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260)
at org.apache.commons.digester.Rule.end(Rule.java:276)
at 
org.apache.commons.digester.Digester.endElement(Digester.java:1063)
at 
org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar
ser.java:585)
at 
org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind
er.java:647)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(
XMLDocumentFragmentScannerImpl.java:1008)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM
LDocumentFragmentScannerImpl.java:329)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:525)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:581)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at 
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.j
ava:1175)
at org.apache.commons.digester.Digester.parse(Digester.java:1561)
at 
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDep
loyer.java:430)
at 
org.apache.catalina.core.StandardHost.install(StandardHost.java:856)
at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j
ava:504)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461
)
at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:930)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
:420)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
eSupport.java:166)
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1203)

at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:791)
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1195)

at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347
)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:4
97)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:229
0)
at org.apache.catalina.startup.Catalina.start(Catalina.java:587)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:285)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:371)
Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Marking this application unavailable due to previous error(s)
Nov 11, 2002 5:59:59 PM org.apache.catalina.core.ContainerBase log
INFO: Context start

cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default

[jfarcand]

jfarcand2002/11/11 20:07:11

  Modified:.BUILDING.txt build.properties.default
  Log:
  Xerces 2.2.1 is now working with Tomcat.
  
  Revision  ChangesPath
  1.28  +4 -4  jakarta-tomcat-5/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- BUILDING.txt  28 Oct 2002 19:31:32 -  1.27
  +++ BUILDING.txt  12 Nov 2002 04:07:11 -  1.28
  @@ -56,13 +56,13 @@
   
   * Download a binary distribution of version 2.0.1 from:
   
  -  http://xml.apache.org/dist/xerces-j/old_xerces2
  +  http://xml.apache.org/dist/xerces-j/
   
 On a Windows platform, you will need:
  -Xerces-J-bin.2.0.1.zip
  +Xerces-J-bin.2.2.1.zip
   
 On a Unix platform, you will need:
  -Xerces-J-bin.2.0.1.tar.gz
  +Xerces-J-bin.2.2.1.tar.gz
   
   * Unpack the binary distribution into a convenient location so that the
 distribution resides in its own directory (conventionally named
  
  
  
  1.51  +4 -4  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- build.properties.default  5 Nov 2002 19:25:49 -   1.50
  +++ build.properties.default  12 Nov 2002 04:07:11 -  1.51
  @@ -99,12 +99,12 @@
   
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
   
   
  -# - Xerces XML Parser, version 2.1.0 or later -
  -xerces.home=${base.path}/xerces-2_2_0
  +# - Xerces XML Parser, version 2.1.0, 2.2.1 or later -
  +xerces.home=${base.path}/xerces-2_2_1
   xerces.lib=${xerces.home}
   xercesImpl.jar=${xerces.lib}/xercesImpl.jar
   xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
  -xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
  +xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.1.tar.gz
   
   
   # --
  
  
  

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

cvs commit: jakarta-tomcat-4.0 build.properties.sample

[jfarcand]

jfarcand2002/11/11 20:16:59

  Modified:.build.properties.sample
  Log:
  Update to Xerces 2.2.1.
  
  Revision  ChangesPath
  1.53  +3 -3  jakarta-tomcat-4.0/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- build.properties.sample   4 Oct 2002 08:46:33 -   1.52
  +++ build.properties.sample   12 Nov 2002 04:16:59 -  1.53
  @@ -117,9 +117,9 @@
   
   # - Xerces XML Parser, version 2.0.0 or later -
   # Note: Optional with JDK 1.4+, or if Xerces 1.x is present
  -xerces.home=${base.path}/xerces-2_2_0
  +xerces.home=${base.path}/xerces-2_2_1
   xerces.lib=${xerces.home}
  -xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
  +xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.1.tar.gz
   xercesImpl.jar=${xerces.lib}/xercesImpl.jar
   xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
   
  
  
  

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

Servlet Spec interpretation FORM-based authentication

[Algirdas P. Veitas]

Folks,

I am running into an issue with FORM-based authentication
using 4.1.12 (and 4.0.4).  It seems as if the implementation
is not in line with the 2.3 Servlet Specification.  Specifically,
the Servlet Spec states:

SRV.12.5.3 Form Base Authentication
--snip--
J2EE.12.5.3.1 Login Form Notes
--snip--
"If the form based login is invoked because of an HTTP request, the original 
request parameters must be preserved by the container for use if, on 
successful authentication, it redirects the call to the requested resource."

It seems as if the request parameters are not being preserved by the 
container.  After a successful login the container forwards me to the target 
URL (a JSP page).  The JSP page executes the following code:

Enumeration params = request.getParameterNames();
while (params.hasMoreElements())
{
 String paramKey = (String)params.nextElement();
 String paramVal = request.getParameter(paramKey);
 System.out.println(paramKey + " = " + paramKey);
}

which I would expect to atleast see printed out:

j_username = 
j_password = 

but in fact these request parameters are not printed out and thus not part of 
the request.

A bit of digging in the source revealed that in the method

authenticate(HttpRequest,HttpResponse,LoginConfig)

of class org.apache.catalina.authenticator.FormAuthenticator, the code is 
executing HttpResponse.sendRedirect(String url) in order to forward the user 
to the appropriate page.  A sendRedirect() will wipe out all of the original 
request parameters.

I think in order to preserve the parameters the sendRedirect() needs to be 
replaced by HttpRequest.getServletDispatcher().forward().

Has anyone else seen this behavior and is my claim valid?

Thanks,
  Al



--
Open WebMail Project (http://openwebmail.org)


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

Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 11, 2002 8:16 PM
Subject: cvs commit: jakarta-tomcat-4.0 build.properties.sample


> jfarcand2002/11/11 20:16:59
>
>   Modified:.build.properties.sample
>   Log:
>   Update to Xerces 2.2.1.
>

Not working any different than 2.2.0 for me. :-(

2002-11-11 22:46:32 action: null
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.




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

Servlet calls Connector

[h . buerger]

Hi,

i have a Servlet that needs to use object instances initially loaded
by a connector.
I first tried to use a resource but the environment is not set up
when the connector starts. Any ideas how a Servlet can communicate
with the connector instance?


Haug


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

AW: TagHandlerPool doesn't release Tags on reuse

[Torsten Fohrer]

thanks all, the article clarify some thinks.

cu Torsten Fohrer

> -Ursprüngliche Nachricht-
> Von: Hans Bergsten [mailto:hans@;gefionsoftware.com]
> Gesendet: Montag, 11. November 2002 21:06
> An: Tomcat Developers List
> Betreff: Re: TagHandlerPool doesn't release Tags on reuse
> 
> 
> Torsten,
> 
> You may want to read the section about the tag handler lifecycle in an
> article I wrote for ONJava.com:
> 
>
> 
> It explains how the methods are called and how to deal with attribute
> values.
> 
> Hans
> Torsten Fohrer wrote:
> > But if i looking into the generated jsp/servlet sources, i 
> see the following:
> > 
> > --- example ---
> >   /*   tools:simpleCell  */
> >   de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
> > _jspx_th_tools_simpleCell_0 = 
> (de.dcsi.util.jsp.taglibs.Validator_SimpleCell) 
> > _jspx_
> > 
> tagPool_tools_simpleCell_width_valign_messageName_height_error
> Name_errorColor.get(de.dcsi.util.jsp.taglibs.Validator_SimpleC
> ell.class);
> >   _jspx_th_tools_simpleCell_0.setPageContext(pageContext);
> >   _jspx_th_tools_simpleCell_0.setParent(null);
> >   _jspx_th_tools_simpleCell_0.setErrorName("messages");
> >   _jspx_th_tools_simpleCell_0.setMessageName("login");
> >   _jspx_th_tools_simpleCell_0.setHeight("30");
> >   _jspx_th_tools_simpleCell_0.setValign("top");
> >   _jspx_th_tools_simpleCell_0.setWidth("14%");
> >   _jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
> >   int _jspx_eval_tools_simpleCell_0 = 
> > _jspx_th_tools_simpleCell_0.doStartTag();
> >   if (_jspx_th_tools_simpleCell_0.doEndTag() == 
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > return;
> > 
> > 
> >  example
> > 
> > If i now reset my tag to a initial state in doStartTag() i 
> haven't any 
> > properties set
> > 
> > Who call the release method in reaction of the GC, finalize 
> can't it.
> > 
> > On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
> > 
> >>According to the JSP 1.2 Spec, the release method is not 
> invoked between
> >>tag usages, but is invoked before GC of the tag handler.  Therefore
> >>it should not be used to reset the tag handler to its initial state;
> >>you should do that in doStartTag.  See p164 and p166.
> >>
> >>
> >>>Date: Mon, 11 Nov 2002 13:32:31 +0100
> >>>From: Torsten Fohrer <[EMAIL PROTECTED]>
> >>>Subject: TagHandlerPool doesn't release Tags on reuse
> >>>To: "'[EMAIL PROTECTED]'" 
> <[EMAIL PROTECTED]>
> >>>
> >>>
> >>>I have some jsp sites which taglibs. With pooling enabled, 
> some problems
> >>>occures.
> >>>
> >>>Samples:
> >>>
> >>>  Customer Registration: all fields have the same values???
> >>>  Sessions Values are used together
> >>>
> >>>After reading the jsp spezifikation and source of the
> >>>jasper/runtime/TagHandlerPool, i see that the pool doesn't 
> call release
> >>>in his reuse method?
> >>>
> >>>After adding a general release in the reuse methode, which 
> perhaps breaks
> >>>the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
> >>>working.
> >>>
> >>>/**
> >>> * Adds the given tag handler to this tag handler 
> pool, unless this
> >>>tag * handler pool has already reached its capacity, in 
> which case the
> >>>tag * handler's release() method is called.
> >>> *
> >>> * @param handler Tag handler to add to this tag handler pool
> >>> */
> >>>public synchronized void reuse(Tag handler) {
> >>>
> >>>// Releasing Tags, see jsp spec 1.2-fcs, page 172
> >>>handler.release();
> >>>
> >>>if (current < (handlers.length - 1))
> >>>handlers[++current] = handler;
> >>>}
> >>>
> >>>Torsten Fohrer
> >>>
> >>>**
> >>>* DCSI AG* Tel.: +49 7131 155 88-0   *
> >>>* Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
> >>>* D-74076 Heilbronn  * [EMAIL PROTECTED]*
> >>>* GERMANY* http://www.dcsi.de*
> >>>**
> >>>
> >>>--
> >>>To unsubscribe, e-mail:  
> >>> For additional
> >>>commands, e-mail: 
> >>
> >>--
> >>To unsubscribe, e-mail:  
> >> For 
> additional commands,
> >>e-mail: 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   

> For additional commands, e-mail:

> 

-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pageshttp://TheJSPBook.com


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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realmJNDIRealm.java

[Fredrik Westermarck]

Amy Roh wrote:

I don't use SSL with JNDIRealm so I didn't test this out.  However, the
patch seems ok and has been ignored long enough (with a few complaints).
;-)  Let me know if there're any issues.


Thank you!


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

Re: [4.1.15] Tag tomorrow

[Remy Maucherat]

Glenn Nielsen wrote:


Doesn't this require a vote?



No. The vote is when the milestone is then publicly released. Otherwise, 
it's like a nightly, and allows getting some testing.

Rémy


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