DO NOT REPLY [Bug 15880] New: - Why not support Chinese?

[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=15880

Why not support Chinese?

   Summary: Why not support Chinese?
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat4.0.6+jdk1.3.02:
When I insert values into database,
if the values are Chinese.Tomcat will insert upside-down code.
such as "£¿£¿£¿£¿¡¤£¿£¿",
Chinese cannot be inserted normally in JSP pages.
so I have to convert the code before i insert the String into database:
public String getStr(String str){
try{
if(str == null || str.length() == 0)
return str;
byte[] b = str.getBytes("ISO8859-1");
return new String(b);
}catch(Exception e){
System.err.println(e.toString());
}
return null;
}
I insert Chinese by other method normally.
Chinese can be displayed normally in JSP pages by TOMCAT.
But Resin web server has never the problem!!!

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

DO NOT REPLY [Bug 15879] New: - default tomcat homepage index.jsp says it's index.html

[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=15879

default tomcat homepage index.jsp says it's index.html

   Summary: default tomcat homepage index.jsp says it's index.html
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
   URL: http://localhost:8080/index.jsp
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Installed Tomcat from tomcat-4.1.18.exe.  The 
default tomcat homepage file resides at $CATALINA_HOME/webapps/ROOT/index.jsp. 
But, the text in that file mistakenly says it resides at
$CATALINA_HOME/webapps/ROOT/index.html.

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

Re: [PROPOSAL] Tomcat doc organization

[Craig R. McClanahan]

On Tue, 7 Jan 2003, Glenn Nielsen wrote:

> Date: Tue, 07 Jan 2003 21:35:12 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Tomcat doc organization
>
> If you follow the tomcat-user list there are many questions that are asked
> which the reply could be RTFM.  If the tomcat docs were organized in a way
> which made them easier to use this may reduce the number of RTFM type of
> questions.
>
> Proposed changes to doc organization:
>
> For each individual page generate a "Printer Friendly" version without the
> navigation menu.  Provide a link on the menu to the printer friendly version.
> These can easily be generated from the existing xml files, I already have a
> minor change in tomcat-docs.xsl to support this.
>

The docs generated by Maven and Forrest based builds do this already --
they declare a stylesheet for the "print" media that leaves off the
navigation column when you print the document, without having to
explicitly generate print-friendly versions.  We could either import the
relevant stylesheets, or convert the docco generation to use these
existing packages.

> For the Config Reference and HOW-TO's provide a printer friendly version
> that includes all of those docs.  This will make it easier for user's to
> print out a Tomcat manual.

Shouldn't be too hard to accomplish with a document that just includes all
the individual parts into a single resulting "page".

>
> Where appropriate, add Table of Content sections at the top to make
> finding what you want and navigating within a single document easier.
>

Oh, and generate an searchable index with Lucene ... :-)

> Regards,
>
> Glenn

Craig


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

cvs commit: jakarta-tomcat-4.0 README.txt

[glenn]

glenn   2003/01/07 19:50:26

  Modified:.README.txt
  Log:
  Long overdue update
  
  Revision  ChangesPath
  1.20  +10 -11jakarta-tomcat-4.0/README.txt
  
  Index: README.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/README.txt,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- README.txt26 Dec 2001 01:21:23 -  1.19
  +++ README.txt8 Jan 2003 03:50:26 -   1.20
  @@ -1,6 +1,6 @@
   $Id$
   
  -   The Tomcat 4.0 Servlet/JSP Container
  +   The Tomcat 4.1 Servlet/JSP Container
  
   
   This subproject contains a server that conforms to the Servlet 2.3 and
  @@ -10,7 +10,7 @@
 LICENSE Apache Software License for this release
 README.txt  This document
 RELEASE-NOTES-*.txt Release Notes for this (and previous) releases
  -  of Tomcat 4.0
  +  of Tomcat 4.1
 RUNNING.txt Instructions for installing Tomcat, as well as
 starting and stopping the server
 bin/Binary executables and scripts
  @@ -19,7 +19,6 @@
   classes/  Unpacked common classes
   lib/  Common classes in JAR files
 conf/   Configuration files
  -  jasper/ JAR files visible only in the Jasper classloader
 logs/   Destination directory for log files
 server/ Internal Catalina classes and their dependencies
   classes/  Unpacked classes (internal only)
  @@ -28,7 +27,7 @@
   classes/  Unpacked shared classes
   lib/  Shared classes in JAR files
 webapps/Base directory containing web applications
  -  included with Tomcat 4.0
  +  included with Tomcat 4.1
 work/   Scratch directory used by Tomcat for holding
 temporary files and directories
 temp/   Directory used by JVM for temporary files
  @@ -41,13 +40,13 @@
   please consult the documentation in "RUNNING.txt".
   
   
  -  Acquiring Tomcat 4.0 Releases
  +  Acquiring Tomcat 4.1 Releases
 =
   
   Nightly Builds
   --
   
  -Nightly Builds of Tomcat 4.0 are built from the most recent CVS sources each
  +Nightly Builds of Tomcat 4.1 are built from the most recent CVS sources each
   evening (Pacific Time).  The filename of the downloadable file includes the
   date it was created (in MMDD format).  These builds are available at:
   
  @@ -58,10 +57,10 @@
   Release Builds
   --
   
  -Release Builds of Tomcat 4.0 are created and released periodically, and
  +Release Builds of Tomcat 4.1 are created and released periodically, and
   announced to the interested mailing lists.  Each release build resides in its
  -own directories.  For example, the Tomcat 4.0-beta-7 release is available at:
  +own directories.  For example, the Tomcat 4.1.18 release is available at:
   
  -Binary:  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/
  -Source:  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/src/
  +Binary:  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.18/bin/
  +Source:  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.18/src/
   
  
  
  

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

[PROPOSAL] Tomcat doc organization

[Glenn Nielsen]

If you follow the tomcat-user list there are many questions that are asked
which the reply could be RTFM.  If the tomcat docs were organized in a way
which made them easier to use this may reduce the number of RTFM type of
questions.

Proposed changes to doc organization:

For each individual page generate a "Printer Friendly" version without the
navigation menu.  Provide a link on the menu to the printer friendly version.
These can easily be generated from the existing xml files, I already have a
minor change in tomcat-docs.xsl to support this.

For the Config Reference and HOW-TO's provide a printer friendly version
that includes all of those docs.  This will make it easier for user's to
print out a Tomcat manual.

Where appropriate, add Table of Content sections at the top to make
finding what you want and navigating within a single document easier.

Regards,

Glenn



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

DO NOT REPLY [Bug 13583] - Relative includes/forwards with ../s broken

[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=13583

Relative includes/forwards with ../s broken





--- Additional Comments From [EMAIL PROTECTED]  2003-01-08 03:26 ---
I ran into the same problem and I wanted to mention that I tested this with
4.1.18 and its fixed.

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

RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Dimitry Ivanov]

Jan,

I'm not agree. :)

In accordance to spec JSP.10.2.2 (BodyTag):
"If EVAL_BODY_INCLUDE is returned, then evaluation happens as in
IterationTag."

The scripting variable synchronization is part of evaluation, isn't it?

I think, if container doesn't synchronize scripting variables it
explicitly conflicts 
with quoted requirement.

On the other hand, if container synchronizes scripting variables after
skipped invoke to doInitBody, 
it doesn't conflict with spec.

Substantiation:

Again JSP.10.2.2:
"If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked,
doInitBody() is not invoked, the body is evaluated and "passed through"
to the
current out, doAfterBody() is invoked and then, after zero or more
iterations,
doEndTag() is invoked."

There is nothing about skipping variable synchronization.

And JSP.10.5.9:
"The scope value for a variable implies what methods may affect its
value and thus
where synchronization is needed:
 - for NESTED, after doInitBody and doAfterBody for a tag handler
implementing
BodyTag, and after doStartTag otherwise.
 - for AT_BEGIN, after doInitBody, doAfterBody, and doEndTag for a tag
handler implementing BodyTag, and doStartTag and doEndTag otherwise."

There is nothing about synchronization *only* when doInitBody has
*invoked*.

I think it means the *state* not the action. When call to doInitBody
skipped (doStartTag 
returned EVAL_BODY_INCLUDE) "After doInitBody" *state* comes just after
doStartTag 
call.

Dimitry
--
P.S. Excuse me for my not ideal English. :(

-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, January 08, 2003 4:08 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH] Iteration tags do not synchronize scripting
variables after doStartTag


Dimitry:

I still believe your patch is invalid, as it would amount to
synchronizing AT_BEGIN and NESTED variables after calling
doStartTag(). However, the spec explicitly mentions that for tag
handlers implementing BodyTag, those variables must not be
synchronized after doStartTag(), *only* after doInitBody().

When I run your example (without applying your patch), I get this
result:

  doStartTag returns EVAL_BODY_INCLUDE
  null
  2nd
  3rd
  doStartTag returns EVAL_BODY_BUFFERED
  1st
  2nd
  3rd

The reason your are getting "null" in the case of doStartTag()
returning EVAL_BODY_INCLUDE is that in this case, doInitBody() is not
called, hence no synchronization.

However, if doStartTag() returns EVAL_BODY_BUFFERED,
doInitBody() is being called, and therefore synchronization does
take place.

Please let me know if you disagree.


Jan



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

DO NOT REPLY [Bug 15875] New: - Support global sharing of tag libraries

[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=15875

Support global sharing of tag libraries

   Summary: Support global sharing of tag libraries
   Product: Tomcat 4
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Being able to share a tag library globally for all the web applications 
running under Tomcat is something that is often desirable.

Unfortunately, the way to do this currently in Tomcat is more complex 
than it should be. While the jar files associated with the taglibs 
to be shared can be "shared" in /shared/lib, the TLD mappings 
must be defined within the web.xml of every web application that wants 
to use that shared library.
(defining the TLD mappings in /conf/web.xml does not currently
work because Jasper only processes TLD mappings in the web.xml of the 
webapp)

JSP 1.2 has simplified the use of tag libraries by supporting the
auto discory of TLD mappings in jar files. One simply has to 
drop the tag-library's jar file at the proper location, and voila... the
container will process any TLD contained in these jar files and record 
the proper mappings.

It would really be nice if it were possible to do the same at the
container (Tomcat) level.

As suggested by Craig, this could be supported in the following way:

Extend the "search for TLDs inside a JAR file" algorithm to work its
way up the parent class loaders as well.  That way, one can simply
drop the jar files of tag libraries to be shared into /common/lib 
and they would be recognized without requiring any TLD mappings in 
any web.xml.

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

DO NOT REPLY [Bug 15863] - An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.

[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=15863

An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Jan Luehe]

Dimitry:

I still believe your patch is invalid, as it would amount to
synchronizing AT_BEGIN and NESTED variables after calling
doStartTag(). However, the spec explicitly mentions that for tag
handlers implementing BodyTag, those variables must not be
synchronized after doStartTag(), *only* after doInitBody().

When I run your example (without applying your patch), I get this result:

  doStartTag returns EVAL_BODY_INCLUDE
  null
  2nd
  3rd
  doStartTag returns EVAL_BODY_BUFFERED
  1st
  2nd
  3rd

The reason your are getting "null" in the case of doStartTag()
returning EVAL_BODY_INCLUDE is that in this case, doInitBody() is not
called, hence no synchronization.

However, if doStartTag() returns EVAL_BODY_BUFFERED,
doInitBody() is being called, and therefore synchronization does
take place.

Please let me know if you disagree.


Jan


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

DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving

[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=15819

Duplicate context listener entries in server.xml when saving

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-07 23:45 ---
Fixed.  Should be available in the next release.

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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Aditya]

Glenn,

> On Mon, 06 Jan 2003 19:30:42 -0600, Glenn Nielsen <[EMAIL PROTECTED]> said:
> Thanks for reporting this.  I have changed the code so that if there
> is no content only status codes >= 400 are passed back through
> apache.
>
> The original patch was made so that when an error occurred at the
> Ajp13Processor layer it could propogated back to the browser
> correctly instead of a blank page being displayed.

and it was a welcome fix (now, when Tomcat is being restarted, instead
of the JSP being displayed as HTML, I can use a custom error page).

> Please test from a CVS build and let me know if this fixes the
> problem for you.

I just updated mod_jk.c from CVS and the fix of only passing empty
content errors >= 400 seems to work in my quick testing.

Thanks,
Adi

> Aditya wrote:
>>> On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn
>>> 2003/01/02 04:58:58
>>> 
>>> Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0
>>> mod_jk.c Log: Make sure http errors are handled by Apache if not
>>> handled by Tomcat
>>> 
>>> Revision Changes Path 1.34 +6 -1
>>> jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
> This fix seems to cause container form-based authentication to have
> "problems" - instead of the usual sequence of:
> 1) GET protected page -> 302 to login page
> 2) GET login page -> 200 retrieved
> 3) POST login page -> 302 to protected page
> 4) GET protected page -> 200 retrieved
> The *first* time I try to go to the protected page, instead of (4),
> I get:
> HTTP status 400 (invalid direct reference...)
> However, if I then try to get the protected page a *second* time, it
> works fine...
> reverting to a verison of mod_jk that does not include the below fix
> doesn't evidence this problem...
> Adi
> --
> To unsubscribe, e-mail:
>>> 
> For additional commands, e-mail:
>>> 

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

DO NOT REPLY [Bug 15872] New: - ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException

[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=15872

ContextManager: Error reading request, ignored - 
java.lang.ArrayIndexOutOfBoundsException

   Summary: ContextManager: Error reading request, ignored -
java.lang.ArrayIndexOutOfBoundsException
   Product: Tomcat 3
   Version: 3.2.x Nightly
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using Tomcat 3.2.4 (it is not a nightly build):

Getting the following exception. It is blocking me for deveolping my 
application. Will be greateful if it is attended to urgently. Had a look at Bug 
#300, but there is no solution provided. Link mentioned 
(http://znutar.cortexity.com:/BugRatViewer/ShowReport/300>
) is also not working. Similar bug is Bug # 359, but no solution / workaround 
is given.
 

2003-01-08 20:18:39 - ContextManager: Error reading request, ignored - 
java.lang.ArrayIndexOutOfBoundsException
at org.apache.tomcat.service.http.HttpRequestAdapter.parseHeaderFiled
(HttpRequestAdapter.java:224)
at org.apache.tomcat.service.http.HttpRequestAdapter.readHeaders
(HttpRequestAdapter.java:205)
at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest
(HttpRequestAdapter.java:140)
at 
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection
(HttpConnectionHandler.java:198)
at org.apache.tomcat.service.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run
(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:479)

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

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

[amyroh]

amyroh  2003/01/07 14:21:29

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Port change.
  
  Revision  ChangesPath
  1.11  +5 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- StandardServer.java   6 Jan 2003 23:22:26 -   1.10
  +++ StandardServer.java   7 Jan 2003 22:21:29 -   1.11
  @@ -191,6 +191,7 @@
   "org.apache.catalina.authenticator.SSLAuthenticator",
   "org.apache.catalina.core.NamingContextListener",
   "org.apache.catalina.core.StandardContextValve",
  +"org.apache.catalina.core.StandardDefaultContext",
   "org.apache.catalina.core.StandardEngineValve",
   "org.apache.catalina.core.StandardHostValve",
   "org.apache.catalina.startup.ContextConfig",
  
  
  

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

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

[amyroh]

amyroh  2003/01/07 14:20:12

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Fix bug 15819.  Do not write out StandardDefaultContext Listener to server.xml.
  
  Revision  ChangesPath
  1.36  +5 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- StandardServer.java   6 Jan 2003 23:25:24 -   1.35
  +++ StandardServer.java   7 Jan 2003 22:20:12 -   1.36
  @@ -191,6 +191,7 @@
   "org.apache.catalina.authenticator.SSLAuthenticator",
   "org.apache.catalina.core.NamingContextListener",
   "org.apache.catalina.core.StandardContextValve",
  +"org.apache.catalina.core.StandardDefaultContext",
   "org.apache.catalina.core.StandardEngineValve",
   "org.apache.catalina.core.StandardHostValve",
   "org.apache.catalina.startup.ContextConfig",
  
  
  

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

DO NOT REPLY [Bug 15863] New: - An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.

[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=15863

An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.

   Summary: An NPE occurs in Jasper2's parser when the body of
jsp:attribute is empty.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the JSP 2.0 specicifcation, if the body of the jsp:attribute action
is empty, it is the equivalent of specifying "" as the value of the attribute.

When Jasper2 is provided such a scenario, an NPE occurs.

Stacktrace below:


java.lang.NullPointerException
at
org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:825)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1022)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1634)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:1676)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:1682)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:323)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1634)
at org.apache.jasper.compiler.Validator.validate(Validator.java:1167)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:260)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:427)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:571)


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

mod_jk: feature disabling sticky sessions

[David Klimek]

Hello,

will be in future added into mod_jk option to disable sticky sessions
but with sessions working?

Thank's a lot
David Klimek
	
--
http://www.sweb.cz/david.klimek


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

Re: Jasper and big jsp files ( not working !! )

[webmaster]

Hi,

I guess my problem is a little bit different. I don't see the exception in the error 
log and when I put something 
like:

<%  %>


lots of html... more than 8192 charaters


Jasper compiles the file and the out.println("...") line is trimmed in 8192 
characters... :((



On Tue, 7 Jan 2003 20:15:22 +0100, "Holger Brozio" <[EMAIL PROTECTED]> escreveu :

> De: "Holger Brozio" <[EMAIL PROTECTED]>
> Data: Tue, 7 Jan 2003 20:15:22 +0100
> Para: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Assunto: Re: Jasper and big jsp files ( not working !! )
> 
> Hi,
> 
> i have reported this as a bug before, see
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14359
> 
> for more details, but i have no real solution for this now. Is this also
> your problem?
> One workaround may be to split the jsp files and include the content by a
> jsp:include?
> 
> Holger
> 
> - Original Message -
> From: "webmaster" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 07, 2003 7:38 PM
> Subject: Jasper and big jsp files ( not working !! )
> 
> 
> > Hi all,
> >
> > I have a problem with both Jasper and Jasper2. If I have a huge piece of
> HTML inserted between two
> > statements, the generated out.println("") on the compiled code outputs
> just the first 8192 characters. I tried to
> > play with the 'largefile' option in the /conf/web.xml:
> >
> > 
> > jsp
> >
> org.apache.jasper.servlet.JspServlet
> > 
> > logVerbosityLevel
> > WARNING
> > 
> > 
> > largefile
> > true
> > 
> > 3
> > 
> >
> > and it does not work either. I'm using Tomcat 4.1.18 with Jasper2.
> >
> > Thanks
> >
> >
> > --
> > 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: 

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

[luehe]

luehe   2003/01/07 12:47:27

  Modified:jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
  Log:
  Undid change that leveraged org.apache.jasper.compiler.ErrorDispatcher,
  since this change would have required duplication of a lot of the class files
  of jasper-compiler.jar in jasper-runtime.jar
  
  Revision  ChangesPath
  1.14  +38 -31
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
  
  Index: JspRuntimeLibrary.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- JspRuntimeLibrary.java6 Jan 2003 18:57:15 -   1.13
  +++ JspRuntimeLibrary.java7 Jan 2003 20:47:27 -   1.14
  @@ -80,8 +80,8 @@
   import javax.servlet.jsp.JspWriter;
   import javax.servlet.jsp.tagext.BodyContent;
   
  +import org.apache.jasper.Constants;
   import org.apache.jasper.JasperException;
  -import org.apache.jasper.compiler.ErrorDispatcher;
   
   // for JSTL expression interpreter
   import javax.servlet.jsp.PageContext;
  @@ -100,12 +100,6 @@
*/
   public class JspRuntimeLibrary {
   
  -private static ErrorDispatcher err;
  -
  -static {
  - err = new ErrorDispatcher();
  -}
  -
   protected static class PrivilegedIntrospectHelper
implements PrivilegedExceptionAction {
   
  @@ -288,7 +282,7 @@
   t, propertyName, s);
   }
   } catch (Exception ex) {
  -throw new JasperException (ex);
  +throw new JasperException(ex);
   }
   }
   // __end convertMethod
  @@ -354,7 +348,9 @@
if ( method != null ) {
if (type.isArray()) {
   if (request == null) {
  -err.jspError("jsp.error.beans.setproperty.noindexset");
  + throw new JasperException(Constants.getString(
  +"jsp.error.beans.setproperty.noindexset",
  + new Object[] {}));
   }
Class t = type.getComponentType();
String[] values = request.getParameterValues(param);
  @@ -375,15 +371,18 @@
}
}
} catch (Exception ex) {
  - throw new JasperException (ex);
  + throw new JasperException(ex);
}
   if (!ignoreMethodNF && (method == null)) {
   if (type == null) {
  -err.jspError("jsp.error.beans.noproperty",
  -  prop, bean.getClass().getName());
  + throw new JasperException(Constants.getString(
  +"jsp.error.beans.noproperty",
  + new Object[] { prop, bean.getClass().getName() }));
   } else {
  - err.jspError("jsp.error.beans.nomethod.setproperty",
  -  prop, type.getName(), bean.getClass().getName());
  + throw new JasperException(Constants.getString(
  +"jsp.error.beans.nomethod.setproperty",
  + new Object[] { prop, type.getName(),
  +bean.getClass().getName() }));
   }
   }
   }
  @@ -611,8 +610,9 @@
   // __begin lookupReadMethodMethod
   public static Object handleGetProperty(Object o, String prop)
   throws JasperException {
  -if (o == null){
  -err.jspError("jsp.error.beans.nullbean");
  +if (o == null) {
  + throw new JasperException(Constants.getString(
  + "jsp.error.beans.nullbean", new Object[] {}));
   }
Object value = null;
   try {
  @@ -794,19 +794,23 @@
}
   } else {
   // just in case introspection silently fails.
  -err.jspError("jsp.error.beans.nobeaninfo",
  -  beanClass.getName());
  +throw new JasperException(Constants.getString(
  + "jsp.error.beans.nobeaninfo",
  + new Object[] { beanClass.getName() }));
   }
   } catch (Exception ex) {
   throw new JasperException (ex);
   }
   if (method == null) {
   if (type == null) {
  -err.jspError("jsp.error.beans.noproperty",
  -  prop, beanClass.getName());
  + throw new JasperException(Constants.getString(
  +"jsp.error.beans.noproperty",
  + new Object[] { prop, beanClass.getName() }));
   } else {
  -err.jspError("jsp.error.beans.nomethod.setproperty",
  -   

Error page declarations interacting with servlets

[John Willemin]

I first noticed about 10 months ago, when I filed bug 7371, that for some 
reason the error-page's that I declared in my web.xml were working fine 
from JSP's but not from servlets. That bug was closed, because it worked in 
the tests. Tomcat 4.0.1:

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

Then someone posted something similar, about how when certain exceptions 
are thrown from servlets instead of JSP's, the Exception report is 
displayed instead of the error-page (this bug is still outstanding). This 
was filed for Tomcat 4.1.12:

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

And as recently as December 14th there is evidence someone is having the 
same problem still, with Tomcat 4.0.4:

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38168.html

I am just trying to generate critical mass for hunting this down. I posted 
a test case on 7371, and there was also a test case posted on 13924. My 
test case works as expected in Resin but not in Tomcat 4.0.1

This is very problematic for us, as users of our system are seeing 
stacktraces instead of our custom error pages.

Thanks for any assistance.

John


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

DO NOT REPLY [Bug 15854] New: - Unable to provide a qname attribute value to the name attribute of the jsp:attribute action.

[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=15854

Unable to provide a qname attribute value to the name attribute of the jsp:attribute 
action.

   Summary: Unable to provide a qname attribute value to the name
attribute of the jsp:attribute action.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to table JSP.5-8, in particular the section regarding the 'name'
attribute:

"The value of name can be a QName.  If so, the prefix must match that of the 
 action it applies to,"

So given the following:



attributevalue



The following error is incorrectly returned:


/JspAttributeQNameTest1.jsp(9,0) According to the TLD attribute attributename is
mandatory for tag action


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

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

[jfarcand]

jfarcand2003/01/07 11:35:32

  Modified:catalina/src/share/org/apache/catalina/core Constants.java
  Log:
  Put the proper spec version.
  
  Submitted by: Ryan Lubke
  
  Revision  ChangesPath
  1.2   +4 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Constants.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Constants.java18 Jul 2002 16:48:06 -  1.1
  +++ Constants.java7 Jan 2003 19:35:32 -   1.2
  @@ -69,7 +69,7 @@
   
   public static final String Package = "org.apache.catalina.core";
   public static final int MAJOR_VERSION = 2;
  -public static final int MINOR_VERSION = 3;
  +public static final int MINOR_VERSION = 4;
   
   public static final String JSP_SERVLET_CLASS =
   "org.apache.jasper.servlet.JspServlet";
  
  
  

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

Re: Jasper and big jsp files ( not working !! )

[Holger Brozio]

Hi,

i have reported this as a bug before, see

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

for more details, but i have no real solution for this now. Is this also
your problem?
One workaround may be to split the jsp files and include the content by a
jsp:include?

Holger

- Original Message -
From: "webmaster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 7:38 PM
Subject: Jasper and big jsp files ( not working !! )


> Hi all,
>
> I have a problem with both Jasper and Jasper2. If I have a huge piece of
HTML inserted between two
> statements, the generated out.println("") on the compiled code outputs
just the first 8192 characters. I tried to
> play with the 'largefile' option in the /conf/web.xml:
>
> 
> jsp
>
org.apache.jasper.servlet.JspServlet
> 
> logVerbosityLevel
> WARNING
> 
> 
> largefile
> true
> 
> 3
> 
>
> and it does not work either. I'm using Tomcat 4.1.18 with Jasper2.
>
> Thanks
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

FW: documentation error

[Pier Fumagalli]

Not acked... FYI...

Pier

-- Forwarded Message
> From: "Stoffer, Shawn D" <[EMAIL PROTECTED]>
> Date: Tue, 7 Jan 2003 11:55:11 -0700
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: documentation error
> 
> I wished to point out that in the jakarta/tomcat documentation, there is an
> error.  
> 
> Under server configuration reference, Host
> (webapps\tomcat-docs\config\host.html), it shows, under the section heading
> request filters, an example of using the valve xml tag for the server.xml
> configuration file.
> 
> 
> ...
> allow="*.mycompany.com,www.yourcompany.com"/>
> deny="192.168.1.*"/>
> ...
> 
> 
> The problem is in the regular expression, it should read:
> 
> 
> ...
> allow="\w*.mycompany.com,www.yourcompany.com"/>
> deny="192.168.1.\d*"/>
> ...
> 
> 
> Without the '\w' and the '\d' the server will not start, as the regular
> expression engine will throw an exception.
> 
> Excellent job, else, guys!  Thanks,
> 
> Shawn Stoffer
> <>
> 

-- End of Forwarded Message




Stoffer, Shawn D.vcf
Description: Binary data
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15851] New: - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.

[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=15851

Parser generates a NullPointerException for invalid use case of jsp:attribute instead 
of a useful message.

   Summary: Parser generates a NullPointerException for invalid use
case of jsp:attribute instead of a useful message.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Consider the following fragment which is supposed to generate a translation-time
error:



someattr


someattrvalue



According to the specification, if a jsp:attribute standard action is nested
within another jsp:attribute standard action, a translation error must occur.

In this case, a translation error does occur, but for the wrong reason.  Here is
the resulting cause:


java.lang.NullPointerException
at org.apache.jasper.compiler.Parser.getAttributeBodyType(Parser.java:1736)
at org.apache.jasper.compiler.Parser.parseNamedAttributes(Parser.java:1710)
at
org.apache.jasper.compiler.Parser.parseJspAttributeAndBody(Parser.java:1045)
at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:1017)
at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1313)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1458)
at org.apache.jasper.compiler.Parser.parse(Parser.java:164)


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

Jasper and big jsp files ( not working !! )

[webmaster]

Hi all,

I have a problem with both Jasper and Jasper2. If I have a huge piece of HTML inserted 
between two 
statements, the generated out.println("") on the compiled code outputs just the first 
8192 characters. I tried to 
play with the 'largefile' option in the /conf/web.xml:


jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
WARNING


largefile
true

3


and it does not work either. I'm using Tomcat 4.1.18 with Jasper2.

Thanks


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

DO NOT REPLY [Bug 13924] - error-page directive does not always work 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=13924

error-page directive does not always work correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-01-07 17:55 ---
This sounds a lot like what I reported a while back (not the wrapping thing, but
the servlet vs. JSP thing):

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

There's another test case there. We are still using 4.0.1 so it still fails for
me. I have no clue WHY it works when thrown from a JSP, but not from a servlet;
it just doesnt :)

Hell, I'd be happy to start looking at the Tomcat source if someone wants to
shove me in the right direction.

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

JK 1.2.2 need Windows binaries

[Henri Gomez]

I just take a look and see that jk 1.2.2 release miss a
binary for Windows (Apache 1.3.x/2.0).

Nacho ?


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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Tue, 2003-01-07 at 04:39, Remy Maucherat wrote:
> Matt Parker wrote:
> > If you want to mirror what Apache HTTPD does:
> > 
> > No slash present --> append slash (only!) and redirect
> > Slash present --> internally forward to welcome-file page
> > 
> > 
> > Well, here's the rub:
> > 
> > - The new servlet spec clearly states that either /foo or /foo/ should
> > return a welcome-file (if specified)
> 
> Well, this is broken behavior. If no slash, then a redirect will be sent 
> back to the client, otherwise, relative paths are not resolved 
> correctly, with no way for the app writer to anticipate it.
> 

That's true. Although I think it would still satisfy the spec to
redirect /foo to /foo/index.html, but would a redirect from /foo to
/foo/, and then forward to /foo/index.html still satisfy it? Maybe I'm
being too pedantic. The actual text reads:

"A request URI of /foo or /foo/ will be returned as /foo/index.html"

> > 
> > What do y'all think?
> > 
> > I vote +1 :)
> 
> I'll vote the opposite ;-)
> People are used to the bahavior in 4.1. In 5.0, I plan to add the option 
> for internal forwards in the new mapper I'll write.
> 
> Note that internal forwards were used in early 4.0 releases, but went 
> away as it got reported as a security issue (the security checks apply 
> to the original URI, not the served welcome file).
> 
> Remy
> 

I hear ya. Didn't mean to be cute. Could the security check be applied
after the welcome file was resolved? Or is that going to be done in your
mapper?

Matt



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

DO NOT REPLY [Bug 15845] New: - Memory Leak when compiling JSP

[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=15845

Memory Leak when compiling JSP

   Summary: Memory Leak when compiling JSP
   Product: Tomcat 4
   Version: 4.1.14
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when accessing lots of uncompiled jsp pages Jasper leaks memory.

I have found a temporary solution but am sure it is not good.

if you always force the JspCompilationContext to use a new Compiler when 
getCompiler() is called the leak goes away.  

When profiling Jasper the problem was that the JspCompilationContext, 
JspServletWrapper, JspRuntimeContext, and the Compiler never got gced because 
they where never dereferenced.  by forcing a new compiler each time it seems to 
solve this problem but not sure what others it could cause.

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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Tue, 2003-01-07 at 04:40, Remy Maucherat wrote:
> I'll -1 this patch unless the new behavior is made optional (and default 
> to the current behavior).
> 
> Remy

Okay, it's now an init param which defaults to false. Following are
DefaultServlet.java and web.xml patches.


--- DefaultServlet.java.orig2003-01-07 08:41:16.0 -0700
+++ DefaultServlet.java 2003-01-07 08:42:33.0 -0700
@@ -169,6 +169,10 @@
  */
 protected String welcomes[] = new String[0];
 
+/**
+ * Should we redirect or forward for welcome files?
+ */
+protected boolean forwardWelcomeFiles = false;
 
 /**
  * MD5 message digest provider.
@@ -294,6 +298,13 @@
 } catch (Throwable t) {
 ;
 }
+try {
+value =
getServletConfig().getInitParameter("forwardWelcomeFiles");
+if (value != null)
+forwardWelcomeFiles = (new
Boolean(value)).booleanValue();
+} catch (Throwable t) {
+;
+}
 
 // Sanity check on the specified buffer sizes
 if (input < 256)
@@ -957,11 +968,16 @@
 if (welcomeFileInfo != null) {
 String redirectPath = welcomeFileInfo.path;
 String contextPath = request.getContextPath();
-if ((contextPath != null) &&
(!contextPath.equals("/"))) {
+if ((contextPath != null) && (!contextPath.equals("/"))
&& (!forwardWelcomeFiles)) {
 redirectPath = contextPath + redirectPath;
 }
 redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+if (forwardWelcomeFiles) {
+  
request.getRequestDispatcher(redirectPath).forward(request, response);
+}
+else {
+   response.sendRedirect(redirectPath);
+}
 return;
 }

--- web.xml.orig2003-01-07 08:58:09.0 -0700
+++ web.xml 2003-01-07 08:50:13.0 -0700
@@ -39,6 +39,9 @@
   
   
   
+ 

+  
+  
 
 
 default







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

DO NOT REPLY [Bug 14261] - JNDI data source not configured 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=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2003-01-07 14:36 ---
This bug seems to be due to the fact that the JNDI resource config is located in
the GlobalNamingResources. When the data source config is put in the Context, it
seems to work. I haven't had a chance to check the source code, but I suspect
there is something amiss in the global resource configs.

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

RE: Unable to compile class for JSP

[Kevin Jones]

I've used 4.1.x and 4.0.x with JDK1.4 and JDK 1.4.1 and never had this
problem. 

One thing you might want to check on windows is which JRE you are using.
Sun install Java in two places, c:\j2sdk1.4.1 and c:\winnt\java (or
something similar). By default the JRE is set in the registry to be
c:\winnt\java and java.exe is copied to c:\winnt\system32. So unless you
either choose not to install the JRE, or you delete java.exe from
c:\winnt\system32 when you run java, the JRE picked up is the one
installed into c:\winnt and this one doesn't have a tools.jar.

Delete java.exe from c:\winnt\system32, set java_home to c:\j2sdk1.4.1
and add c:\j2sdk1.4.1\bin to your path, then try it again

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache
> Sent: 07 January 2003 00:53
> To: [EMAIL PROTECTED]
> Subject: Re: Unable to compile class for JSP
> 
> 
> Jeanfrancois Arcand wrote:
> 
> > Hum...I don't have any problems under win2k using Sun JDK 
> 1.4.1 (and I
> > don't remember seeing that problem with 1.4). Have you try 
> with 1.4.1? I
> > will downgrade and see
> 
> No, I'm just happy that I found the trick to make it work.
> ( I only tested tomcat4.1 with JDK1.4.0-b92 on w2k and xp )
> 
> Costin
> 
> > 
> > -- Jeanfrancois
> > 
> > Costin Manolache wrote:
> > 
> >>Just had the same problem - it seems JDK1.4 on windows has 
> an interesting
> >>behavior - it will not load javac from tools.jar unless it 
> is included in
> >>endorsed.
> >>
> >>I'm not a big windows user - if someone could confirm, we 
> need to change
> >>the scripts. I see this behavior with (at least) 1.4.0-b92.
> >>
> >>Costin
> >>
> >>
> >>Gary Pollreis wrote:
> >>
> >>  
> >>
> >>>will do - thanks for the heads up.
> >>>
> >>>-Original Message-
> >>>From: Matt Parker [mailto:[EMAIL PROTECTED]]
> >>>Sent: Monday, January 06, 2003 5:57 PM
> >>>To: Tomcat Developers List
> >>>Subject: Re: Unable to compile class for JSP
> >>>
> >>>
> >>>you should post this to the tomcat-users list. this list 
> is for issues
> >>>related to development on the tomcat product.
> >>>
> >>>
> >>>On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
> >>>
> >>>
> I have just installed Tomcat 4.1.18 under Windows 2000 
> (using Java JDK
> 1.4.0).  When I try to run the examples I get
> "org.apache.jasper.JasperException: Unable to compile 
> class for JSP" .
> I have validated that my JAVA_HOME and CATALINA_HOME environment
> variables are correct.
> Any/all help would be appreciated.  Thanks in advance.
> 
> --
> 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:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


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

RE: where to download tomcat 4.1 nightly builds?

[Kevin Jones]

Thanks both,

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: 06 January 2003 18:26
> To: Tomcat Developers List
> Subject: Re: where to download tomcat 4.1 nightly builds?
> 
> 
> Petr Jiricka wrote:
> > I was able to find them for Tomcat 5:
> > 
> > http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/
> > 
> > but not for Tomcat 4.1.
> > 
> > Speaking of 5.0, is it known when the next milestone/beta 
> of Tomcat 5 
> > will be released ? Is there any scheduled ?
> 
> Features are being added, so it got delayed.
> Tomcat 5 is supposed to be very easy to build from CVS 
> (http://jakarta.apache.org/tomcat/building.html), so IMO 
> there's little 
> point in having nightly builds.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


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

DO NOT REPLY [Bug 15834] New: - Version 2.0.2 von JK2 does not work in Win2k

[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=15834

Version 2.0.2 von JK2 does not work in Win2k

   Summary: Version 2.0.2 von JK2 does not work in Win2k
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I tried to set up Apache v 2.0.43 with Tomcat 2.1.18 wich worked fine.
Than I wanted to clue them together using JK2 v 2.0.2, where I downloaded the 
binary from the main distribution site. I did as it was explained in the docs, 
wich is really easy, thanks for that. But it didnt work. I always got the error 
message, that it could not connect to tomcat.

Then I tried JK2 v 2.0.1 and it worked at once. Thus, I would think that it is 
a bug in v 2.0.2.

Thank you very much for providing this Apache-Tomcat connectivity.

Yours 
Thomas Janke

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

Re: [PATCH] forward instead of redirect for welcome files

[Remy Maucherat]

Matt Parker wrote:

Here's the new version of the patch. the code to redirect if there is no
trailing slash remains untouched, but it now forwards if there is a
trailing slash. i've included more context to avoid potential confusion:


I'll -1 this patch unless the new behavior is made optional (and default 
to the current behavior).

Remy


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

Re: [PATCH] forward instead of redirect for welcome files

[Remy Maucherat]

Matt Parker wrote:

If you want to mirror what Apache HTTPD does:

No slash present --> append slash (only!) and redirect
Slash present --> internally forward to welcome-file page


Well, here's the rub:

- The new servlet spec clearly states that either /foo or /foo/ should
return a welcome-file (if specified)


Well, this is broken behavior. If no slash, then a redirect will be sent 
back to the client, otherwise, relative paths are not resolved 
correctly, with no way for the app writer to anticipate it.

- Apache also has the problem with a relative link on a welcome file
which has a directory specified in it


However, I think that the patch benefits still outweigh its drawbacks:

- it satisfies the new servlet spec

- it circumvents the need for special processing and configuration when
placed behind a proxy server (a farely common production practice).

- it inherits a problem, but the problem is probably rare in practice,
and will already have been avoided by Apache users since it's the same.
i.e. i've never had a burning need to specify a welcome file or
directory index that has a subdirectory in it _and_ has a relative link,
so i can only guess that others either don't or already know to avoid
it.

What do y'all think?

I vote +1 :)


I'll vote the opposite ;-)
People are used to the bahavior in 4.1. In 5.0, I plan to add the option 
for internal forwards in the new mapper I'll write.

Note that internal forwards were used in early 4.0 releases, but went 
away as it got reported as a security issue (the security checks apply 
to the original URI, not the served welcome file).

Remy


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

DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving

[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=15819

Duplicate context listener entries in server.xml when saving





--- Additional Comments From [EMAIL PROTECTED]  2003-01-07 10:22 ---
Yes - I have remove my DefaultContext and the problem no longer occurs.

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

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml

[hgomez]

hgomez  2003/01/07 01:49:12

  Modified:jk/xdocs/jk aphowto.xml
  Log:
  Add build notes for MacOS/X
  
  Revision  ChangesPath
  1.19  +22 -0 jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml
  
  Index: aphowto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- aphowto.xml   30 Dec 2002 14:16:54 -  1.18
  +++ aphowto.xml   7 Jan 2003 09:49:12 -   1.19
  @@ -863,6 +863,28 @@
   
   
   
  +
  +
  +Mac OS X (10.2.x) build notes :
  +
  +
  +Assuming that you are root :
  +
  +
  +For Apache 1.3:
  +./configure --with-apxs=/usr/sbin/apxs
  +cd apache-1.3
  +make -f Makefile.apxs
  +cp mod_jk.so /etc/libexec/httpd
  +
  +For Apache 2.0:
  +./configure --with-apxs=/usr/local/apache2/bin/apxs
  +(you should point to the directory where you installed Apache 2.0)
  +cd apache-2.0
  +make -f Makefile.apxs install
  +
  +
  +
   
   
   mod_jk allows to install mod_jk in the Apache source tree to get a statically
  
  
  

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