DO NOT REPLY [Bug 23344] - catalina.properties don't allow to add one jar file

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

catalina.properties don't allow to add one jar file





--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 07:02 ---
> This sounds reasonable. Can you submit a tested fix ?

I was trying ... 
Don't throw the challenge and solve the problem the day after! :-)
Thanks.

> Actually, you could probably use that to run Tomcat with the binary on a remote
> server, using only the bootstrap stuff (this is similar to webstart, I guess).

We working on one huge application deployable on different application server.
We use Tomcat in the development environment, here we don't deploy anything:
we set tomcat classloaders to load classes from the IDE projects directories.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core LocalStrings.properties StandardWrapper.java

[remm]

remm2003/09/23 23:56:21

  Modified:catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardWrapper.java
  Log:
  - Fix obvious issues with wait-for-unload logic (untested).
  
  Revision  ChangesPath
  1.10  +1 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- LocalStrings.properties   17 Aug 2003 08:30:44 -  1.9
  +++ LocalStrings.properties   24 Sep 2003 06:56:21 -  1.10
  @@ -165,3 +165,4 @@
   standardWrapper.unavailable=Marking servlet {0} as unavailable
   standardWrapper.unloadException=Servlet {0} threw unload() exception
   standardWrapper.unloading=Cannot allocate servlet {0} because it is being unloaded
  +standardWrapper.waiting=Waiting for {0} instance(s) to be deallocated
  
  
  
  1.33  +9 -9  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
  
  Index: StandardWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- StandardWrapper.java  17 Sep 2003 23:26:33 -  1.32
  +++ StandardWrapper.java  24 Sep 2003 06:56:21 -  1.33
  @@ -1233,13 +1233,13 @@
   // (possibly more than once if non-STM)
   if (countAllocated > 0) {
   int nRetries = 0;
  -while (nRetries < 10) {
  -if (nRetries == 0) {
  -log.info("Waiting for " + countAllocated +
  -" instance(s) to be deallocated");
  +while ((nRetries < 21) && (countAllocated > 0)) {
  +if ((nRetries % 10) == 0) {
  +log.info(sm.getString("standardWrapper.waiting",
  +  new Integer(countAllocated)));
   }
   try {
  -Thread.sleep(50);
  +Thread.sleep(100);
   } catch (InterruptedException e) {
   ;
   }
  
  
  

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

DO NOT REPLY [Bug 23371] - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 06:29 ---
Do you basically say documentation RFEs do not go into Bugzilla, but on the
mailing list?

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

DO NOT REPLY [Bug 23371] - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443





--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 06:17 ---
thanks for the fast answers; of course I've read before the security faq; but
there are no answers for my question.

So I'll give a try on tomcat-user.

But I still think it's a bug. In Apache the start fahther process runs as root
but everything else under the users I configured in the conf file.

That's the way it has to be - in my opinion - in Catalina too.

regards 

Damian

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

DO NOT REPLY [Bug 23379] New: - CoyoteAdapter An exception or error occurred in the container during the request processing

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

CoyoteAdapter An exception or error occurred in the container during the request 
processing

   Summary: CoyoteAdapter An exception or error occurred in the
container during the request processing
   Product: Tomcat 4
   Version: 4.1.27
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Anybody knows why this error can appear?

2003-09-23 18:42:09 CoyoteAdapter An exception or error occurred in the 
container during the request processing
java.lang.NullPointerException
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:164)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNe
xt(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:601)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnecti
on(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)

Thanks in advance.

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

DO NOT REPLY [Bug 23371] - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 05:26 ---
Please do not use BZ for user support !! Post on tomcat-user.

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

DO NOT REPLY [Bug 23344] - catalina.properties don't allow to add one jar file

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

catalina.properties don't allow to add one jar file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 05:22 ---
I've added the possibility to add URLs to the list. This can be local or remote
folders, or single local or remote JARs.
Actually, you could probably use that to run Tomcat with the binary on a remote
server, using only the bootstrap stuff (this is similar to webstart, I guess).

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

DO NOT REPLY [Bug 23373] - Servlet destroy() methods not being called at shutdown

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

Servlet destroy() methods not being called at shutdown

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 05:19 ---
This obviously works fine for me (I did test it again just to be sure). The
stopServer method is run in a separate JVM, so there can't be any side effect ;-)
Please reopen if you can submit a ready to test WAR (with source for the
servlet, so that it can be debugged if needed). Thanks.

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

DO NOT REPLY [Bug 23371] - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 05:18 ---
Tim, Thanks for the quick reply.

Unfortunately, on the page you reference I don't see port 80 mentioned.
- "How to I force all my pages to run under HTTPS?"
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23371 mentions
security-constraints in web.xml once a httpd has taken port 80 and 443, but not
how I can convince linux to give a port < 1000 to a non-root user in the first
place.

- "Tomcat as root and security issues" basically mentions squid or other port
forwarders... ==> if the answer is that Tomcat can't run under 443 or 80
standalone as non-root, then, my suggestion is to add another paragraph to the
security FAQ!

Looking around for similar useful information, for example
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/RUNNING.txt only hints at port
8080 but not sub 1000 ports.

In many environments firewalls restrict outgoing traffic to 80 and 443. Does
this mean that all the users of these environments can never see a standalone
tomcat site?

Or, at least has anybody built and successfully deployed a chroot'ing
starter-utility that could be easily used for this as a second-best fix?

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

Re: our attempt to build tomcat 4.1.27 from source on Solaris 2.8

[Bill Barker]

It doesn't look like you got the servletapi-4 project (or it is in the wrong
place).  Try doing:
   ant download
to make certain that you've got all of the jars you need to build Tomcat.
If you are behind a firewall, you'll need to set the values of 'proxy.host'
and 'proxy.port' in your build.properties file first.

I build Tomcat 4.1.x from source on Solaris pretty regularly, so it
definately can be done ;-).

"Ziying Sherwin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Dear tomcat Colleagues,
>
> We have been trying to build tomcat 4.1.27 from source, which we
downloaded
> from the cvs repository (cvs.apache.org) onto a SPARC computer
> running Solaris 2.8, using j2sdk 1.4.0.  Unfortunately, the installation
> failed, and we are hoping to find helpful insights to get us back on the
road.
> We have successfully installed the pre-built binary for tomcat, but
strongly
> prefer to build it from source.  We posted several messages to the mailing
> list several weeks ago, asking for help, but received no replies.
>
> Here is a detailed summary of what we did, and the outcome.
> FIrst, we installed the following related packages:
>
>ant 1.5.3-1
>jaf 1.0.2
>Java XML Pack Fall 01 FCS Bundle
>javamail 1.3
>jdbc 2.0
>JMX 1.2
>JNDI 1.2.1
>jsse 1.0.2
>jta 1.0.1
>xerces 2.4.0
>
> We downloaded the following tomcat modules from the indicated locations:
>
>commons-beanutils-1.6.1
(http://www.apache.org/dist/jakarta/commons/beanutils/binaries/commons-beanu
tils-1.6.1.tar.gz)
>commons-collections-2.1
(http://www.apache.org/dist/jakarta/commons/collections/binaries/collections
-2.1.tar.gz)
>commons-digester-1.4.1
(http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digest
er-1.4.1.tar.gz)
>commons-dbcp-1.0
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/
commons-dbcp-1.0.zip)
>commons-fileupload-1.0
(http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-cu
rrent.tar.gz)
>commons-logging-1.0.2
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1
.0.2/commons-logging-1.0.2.tar.gz)
>commons-modeler-1.0
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1
.0/commons-modeler-1.0.tar.gz)
>commons-pool-1.0.1
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-pool/v1.0.
1/commons-pool-1.0.1.tar.gz)
>struts
(http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-stru
ts-1.0.2.tar.gz)
>
> We also obtained the cvs versions of "jakarta-tomcat-connectors" and
> "jakarta-tomcat-jasper" from the jakarta site from which we obtained
tomcat.
>
> We customized the build properties by editing the file build.properties to
> reflect the correct paths to all the packages.
>
> However, when we started to build the package using command "ant dist", we
> observed the following error messages:
>
>build-only:
>[javac] Compiling 79 source files to
/src/tomcat_4.1.27/jasper/build/shared/classes
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/JspC.java:71: package javax.servlet does not exist
>[javac] import javax.servlet.ServletException;
>[javac]  ^
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/Options.java:66: package javax.servlet does not exist
>[javac] import javax.servlet.ServletConfig;
>[javac]  ^
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/Options.java:67: package javax.servlet does not exist
>[javac] import javax.servlet.ServletContext;
>[javac]  ^
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/servlet/JspCServletContext.java:73: package javax.servlet does not exist
>[javac] import javax.servlet.RequestDispatcher;
>[javac]  ^
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/servlet/JspCServletContext.java:74: package javax.servlet does not exist
>[...]
>
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/compiler/JspUtil.java:105: cannot resolve symbol
>[javac] symbol  : class ExpressionEvaluatorImpl
>[javac] location: class org.apache.jasper.compiler.JspUtil
>[javac] private static ExpressionEvaluatorImpl
expressionEvaluator
>[javac]^
>[javac]
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
/compiler/JspUtil.java:627: cannot resolve symbol
>[javac] symbol  : class FunctionMapper
>[javac] location: class org.apache.jasper.compiler.JspUtil
>[javac]FunctionMapper
functionMapper,
>[javac]   

DO NOT REPLY [Bug 10373] - Wrong response status code for custom error page

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

Wrong response status code for custom error page





--- Additional Comments From [EMAIL PROTECTED]  2003-09-24 02:35 ---
This is a very questionable and unfortunate decision.

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

DO NOT REPLY [Bug 10373] - Wrong response status code for custom error page

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

Wrong response status code for custom error page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 23:55 ---
In error pages, it is the responsibility of the jsp page author to reset the
error code to the correct state. You find this behavior in other containers too.

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

DO NOT REPLY [Bug 23371] - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 23:06 ---
See the faq http://jakarta.apache.org/tomcat/faq/security.html
substitute 443 anytime anyone says 80

Please follow up with tomcat-user if you have more questions.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java

[Jean-Francois Arcand]

Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

jfarcand2003/09/23 14:37:01

Modified:catalina/src/share/org/apache/catalina/startup 
ContextConfig.java TldConfig.java Log: Revert my previous patch since
it force validation even when the value is set to false (for schema).


I didn't upgrade back to X 2.5, but with X 2.1, this didn't force 
validation.

I'm sure it's a bit hard to follow for everyone. Can you do a recap on 
tomcat-dev of what's wrong with Xerces, and what is being done about it ?
Curently, schema validation doesn't work when you turns it on in 
server.xml. The problem resides in ContextConfig.java when you do 
webDigester.setSchema(). For a reason I'm trying to find, the schema 
file is not loaded by Xerces. I suspect a classloader issue but the 
validation task suffer the same problem.

I'm trying to resolve the problem right now with the jaxp team, but if 
someone wants to create a test case and file a bug againts Xerces, I 
will be more that happy. Knowing how they work, without a little test 
case, they will never looks at it ;-)

-- Jeanfrancois



Thanks,
Remy


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


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

FW: tomcat binary page links not up

[Pier Fumagalli]

FYI


-- Forwarded Message
> From: Michael Kidd <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 23 Sep 2003 14:46:52 -0700
> To: [EMAIL PROTECTED]
> Subject: tomcat binary page links not up
> 
> Webmaster,
> 
> I'm trying to download a tomcat file on the following page:
> 
> http://jakarta.apache.org/site/binindex.html
> 
> I keep getting a 404 error message, so I am unable to download the
> current version of Tomcat.  It looks like all the links on this page for
> downloading are not correct either.
> 
> 
> -- 
> 
> Michael Kidd
> Line Support Technician - SBBT/FBBT
> (510) 714-0123 (cell)
> X32787
> 
> 
> 
> 
> 

-- End of Forwarded Message


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

Servlet destory method not being called

[Oxley, David]

I've just reported a serious bug that means that servlet destroy methods
don't get called on server shutdown. See my comments at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23373

Dave.




This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

DO NOT REPLY [Bug 23373] - Servlet destroy() methods not being called at shutdown

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

Servlet destroy() methods not being called at shutdown





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 22:08 ---
Created an attachment (id=8322)
There are several ways to fix this. IMO this is probably the tidiest!

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

DO NOT REPLY [Bug 23373] New: - Servlet destroy() methods not being called at shutdown

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

Servlet destroy() methods not being called at shutdown

   Summary: Servlet destroy() methods not being called at shutdown
   Product: Tomcat 5
   Version: 5.0.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


No servlet destroy() methods are being called at shutdown.
The problem is that the stopServer method in Catalina.java constructs a new 
StandardServer and the digester.parse(is); on line 423 results in a call back 
to setServer which means that when the SHUTDOWN command is sent to the server, 
it actually goes to the new !started server.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

jfarcand2003/09/23 14:37:01

Modified:catalina/src/share/org/apache/catalina/startup 
ContextConfig.java TldConfig.java Log: Revert my previous patch since
it force validation even when the value is set to false (for schema).
I didn't upgrade back to X 2.5, but with X 2.1, this didn't force 
validation.

I'm sure it's a bit hard to follow for everyone. Can you do a recap on 
tomcat-dev of what's wrong with Xerces, and what is being done about it ?

Thanks,
Remy


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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java

[jfarcand]

jfarcand2003/09/23 14:37:01

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java TldConfig.java
  Log:
  Revert my previous patch since it force validation even when the value is set to 
false (for schema).
  
  Revision  ChangesPath
  1.35  +2 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- ContextConfig.java23 Sep 2003 18:43:12 -  1.34
  +++ ContextConfig.java23 Sep 2003 21:37:00 -  1.35
  @@ -459,8 +459,6 @@
   try{
   digester.setFeature(
   "http://apache.org/xml/features/allow-java-encodings";, true);
  -digester.setFeature(
  -"http://apache.org/xml/features/validation/schema";, true);
   } catch(ParserConfigurationException e){
   // log("contextConfig.registerLocalSchema", e);
   } catch(SAXNotRecognizedException e){
  @@ -492,7 +490,6 @@
   boolean validation) {
   URL url = null;
   Digester webDigester = new Digester();
  -webDigester.setUseContextClassLoader(false);
   webDigester.setNamespaceAware(namespaceAware);
   webDigester.setValidating(validation);
  
  @@ -507,7 +504,7 @@
   if (validation) {
   webDigester.setSchema(url.toString());
   }
  -
  +
   url = ContextConfig.class.getResource(Constants.WebDtdResourcePath_22);
   webEntityResolver.register(Constants.WebDtdPublicId_22,
  url.toString());
  
  
  
  1.28  +0 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
  
  Index: TldConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- TldConfig.java23 Sep 2003 20:06:07 -  1.27
  +++ TldConfig.java23 Sep 2003 21:37:00 -  1.28
  @@ -437,8 +437,6 @@
   try{
   digester.setFeature(
   "http://apache.org/xml/features/allow-java-encodings";, true);
  -digester.setFeature(
  -"http://apache.org/xml/features/validation/schema";, true);
   } catch(ParserConfigurationException e){
   // log("contextConfig.registerLocalSchema", e);
   } catch(SAXNotRecognizedException e){
  
  
  

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

Re: admin commit stops the app and doesn't restart

[Remy Maucherat]

Amy Roh wrote:

The admin logs you out after "commit" due to the following error.  Looks 
like "commit" stopped the app and didn't restart correctly.

Comments?
Being less passive about problems can't hurt ;-)
It is normal that a webapp is redeployed after committing since it 
modifies the context file of the webapp (so everything will be 
redeployed). This is the only bad side effect of the improved deployer.

As for the CL problems, well you can get that if the context CL is bad 
somewhere. This obviously works fine for me, though.

Remy



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

cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.properties

[luehe]

luehe   2003/09/23 14:10:28

  Modified:catalina/src/conf catalina.properties
  Log:
  Added noTldJars property
  
  Revision  ChangesPath
  1.8   +5 -0  jakarta-tomcat-catalina/catalina/src/conf/catalina.properties
  
  Index: catalina.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.properties,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- catalina.properties   3 Jan 2003 15:39:53 -   1.7
  +++ catalina.properties   23 Sep 2003 21:10:28 -  1.8
  @@ -53,3 +53,8 @@
   #  repositories
   # "foo/bar.jar": Add bar.jar as a class repository 
   shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
  +
  +#
  +# List of comma-separated names of JAR files that are known not to contain
  +# any TLDs
  
+noTldJars=ant.jar,catalina.jar,catalina-ant.jar,catalina-cluster.jar,catalina-optional.jar,catalina-i18n-fr.jar,catalina-i18n-ja.jar,catalina-i18n-es.jar,commons-dbcp.jar,commons-modeler.jar,commons-logging-api.jar,commons-beanutils.jar,commons-fileupload-1.0.jar,commons-pool.jar,commons-digester.jar,commons-logging.jar,commons-collections.jar,commons-el.jar,jakarta-regexp-1.2.jar,jasper-compiler.jar,jasper-runtime.jar,jmx.jar,jmx-tools.jar,jsp-api.jar,jkshm.jar,jkconfig.jar,naming-common.jar,naming-resources.jar,naming-factory.jar,naming-java.jar,servlet-api.jar,servlets-default.jar,servlets-invoker.jar,servlets-common.jar,servlets-webdav.jar,tomcat-util.jar,tomcat-http11.jar,tomcat-jni.jar,tomcat-jk.jar,tomcat-jk2.jar,tomcat-coyote.jar,xercesImpl.jar,xmlParserAPIs.jar,sunjce_provider.jar,ldapsec.jar,localedata.jar,dnsns.jar
  
  
  

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

admin commit stops the app and doesn't restart

[Amy Roh]

The admin logs you out after "commit" due to the following error.  Looks 
like "commit" stopped the app and didn't restart correctly.

Comments?
Amy
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.coyote.tomcat5.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the 
request proce
ssing
java.lang.ThreadDeath
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1252)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1212)
at java.beans.Introspector.instantiate(Introspector.java:1293)
at 
java.beans.Introspector.findExplicitBeanInfo(Introspector.java:382)
at java.beans.Introspector.(Introspector.java:331)
at java.beans.Introspector.getBeanInfo(Introspector.java:132)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(Pro
pertyUtils.java:949)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(Pro
pertyUtils.java:979)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(Prop
ertyUtils.java:887)
at 
org.apache.commons.beanutils.PropertyUtils.getSimpleProperty(Property
Utils.java:1172)
at 
org.apache.commons.beanutils.PropertyUtils.getNestedProperty(Property
Utils.java:772)
at 
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.
java:801)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:297)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardContextValve.invokeInternal(Standard
ContextValve.java:245)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:199)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:573)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:149)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:195)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:164)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:149)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:156)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)

at 
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:20
9)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:670)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ssConnection(Http11Protocol.java:517)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java
:580)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:666)
at java.lang.Thread.run(Thread.java:536)



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

DO NOT REPLY [Bug 23371] New: - running tomcat standalone as non-root on port 443

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

running tomcat standalone as non-root on port 443

   Summary: running tomcat standalone as non-root on port 443
   Product: Tomcat 4
   Version: 4.1.27
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


I have to run Tomcat standalone as user e.g tomcat (non-root) on port 443.
But the server doesn't start (not able to bind port 443).
With 8443 everything works fine.

Why can't tomcat do that like apache ?

Thanks for hints or help.

I'm running Version 4.1.27 on SuSE 8.2 with SUN Java 2 Standard Edition (build
1.4.1_02-b06)

regards,

Damian

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

Re: \<% not handled right?

[Kin-Man Chung]

This is a bug.  I have committed a fix in Tomcat 5.  Thanks for reporting.

-Kin-man

> Date: Tue, 23 Sep 2003 07:30:29 -0400
> From: Tim Funk <[EMAIL PROTECTED]>
> Subject: \<% not handled right?
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 
> Attached is a note from tomcat-user which I think might be a bug in jasper.
> 
> Summary it you don't want to read it...
> Take this page:
> -
> <%="BAR"%>
> \<%="bar"%>
> -
> 
> It produces:
> BAR
> \<%="bar"%>
> 
> Instead of
> BAR
> \bar
> 
> The spec says to escape <% with <\%
> 
> -Tim
> 
>  Original Message 
> Subject: JSP Compilation Problem
> Date: Tue, 23 Sep 2003 13:23:30 +0300
> From: Anatol Pomazau <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 
> Hi.
> 
> I just upgrade tomcat server from 4.1.12 to Tomcat-dev (I get sources
> from CVS and compile it yesterday)
> But I have a problem with one jsp.
> So, such code
>   <% String fullname = "Anatol Pomazau"; %>
>href="\\epmsa007\applForm\new_applicant_form\<%=fullname%>.doc"><%=fulln
> ame%>
> Works fine in old version but in new Tomcat generates
>href="\\epmsa007\applForm\new_applicant_form\<%=fullname%>.doc">Anatol
> Pomazau
> Insead of
>href="\\epmsa007\applForm\new_applicant_form\Anatol Pomazau.doc">Anatol
> Pomazau
> 
> I have looked JSP Spec 2.0 and I have not found any remarks about such
> quoting.
> 
> What I do wrong? Please help me.
> 
> 
> EPAM Systems, Minsk, Belarus
> work: +375 17 210 1662, ext. #1373
> icq uin: 138182429
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

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

[kinman]

kinman  2003/09/23 13:47:23

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  - Fix bug: \<%foo%> in template text hides expression.
  
  Revision  ChangesPath
  1.82  +10 -7 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.81
  retrieving revision 1.82
  diff -u -r1.81 -r1.82
  --- Parser.java   23 Sep 2003 00:08:22 -  1.81
  +++ Parser.java   23 Sep 2003 20:47:23 -  1.82
  @@ -1486,10 +1486,13 @@
ttext.write('\\');
break;
}
  - ch = reader.nextChar();
  - // Looking for \% or \$
  - if (ch != '%' && ch != '$') {
  - ttext.write('\\');
  +char next = (char)reader.peekChar();
  +// Looking for \% or \$
  +// TODO: only recognize \$ if isELIgnored is false, but since
  +// it can be set in a page directive, it cannot be determined
  +// here.  Argh!
  +if (next == '%' || next == '$') {
  +ch = reader.nextChar();
   }
}
ttext.write(ch);
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup TldConfig.java

[luehe]

luehe   2003/09/23 13:06:07

  Modified:catalina/src/share/org/apache/catalina/startup
TldConfig.java
  Log:
  improved javadocs
  
  Revision  ChangesPath
  1.27  +10 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
  
  Index: TldConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- TldConfig.java23 Sep 2003 19:47:52 -  1.26
  +++ TldConfig.java23 Sep 2003 20:06:07 -  1.27
  @@ -724,16 +724,23 @@
   }
   
   /**
  - * Returns a map of the paths to all JAR files accessible to the webapp.
  + * Returns a map of the paths to all JAR files that are accessible to the
  + * webapp and will be scanned for TLDs.
*
  - * The map includes the JARs under WEB-INF/lib as well as those in the
  - * classloader delegation chain of the webapp's classloader.
  + * The map always includes all the JARs under WEB-INF/lib, as well as
  + * shared JARs in the classloader delegation chain of the webapp's
  + * classloader.
*
* The latter constitutes a Tomcat-specific extension to the TLD search
* order defined in the JSP spec. It allows tag libraries packaged as JAR
* files to be shared by web applications by simply dropping them in a 
* location that all web applications have access to (e.g.,
* /common/lib).
  + *
  + * The set of shared JARs to be scanned for TLDs is narrowed down by
  + * the list of JARs specified as the value of the noTldJars
  + * property in catalina.properties, which are known not to contain any 
  + * TLDs.
*
* @return Map of JAR file paths
*/
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup TldConfig.java catalina.properties

[luehe]

luehe   2003/09/23 12:47:52

  Modified:catalina/src/share/org/apache/catalina/startup
TldConfig.java catalina.properties
  Log:
  Made noTldJars are configurable property in catalina.properties, as suggested by 
Jeanfrancois Arcand
  
  Revision  ChangesPath
  1.26  +11 -50
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
  
  Index: TldConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- TldConfig.java23 Sep 2003 18:48:36 -  1.25
  +++ TldConfig.java23 Sep 2003 19:47:52 -  1.26
  @@ -77,6 +77,7 @@
   import java.util.Iterator;
   import java.util.Map;
   import java.util.Set;
  +import java.util.StringTokenizer;
   import java.util.jar.JarEntry;
   import java.util.jar.JarFile;
   
  @@ -107,7 +108,7 @@
*/
   public final class TldConfig  {
   
  -// Set of JARs that are known not to contain any TLDs
  +// Names of JARs that are known not to contain any TLDs
   private static HashSet noTldJars;
   
   private static org.apache.commons.logging.Log log=
  @@ -121,55 +122,14 @@
* Initializes the set of JARs that are known not to contain any TLDs
*/
   static {
  -noTldJars = new HashSet();
  -noTldJars.add("ant.jar");
  -noTldJars.add("catalina.jar");
  -noTldJars.add("catalina-ant.jar");
  -noTldJars.add("catalina-cluster.jar");
  -noTldJars.add("catalina-optional.jar");
  -noTldJars.add("catalina-i18n-fr.jar");
  -noTldJars.add("catalina-i18n-ja.jar");
  -noTldJars.add("catalina-i18n-es.jar");
  -noTldJars.add("commons-dbcp.jar");
  -noTldJars.add("commons-modeler.jar");
  -noTldJars.add("commons-logging-api.jar");
  -noTldJars.add("commons-beanutils.jar");
  -noTldJars.add("commons-fileupload-1.0.jar");
  -noTldJars.add("commons-pool.jar");
  -noTldJars.add("commons-digester.jar");
  -noTldJars.add("commons-logging.jar");
  -noTldJars.add("commons-collections.jar");
  -noTldJars.add("commons-el.jar");
  -noTldJars.add("jakarta-regexp-1.2.jar");
  -noTldJars.add("jasper-compiler.jar");
  -noTldJars.add("jasper-runtime.jar");
  -noTldJars.add("jmx.jar");
  -noTldJars.add("jmx-tools.jar");
  -noTldJars.add("jsp-api.jar");
  -noTldJars.add("jkshm.jar");
  -noTldJars.add("jkconfig.jar");
  -noTldJars.add("naming-common.jar");
  -noTldJars.add("naming-resources.jar");
  -noTldJars.add("naming-factory.jar");
  -noTldJars.add("naming-java.jar");
  -noTldJars.add("servlet-api.jar");
  -noTldJars.add("servlets-default.jar");
  -noTldJars.add("servlets-invoker.jar");
  -noTldJars.add("servlets-common.jar");
  -noTldJars.add("servlets-webdav.jar");
  -noTldJars.add("tomcat-util.jar");
  -noTldJars.add("tomcat-http11.jar");
  -noTldJars.add("tomcat-jni.jar");
  -noTldJars.add("tomcat-jk.jar");
  -noTldJars.add("tomcat-jk2.jar");
  -noTldJars.add("tomcat-coyote.jar");
  -noTldJars.add("xercesImpl.jar");
  -noTldJars.add("xmlParserAPIs.jar");
  -// JARs from J2SE runtime
  -noTldJars.add("sunjce_provider.jar");
  -noTldJars.add("ldapsec.jar");
  -noTldJars.add("localedata.jar");
  -noTldJars.add("dnsns.jar");
  +String value = CatalinaProperties.getProperty("noTldJars");
  +if (value != null) {
  +noTldJars = new HashSet();
  +StringTokenizer tokenizer = new StringTokenizer(value, ",");
  +while (tokenizer.hasMoreElements()) {
  +noTldJars.add(tokenizer.nextToken());
  +}
  +}
   }
   
   
  @@ -809,6 +769,7 @@
* that are not known not to contain any TLDs
*/
   if (loader == webappLoader
  +|| noTldJars == null
   || !noTldJars.contains(file.getName())) {
   if (jarPathMap == null) {
   jarPathMap = new HashMap();
  
  
  
  1.3   +5 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties
  
  Index: catalina.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- catalina.properties   5 Nov 2002 08:07:46 -   1.2
  +++ catalina.proper

cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin TomcatTreeBuilder.java

[amyroh]

amyroh  2003/09/23 12:29:36

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
TomcatTreeBuilder.java
  Log:
  Fix to not display JAASRealm node since admin doesn't support editing such Realm - 
bugtraq 4926142.
  
  Revision  ChangesPath
  1.8   +14 -9 
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java
  
  Index: TomcatTreeBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- TomcatTreeBuilder.java24 Apr 2003 07:56:33 -  1.7
  +++ TomcatTreeBuilder.java23 Sep 2003 19:29:36 -  1.8
  @@ -72,6 +72,8 @@
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import javax.servlet.http.HttpSession;
  +import org.apache.commons.modeler.ManagedBean;
  +import org.apache.commons.modeler.Registry;
   import org.apache.struts.action.Action;
   import org.apache.struts.action.ActionErrors;
   import org.apache.struts.action.ActionForm;
  @@ -434,10 +436,12 @@
   Lists.getRealms(mBServer, containerName).iterator();
   while (realmNames.hasNext()) {
   String realmName = (String) realmNames.next();
  -ObjectName objectName = new ObjectName(realmName);
  -String nodeLabel = "Realm for " + containerNode.getLabel();
  -TreeControlNode realmNode =
  -new TreeControlNode(realmName,
  + ManagedBean mb = Registry.getRegistry().findManagedBean(realmName);
  + if (mb!=null && !mb.getName().equals("JAASRealm")) {
  + ObjectName objectName = new ObjectName(realmName);
  + String nodeLabel = "Realm for " + containerNode.getLabel();
  + TreeControlNode realmNode =
  + new TreeControlNode(realmName,
   "Realm.gif",
   nodeLabel,
   "EditRealm.do?select=" +
  @@ -446,7 +450,8 @@
   URLEncoder.encode(nodeLabel),
   "content",
   false, domain);
  -containerNode.addChild(realmNode);
  +containerNode.addChild(realmNode);
  + }
   }
   
   }   
  
  
  

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

DO NOT REPLY [Bug 23340] - Web Server starts and immediately stops within a few seconds.

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

Web Server starts and immediately stops within a few seconds.





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 19:14 ---
The first time around I pointed to the JSDK 1.3.1 on my computer. The second 
time I took the default that showed up in the window during setup. This last 
time around I downloaded the new SJDK 1.4.2 w/Netbeans from www.sun.com and 
pointed to the JSDK1.4.1 folder during setup. Am I using/downloading the 
incorrect files? If so, which file should I download from Sun. I am also 
running Oracle 9i on my W2K Pro, could that interfere with the setup

My laptop apparently had the correct files and so this problem wasn't an issue, 
however I'm running 5.06 and not 5.0.12. Don't want to mess with something that 
is working.

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

our attempt to build tomcat 4.1.27 from source on Solaris 2.8

[Ziying Sherwin]

Dear tomcat Colleagues,

We have been trying to build tomcat 4.1.27 from source, which we downloaded 
from the cvs repository (cvs.apache.org) onto a SPARC computer
running Solaris 2.8, using j2sdk 1.4.0.  Unfortunately, the installation
failed, and we are hoping to find helpful insights to get us back on the road.
We have successfully installed the pre-built binary for tomcat, but strongly
prefer to build it from source.  We posted several messages to the mailing
list several weeks ago, asking for help, but received no replies.

Here is a detailed summary of what we did, and the outcome.
FIrst, we installed the following related packages:

   ant 1.5.3-1
   jaf 1.0.2
   Java XML Pack Fall 01 FCS Bundle
   javamail 1.3
   jdbc 2.0 
   JMX 1.2
   JNDI 1.2.1
   jsse 1.0.2
   jta 1.0.1
   xerces 2.4.0

We downloaded the following tomcat modules from the indicated locations:

   commons-beanutils-1.6.1 
(http://www.apache.org/dist/jakarta/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz)
   commons-collections-2.1 
(http://www.apache.org/dist/jakarta/commons/collections/binaries/collections-2.1.tar.gz)
   commons-digester-1.4.1 
(http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.1.tar.gz)
   commons-dbcp-1.0 
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/commons-dbcp-1.0.zip)
   commons-fileupload-1.0 
(http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-current.tar.gz)
   commons-logging-1.0.2 
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2/commons-logging-1.0.2.tar.gz)
   commons-modeler-1.0 
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz)
   commons-pool-1.0.1 
(http://jakarta.apache.org/builds/jakarta-commons/release/commons-pool/v1.0.1/commons-pool-1.0.1.tar.gz)
   struts 
(http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-struts-1.0.2.tar.gz)

We also obtained the cvs versions of "jakarta-tomcat-connectors" and 
"jakarta-tomcat-jasper" from the jakarta site from which we obtained tomcat.

We customized the build properties by editing the file build.properties to 
reflect the correct paths to all the packages.

However, when we started to build the package using command "ant dist", we
observed the following error messages:

   build-only:
   [javac] Compiling 79 source files to 
/src/tomcat_4.1.27/jasper/build/shared/classes
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java:71:
 package javax.servlet does not exist
   [javac] import javax.servlet.ServletException;
   [javac]  ^
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java:66:
 package javax.servlet does not exist
   [javac] import javax.servlet.ServletConfig;
   [javac]  ^
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java:67:
 package javax.servlet does not exist
   [javac] import javax.servlet.ServletContext;
   [javac]  ^
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java:73:
 package javax.servlet does not exist
   [javac] import javax.servlet.RequestDispatcher;
   [javac]  ^
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java:74:
 package javax.servlet does not exist
   [...]
   
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java:105:
 cannot resolve symbol
   [javac] symbol  : class ExpressionEvaluatorImpl  
   [javac] location: class org.apache.jasper.compiler.JspUtil
   [javac] private static ExpressionEvaluatorImpl expressionEvaluator
   [javac]^
   [javac] 
/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java:627:
 cannot resolve symbol
   [javac] symbol  : class FunctionMapper  
   [javac] location: class org.apache.jasper.compiler.JspUtil
   [javac]FunctionMapper 
functionMapper,
   [javac]^
   [javac] Note: Some input files use or override a deprecated API.
   [javac] Note: Recompile with -deprecation for details.
   [javac] 100 errors
   
   BUILD FAILED
   file:/src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/build.xml:127: Compile 
failed; see the compiler error output for details.

There is no mention of jasper in the file BUILDING.txt which came with the 
source distribution.  Is jasper required by the tomcat build?  If not, is there 
a way to disable it?  How can we build jasper from source?

Thanks in advance for any insights into our problems!

Best Regards,

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup TldConfig.java

[luehe]

luehe   2003/09/23 11:48:36

  Modified:catalina/src/share/org/apache/catalina/startup
TldConfig.java
  Log:
  Do not search *shared* JARs that are known not to contain any TLDs for TLDs.
  JARs in WEB-INF/lib are *always* searched, as mandated by the spec.
  
  Revision  ChangesPath
  1.25  +81 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
  
  Index: TldConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- TldConfig.java23 Sep 2003 18:43:12 -  1.24
  +++ TldConfig.java23 Sep 2003 18:48:36 -  1.25
  @@ -96,6 +96,7 @@
   import org.xml.sax.InputSource;
   import org.xml.sax.SAXNotRecognizedException;
   import org.xml.sax.SAXNotSupportedException;
  +
   /**
* Startup event listener for a Context that configures the properties
* of that Context, and the associated defined servlets.
  @@ -106,12 +107,72 @@
*/
   public final class TldConfig  {
   
  +// Set of JARs that are known not to contain any TLDs
  +private static HashSet noTldJars;
  +
   private static org.apache.commons.logging.Log log=
   org.apache.commons.logging.LogFactory.getLog( TldConfig.class );
   
   private static final String FILE_URL_PREFIX = "file:";
   private static final int FILE_URL_PREFIX_LEN = FILE_URL_PREFIX.length();
   
  +
  +/*
  + * Initializes the set of JARs that are known not to contain any TLDs
  + */
  +static {
  +noTldJars = new HashSet();
  +noTldJars.add("ant.jar");
  +noTldJars.add("catalina.jar");
  +noTldJars.add("catalina-ant.jar");
  +noTldJars.add("catalina-cluster.jar");
  +noTldJars.add("catalina-optional.jar");
  +noTldJars.add("catalina-i18n-fr.jar");
  +noTldJars.add("catalina-i18n-ja.jar");
  +noTldJars.add("catalina-i18n-es.jar");
  +noTldJars.add("commons-dbcp.jar");
  +noTldJars.add("commons-modeler.jar");
  +noTldJars.add("commons-logging-api.jar");
  +noTldJars.add("commons-beanutils.jar");
  +noTldJars.add("commons-fileupload-1.0.jar");
  +noTldJars.add("commons-pool.jar");
  +noTldJars.add("commons-digester.jar");
  +noTldJars.add("commons-logging.jar");
  +noTldJars.add("commons-collections.jar");
  +noTldJars.add("commons-el.jar");
  +noTldJars.add("jakarta-regexp-1.2.jar");
  +noTldJars.add("jasper-compiler.jar");
  +noTldJars.add("jasper-runtime.jar");
  +noTldJars.add("jmx.jar");
  +noTldJars.add("jmx-tools.jar");
  +noTldJars.add("jsp-api.jar");
  +noTldJars.add("jkshm.jar");
  +noTldJars.add("jkconfig.jar");
  +noTldJars.add("naming-common.jar");
  +noTldJars.add("naming-resources.jar");
  +noTldJars.add("naming-factory.jar");
  +noTldJars.add("naming-java.jar");
  +noTldJars.add("servlet-api.jar");
  +noTldJars.add("servlets-default.jar");
  +noTldJars.add("servlets-invoker.jar");
  +noTldJars.add("servlets-common.jar");
  +noTldJars.add("servlets-webdav.jar");
  +noTldJars.add("tomcat-util.jar");
  +noTldJars.add("tomcat-http11.jar");
  +noTldJars.add("tomcat-jni.jar");
  +noTldJars.add("tomcat-jk.jar");
  +noTldJars.add("tomcat-jk2.jar");
  +noTldJars.add("tomcat-coyote.jar");
  +noTldJars.add("xercesImpl.jar");
  +noTldJars.add("xmlParserAPIs.jar");
  +// JARs from J2SE runtime
  +noTldJars.add("sunjce_provider.jar");
  +noTldJars.add("ldapsec.jar");
  +noTldJars.add("localedata.jar");
  +noTldJars.add("dnsns.jar");
  +}
  +
  +
   // - Instance Variables
   
   /**
  @@ -720,7 +781,8 @@
   
   HashMap jarPathMap = null;
   
  -ClassLoader loader = Thread.currentThread().getContextClassLoader();
  +ClassLoader webappLoader = Thread.currentThread().getContextClassLoader();
  +ClassLoader loader = webappLoader;
   while (loader != null) {
   if (loader instanceof URLClassLoader) {
   URL[] urls = ((URLClassLoader) loader).getURLs();
  @@ -735,15 +797,24 @@
   } catch (IOException e) {
   // Ignore
   }
  -if (file.exists()) {
  -String path = file.getAbsolutePath();
  -if (path.endsWith(".jar")) {
  -if (jarPathMap == null) {
  -jarPathMap = new HashMap();
  -jarPathMa

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java

[jfarcand]

jfarcand2003/09/23 11:43:12

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java TldConfig.java
  Log:
  Partial fix for xml validation. At least DTD works now and the stack trace for 
schema is no longer 1 km long.
  
  Revision  ChangesPath
  1.34  +4 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- ContextConfig.java9 Sep 2003 15:27:00 -   1.33
  +++ ContextConfig.java23 Sep 2003 18:43:12 -  1.34
  @@ -459,6 +459,8 @@
   try{
   digester.setFeature(
   "http://apache.org/xml/features/allow-java-encodings";, true);
  +digester.setFeature(
  +"http://apache.org/xml/features/validation/schema";, true);
   } catch(ParserConfigurationException e){
   // log("contextConfig.registerLocalSchema", e);
   } catch(SAXNotRecognizedException e){
  @@ -490,6 +492,7 @@
   boolean validation) {
   URL url = null;
   Digester webDigester = new Digester();
  +webDigester.setUseContextClassLoader(false);
   webDigester.setNamespaceAware(namespaceAware);
   webDigester.setValidating(validation);
  
  
  
  
  1.24  +2 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java
  
  Index: TldConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- TldConfig.java22 Sep 2003 23:56:11 -  1.23
  +++ TldConfig.java23 Sep 2003 18:43:12 -  1.24
  @@ -416,6 +416,8 @@
   try{
   digester.setFeature(
   "http://apache.org/xml/features/allow-java-encodings";, true);
  +digester.setFeature(
  +"http://apache.org/xml/features/validation/schema";, true);
   } catch(ParserConfigurationException e){
   // log("contextConfig.registerLocalSchema", e);
   } catch(SAXNotRecognizedException e){
  
  
  

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

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

[jfarcand]

jfarcand2003/09/23 11:41:11

  Modified:.build.properties.default
  Log:
  Use Xerces 2.5 as it validate DT properly (only schema are broken). Working on a 
solution.
  
  Revision  ChangesPath
  1.108 +3 -3  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.107
  retrieving revision 1.108
  diff -u -r1.107 -r1.108
  --- build.properties.default  8 Sep 2003 10:11:39 -   1.107
  +++ build.properties.default  23 Sep 2003 18:41:11 -  1.108
  @@ -126,11 +126,11 @@
   
   
   # - Xerces XML Parser, version 2.5.0 -
  -xerces.home=${base.path}/xerces-2_1_0
  +xerces.home=${base.path}/xerces-2_5_0
   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/old_xerces2/Xerces-J-bin.2.1.0.tar.gz
  +xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.5.0.tar.gz
   
   
   # --
  
  
  

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

DO NOT REPLY [Bug 23336] - Error including Hibernate libraries on JSP page

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

Error including Hibernate libraries on JSP page





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 18:04 ---
Thanks for the response. I will do it, but I think this is not a solution, it's
a "work arround" and this is a bug.

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

DO NOT REPLY [Bug 23357] New: - TRAX and Xalan get confused when writing to a JspWriter

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

TRAX and Xalan get confused when writing to a JspWriter

   Summary: TRAX and Xalan get confused when writing to a JspWriter
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I've got JDK 1.4.1_01-b01 running on Linux RHAS 2.1.

I set up the TRAX API to format some data using an XSLT stylesheet.

I create a javax.xml.transform.stream.StreamResult passing the current JSP 
page's writer as the argument to the constructor. The XSLT sheet say 'encoding 
UTF-8', and the JSP page is a UTF-8 page.

All the the non-latin-1 characters are smashed to ?'s. If I create a 
StringWriter, point trax at that, and then write the resulting string to the 
JspWriter, all is well. This problem occurs with the Xalan that comes with the 
JDK and also with 2.5.1. If I use saxon, it does something more useful but 
still wrong -- it represents all the interesting characters as &#nn; 
sequences. 

I cannot produce any form of this bug with any writer except the JspWriter.

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

DO NOT REPLY [Bug 22563] - Digest authentication failure due to bug in org.apache.catalina.authenticator.DigestAuthenticator

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

Digest authentication failure due to bug in 
org.apache.catalina.authenticator.DigestAuthenticator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|MacOS X |All
   Priority|Other   |High
   Platform|Macintosh   |All



--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 17:03 ---
Changed status.

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

RE: Configuring Tomcat to run cgi scripts

[Shapira, Yoav]

Howdy,
I already responded to this on the tomcat-user list, where this thread
belongs.

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Wilson, Allen [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, September 23, 2003 12:27 PM
>To: Tomcat Developers List
>Subject: Configuring Tomcat to run cgi scripts
>
>Hello...
>
>I am trying to configure Tomcat to run a perl script that is part of an
>application I am moving over from another server. Since this is one
>script I do not want to rewrite it so I thought that I could set the
>server to run CGI scripts.
>
>I have put the entries in the web.xml file and restarted the server but
>I cannot get the script to run. Has anyone had any success in doing
>this?
>
>Allen



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Configuring Tomcat to run cgi scripts

[Wilson, Allen]

Hello...

I am trying to configure Tomcat to run a perl script that is part of an
application I am moving over from another server. Since this is one
script I do not want to rewrite it so I thought that I could set the
server to run CGI scripts.

I have put the entries in the web.xml file and restarted the server but
I cannot get the script to run. Has anyone had any success in doing
this?

Allen
This message may contain proprietary or confidential company information.
Any unauthorized use or disclosure is prohibited.


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

DO NOT REPLY [Bug 23354] New: - HttpServletResponse.encodeURL() does not encode relative URLs beginning with ./ or ../

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

HttpServletResponse.encodeURL() does not encode relative URLs beginning with ./ or ../

   Summary: HttpServletResponse.encodeURL() does not encode relative
URLs beginning with ./ or ../
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Calling encodeURL() on an HttpServletResponse with a partial/relative URL that 
begins with ./ or ../ does not appear to get properly encoded with the 
JSESSIONID suffix if Cookies are disabled.

Examples:
response.encodeURL("../foobar/")
response.encodeURL("./foobar/")

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

Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Jan Luehe]

Petr,

I haven't committed any changes related to the proposal yet, as I was 
waiting for more feedback. The changes I committed in TldConfig.java 
were unrelated.

As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too agree that limiting the number of jars scanned could substantially 
improve first start performance, however I am worried that the solution 
as suggested by Jan will make it too easy for the users to shoot 
themselves to the foot.
Actually, if they don't do anything, things will continue to work, as by 
default the container would continue to scan all globally shared JARs.
If they knew their webapp relied on just jstl.jar, they would configure 
the property with just that name.

Also, unless the user does some manual setup, 
there will be no performance gain,right? So wouldn't it be better to 
have a hardcoded list of well-known jar files that should be excluded 
from scanning? This would include all jars found in the Tomcat 
installation.
OK, I like that idea.

I also think that under no circumstances the jar files in WEB-INF/lib 
should be excluded from scanning, as that is in conflict with the spec.
That was never part of the proposal, the proposal only dealt with 
globally shared JARs, which represent a Tomcat-specific extension to the 
spec.

Thanks,

Jan


Or is there something I am missing about the proposal?

Petr

 

Remy

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


 



This message is intended only for the use of the person(s) listed 
above as the intended recipient(s), and may contain information that 
is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment. 
If you received this communication in error, please notify us 
immediately by e-mail and then delete all copies of this message and 
any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail 
sent through the Internet is not secure. Do not send confidential or 
sensitive information, such as social security numbers, account 
numbers, personal identification numbers and passwords, to us via 
ordinary (unencrypted) e-mail.

 



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


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


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

Re: mod_jk does not detect a hung Tomcat

[Henri Gomez]

David Rees a écrit :
Henri Gomez said:

Henri Gomez a écrit :

Nope since you don't have to just test at protocol level but also on
higher level, for instance check the full chain, up to servlet
handling.

It's easy to simulate this behavior by sending a STOP signal to
Tomcat.
I've also attached a log from mod_jk showing the problem.  I marked
the
point at which processing in mod_jk stopped until I sent a CONT
signal to
tomcat.
Does mod_jk2 have this same problem?  Is there any interest in fixing
this? Does anyone have a workaround for this issue?
Well, if you have a hung tomcat, you're probably allready in serious
trouble.


No, actually in my case I wasn't.  I had two Tomcats running, as one was
prone to locking up due to a JVM or application bug.  With a 50-50 load
distribution between two Tomcats, this left me with 1/2 of the requests
getting stuck and clients waiting forever and tying up Apache processes. 
Eventually, a DOS will be the result if action is not taken in time.  If
mod_jk noticed it wasn't really alive, this wouldn't be an issue at all.


Anyway, if we add stuff like time-out in ajp request, you could be
stuck with long running servlets. Also jk read request in a blocking
mode for performance and adding timeout here is not an option.


Agreed that we wouldn't want a timeout normally to handle normal long
running servlet processes, but if there was a PING/PONG added to the
protocol there should be a timeout to prevent the above situation.

When I worked on ajp13++ (ajp14) protocol, I added a more secure auth
mecanism at connection time.
Since there is a bidirectionnal communication, jk could detect that
even if the connection is open, the remote didn't respond and so fall
back to the next in cluster configuration.
But on allready established connections, the problem persist.

Or we should add a PING/PONG before sending any request to tomcat.

It could be done as optional but I work on it only if many users make
such requirements
if many users ask for such feature ;)


Well, you've got one so far.  ;-)  Adding a configurable option to have
mod_jk verify (PING/PONG) that Tomcat is actually responding before using
the connection would solve the problem and I can't imagine that it would
add a lot of complexity to the code as well.  If I wasn't so rusty with my
C programming and had some spare time, I would offer to help code it up. 
;-)  In any case, I'll be more than happy to help test.
Well, if you could find more users or at least one tomcat commiter
(Glenn, Remy, Costin, JFC...) who need it, I'll add the necessary code
in java and C areas ;)


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

Re: mod_jk does not detect a hung Tomcat

[David Rees]

Henri Gomez said:
> Henri Gomez a écrit :
>>> Nope since you don't have to just test at protocol level but also on
>>> higher level, for instance check the full chain, up to servlet
>>> handling.
>>>
 It's easy to simulate this behavior by sending a STOP signal to
 Tomcat.

 I've also attached a log from mod_jk showing the problem.  I marked
 the
 point at which processing in mod_jk stopped until I sent a CONT
 signal to
 tomcat.

 Does mod_jk2 have this same problem?  Is there any interest in fixing
 this? Does anyone have a workaround for this issue?
>>>
>>> Well, if you have a hung tomcat, you're probably allready in serious
>>> trouble.

No, actually in my case I wasn't.  I had two Tomcats running, as one was
prone to locking up due to a JVM or application bug.  With a 50-50 load
distribution between two Tomcats, this left me with 1/2 of the requests
getting stuck and clients waiting forever and tying up Apache processes. 
Eventually, a DOS will be the result if action is not taken in time.  If
mod_jk noticed it wasn't really alive, this wouldn't be an issue at all.

>>> Anyway, if we add stuff like time-out in ajp request, you could be
>>> stuck with long running servlets. Also jk read request in a blocking
>>> mode for performance and adding timeout here is not an option.

Agreed that we wouldn't want a timeout normally to handle normal long
running servlet processes, but if there was a PING/PONG added to the
protocol there should be a timeout to prevent the above situation.

>> When I worked on ajp13++ (ajp14) protocol, I added a more secure auth
>> mecanism at connection time.
>>
>> Since there is a bidirectionnal communication, jk could detect that
>> even if the connection is open, the remote didn't respond and so fall
>> back to the next in cluster configuration.
>>
>> But on allready established connections, the problem persist.
>>
>> Or we should add a PING/PONG before sending any request to tomcat.
>>
>> It could be done as optional but I work on it only if many users make
>> such requirements
>
> if many users ask for such feature ;)

Well, you've got one so far.  ;-)  Adding a configurable option to have
mod_jk verify (PING/PONG) that Tomcat is actually responding before using
the connection would solve the problem and I can't imagine that it would
add a lot of complexity to the code as well.  If I wasn't so rusty with my
C programming and had some spare time, I would offer to help code it up. 
;-)  In any case, I'll be more than happy to help test.

Thanks,
Dave



-Dave

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

DO NOT REPLY [Bug 23349] New: - Jakarta FAQ-o-matic link is dead.

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

Jakarta FAQ-o-matic link is dead.

   Summary: Jakarta FAQ-o-matic link is dead.
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In introduction.html, Jakarta FAQ-o-matic link is dead.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java ClassLoaderFactory.java

[remm]

remm2003/09/23 06:43:18

  Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java ClassLoaderFactory.java
  Log:
  - Add the possibility to specify straight URLs in the repository list (= single JARs,
remote repositories, etc).
  
  Revision  ChangesPath
  1.12  +6 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Bootstrap.java2 Sep 2003 21:22:00 -   1.11
  +++ Bootstrap.java23 Sep 2003 13:43:18 -  1.12
  @@ -63,6 +63,7 @@
   
   import java.io.File;
   import java.lang.reflect.Method;
  +import java.net.MalformedURLException;
   import java.net.URL;
   import java.util.ArrayList;
   import java.util.StringTokenizer;
  @@ -92,7 +93,6 @@
   
   protected static final String CATALINA_HOME_TOKEN = "${catalina.home}";
   protected static final String CATALINA_BASE_TOKEN = "${catalina.base}";
  -protected static final String HTTP_TOKEN = "http://";;
   
   
   // --- Static Variables
  @@ -154,10 +154,12 @@
   StringTokenizer tokenizer = new StringTokenizer(value, ",");
   while (tokenizer.hasMoreElements()) {
   String repository = tokenizer.nextToken();
  -// Check for a remote repository
  -if (repository.startsWith(HTTP_TOKEN)) {
  +// Check for a JAR URL repository
  +try {
   urlList.add(new URL(repository));
   continue;
  +} catch (MalformedURLException e) {
  +// Ignore
   }
   // Local repository
   boolean packed = false;
  
  
  
  1.5   +5 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java
  
  Index: ClassLoaderFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ClassLoaderFactory.java   2 Sep 2003 21:22:00 -   1.4
  +++ ClassLoaderFactory.java   23 Sep 2003 13:43:18 -  1.5
  @@ -222,7 +222,7 @@
   }
   }
   
  -// Add remote URLs
  +// Add URLs
   if (urls != null) {
   for (int i = 0; i < urls.length; i++) {
   list.add(urls[i].toString());
  
  
  

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

RE: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Shapira, Yoav]

Howdy,
I'm -0 leaning towards -1 unless a significant performance benefit is
demonstrated... If this is an optimization that has some effect only the
first time tomcat is started (because then the TLD scan result file is
serialized), then I don't think your patch should be added... ;)

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Jan Luehe [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 22, 2003 5:34 PM
>To: Shapira, Yoav
>Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for
TLDs
>
>Hi Shapira,
>
>so are you giving this proposal a +1, or do you abstain? :)
>
>Thanks,
>
>Jan
>
>Shapira, Yoav wrote:
>> Howdy,
>>
>>
>>>What do you mean by "too much work"? :)
>>>I already have a patch ready to be committed. It's just a few line
>>
>> changes.
>>
>> I mean two things:
>> 1 - the work you've done, implementing the patch;
>> 2 - the work to debug/trace user questions about why their TLDs
aren't
>> loading when they should or vice versa.
>>
>> As long as it's well documented, I never have a problem with a
>> performance enhancement ;)
>>
>> Yoav Shapira
>>
>>
>>
>> This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

DO NOT REPLY [Bug 10912] - org.apache.catalina.INVOKER.process.queue_server is currently unavailable

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

org.apache.catalina.INVOKER.process.queue_server is currently unavailable





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 12:10 ---
This is a follow-up of my previous comment.

I have just downloaded Tomcat 4.1.24 and installed it.
I am able to reload servlets without a problem in it.

The problem only seems to be with 4.1.27.

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

\<% not handled right?

[Tim Funk]

Attached is a note from tomcat-user which I think might be a bug in jasper.

Summary it you don't want to read it...
Take this page:
-
<%="BAR"%>
\<%="bar"%>
-
It produces:
BAR
\<%="bar"%>
Instead of
BAR
\bar
The spec says to escape <% with <\%

-Tim

 Original Message 
Subject: JSP Compilation Problem
Date: Tue, 23 Sep 2003 13:23:30 +0300
From: Anatol Pomazau <[EMAIL PROTECTED]>
Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Hi.

I just upgrade tomcat server from 4.1.12 to Tomcat-dev (I get sources
from CVS and compile it yesterday)
But I have a problem with one jsp.
So, such code
<% String fullname = "Anatol Pomazau"; %>
<%=fulln
ame%>
Works fine in old version but in new Tomcat generates
Anatol
Pomazau
Insead of
Anatol
Pomazau
I have looked JSP Spec 2.0 and I have not found any remarks about such
quoting.
What I do wrong? Please help me.


EPAM Systems, Minsk, Belarus
work: +375 17 210 1662, ext. #1373
icq uin: 138182429


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




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

DO NOT REPLY [Bug 23344] - catalina.properties don't allow to add one jar file

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

catalina.properties don't allow to add one jar file





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 10:36 ---
This sounds reasonable. Can you submit a tested fix ?

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

Re: mod_jk does not detect a hung Tomcat

[Henri Gomez]

Henri Gomez a écrit :

Nope since you don't have to just test at protocol level but also on 
higher level, for instance check the full chain, up to servlet handling.

It's easy to simulate this behavior by sending a STOP signal to Tomcat.

I've also attached a log from mod_jk showing the problem.  I marked the
point at which processing in mod_jk stopped until I sent a CONT 
signal to
tomcat.

Does mod_jk2 have this same problem?  Is there any interest in fixing
this? Does anyone have a workaround for this issue?


Well, if you have a hung tomcat, you're probably allready in serious 
trouble.

Anyway, if we add stuff like time-out in ajp request, you could be 
stuck with long running servlets. Also jk read request in a blocking 
mode for performance and adding timeout here is not an option.


When I worked on ajp13++ (ajp14) protocol, I added a more secure auth 
mecanism at connection time.

Since there is a bidirectionnal communication, jk could detect that
even if the connection is open, the remote didn't respond and so fall
back to the next in cluster configuration.
But on allready established connections, the problem persist.

Or we should add a PING/PONG before sending any request to tomcat.

It could be done as optional but I work on it only if many users make
such requirements
if many users ask for such feature ;)

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

Re: mod_jk does not detect a hung Tomcat

[Henri Gomez]

Nope since you don't have to just test at protocol level but also on 
higher level, for instance check the full chain, up to servlet handling.

It's easy to simulate this behavior by sending a STOP signal to Tomcat.

I've also attached a log from mod_jk showing the problem.  I marked the
point at which processing in mod_jk stopped until I sent a CONT signal to
tomcat.
Does mod_jk2 have this same problem?  Is there any interest in fixing
this? Does anyone have a workaround for this issue?


Well, if you have a hung tomcat, you're probably allready in serious 
trouble.

Anyway, if we add stuff like time-out in ajp request, you could be stuck 
with long running servlets. Also jk read request in a blocking mode for 
performance and adding timeout here is not an option.


When I worked on ajp13++ (ajp14) protocol, I added a more secure auth 
mecanism at connection time.

Since there is a bidirectionnal communication, jk could detect that
even if the connection is open, the remote didn't respond and so fall
back to the next in cluster configuration.
But on allready established connections, the problem persist.

Or we should add a PING/PONG before sending any request to tomcat.

It could be done as optional but I work on it only if many users make
such requirements
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk does not detect a hung Tomcat

[Henri Gomez]

David Rees a écrit :

I posted this to tomcat-users last week, but didn't get a reply...  I'm
hoping to get some feedback from the connectors developers on this issue I
occasionally run into...
I've got a setup where I've got two load balanced Tomcats running off of
Apache and mod_jk.
I've got a problem where one of the Tomcats will occasionally hang, but
not die.  This means that it will accept new connections, but will not
actually process anything.  This renders all clients using the hung Tomcat
completely stuck as they are not switched over to the other Tomcat.
mod_jk seems to assume that if it can connect to Tomcat, it must be ready
to respond to requests.
Yes, if jk can connect to tomcat it assume it could handle the requests.

It seems that some sort of connection test (with a short socket timeout)
would be appropriate to validate that the connection is actually
responding.  While this would increase the latency of each request a bit,
it would improve the reliability.  Is there any provision in the AJP13
protocol to allow for testing of connections before sending a request over
it?
Nope since you don't have to just test at protocol level but also on 
higher level, for instance check the full chain, up to servlet handling.

It's easy to simulate this behavior by sending a STOP signal to Tomcat.

I've also attached a log from mod_jk showing the problem.  I marked the
point at which processing in mod_jk stopped until I sent a CONT signal to
tomcat.
Does mod_jk2 have this same problem?  Is there any interest in fixing
this? Does anyone have a workaround for this issue?
Well, if you have a hung tomcat, you're probably allready in serious 
trouble.

Anyway, if we add stuff like time-out in ajp request, you could be stuck 
with long running servlets. Also jk read request in a blocking mode for 
performance and adding timeout here is not an option.



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

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

[remm]

remm2003/09/23 02:07:37

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Don't save anything if config base doesn't exist.
  
  Revision  ChangesPath
  1.95  +4 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.94
  retrieving revision 1.95
  diff -u -r1.94 -r1.95
  --- StandardContext.java  22 Sep 2003 19:32:04 -  1.94
  +++ StandardContext.java  23 Sep 2003 09:07:37 -  1.95
  @@ -4631,6 +4631,9 @@
   private File getConfigBase() {
   File configBase = 
   new File(System.getProperty("catalina.base"), "conf");
  +if (!configBase.exists()) {
  +return null;
  +}
   Container container = this;
   Container host = null;
   Container engine = null;
  
  
  

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

Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Remy Maucherat]

Petr Jiricka wrote:
Remy Maucherat wrote:

Yes, there is.
There's a serialization file which is used to avoid rescanning, unless 
a JAR is modified. 
That's true, but that does not help on the very first start, only on 
subsequent restarts. So I see that this proposal will not represent any 
performance improvement on second and subsequent starts. I still think 
we should look for a way to improve the first start time.
Thanks for confirming what I was suspecting. I strongly disagree with 
that kind of optimizations unless it has zero useability impact. Since 
it can cause usert errors, I am changing my vote to a -1.

I think this is good enough, and hence my -0 (I'm leaning towards -1 
now, as this could indeed be misused; I'd like to see some performance 
improvement before changing my vote). 
What I don't like about Jan's proposal is the need for user 
configuration. But what's wrong with having a list of well known jar 
files and skipping those?
OTOH, I'm ok with adding a list of JARs known not to have a TLD.

Remy



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

Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Petr Jiricka]

Remy Maucherat wrote:

Petr Jiricka wrote:

Has it? I saw some commits in the area of jar scanning, but not this 
one.


That hasn't been committed yet, indeed.

As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too agree that limiting the number of jars scanned could 
substantially improve first start performance, however I am worried 
that the solution as suggested by Jan will make it too easy for the 
users to shoot themselves to the foot. Also, unless the user does 
some manual setup, there will be no performance gain,right? So 
wouldn't it be better to have a hardcoded list of well-known jar 
files that should be excluded from scanning? This would include all 
jars found in the Tomcat installation.

I also think that under no circumstances the jar files in WEB-INF/lib 
should be excluded from scanning, as that is in conflict with the spec.

Or is there something I am missing about the proposal?


Yes, there is.
There's a serialization file which is used to avoid rescanning, unless 
a JAR is modified. 
That's true, but that does not help on the very first start, only on 
subsequent restarts. So I see that this proposal will not represent any 
performance improvement on second and subsequent starts. I still think 
we should look for a way to improve the first start time.



I think this is good enough, and hence my -0 (I'm leaning towards -1 
now, as this could indeed be misused; I'd like to see some performance 
improvement before changing my vote). 


What I don't like about Jan's proposal is the need for user 
configuration. But what's wrong with having a list of well known jar 
files and skipping those?

Petr



Remy



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


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

DO NOT REPLY [Bug 23344] New: - catalina.properties don't allow to add one jar file

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

catalina.properties don't allow to add one jar file

   Summary: catalina.properties don't allow to add one jar file
   Product: Tomcat 5
   Version: 5.0.12
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My directory "/X" contains 4 jar files:
- /X/jdbcOracle.jar
- /X/jdbcMySQL.jar
- /X/Xerces.jar
- /X/Xalan.jar

I updated shared.loader in catalina.properties (or common.loader, it's the same)
value to see jdbc driver:

- shared.loader=...default...,/X/jdbcOracle.jar,/X/jdbcMySQL.jar
  => ClassNotFoundException: oracle.jdbc.driver.OracleDriver

- shared.loader=...default...,/X/*.jar
  => OK!

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

Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Remy Maucherat]

Petr Jiricka wrote:
Has it? I saw some commits in the area of jar scanning, but not this one.
That hasn't been committed yet, indeed.

As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too agree that limiting the number of jars scanned could substantially 
improve first start performance, however I am worried that the solution 
as suggested by Jan will make it too easy for the users to shoot 
themselves to the foot. Also, unless the user does some manual setup, 
there will be no performance gain,right? So wouldn't it be better to 
have a hardcoded list of well-known jar files that should be excluded 
from scanning? This would include all jars found in the Tomcat 
installation.

I also think that under no circumstances the jar files in WEB-INF/lib 
should be excluded from scanning, as that is in conflict with the spec.

Or is there something I am missing about the proposal?
Yes, there is.
There's a serialization file which is used to avoid rescanning, unless a 
JAR is modified.

I think this is good enough, and hence my -0 (I'm leaning towards -1 
now, as this could indeed be misused; I'd like to see some performance 
improvement before changing my vote).

Remy



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

Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

[Petr Jiricka]

Bill Barker wrote:

- Original Message - 
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 10:31 PM
Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

 

Jan Luehe wrote:
   

Currently, any JARs in the classloader delegation chain of a webapp's
classloader are scanned for packaged TLDs. This is convenient, as it
allows a JAR-packaged taglib to be simply dropped in common/lib and
shared by all webapps, rather than requiring each webapp to bundle the
taglib in its own WEB-INF/lib.
However, scanning all available JARs for TLDs is not very efficient,
especially if the names of the JAR-packaged taglibs are known in
advance.
The proposal is to add a configurable String property ("tldJarNames")
on Context, which specifies the comma-separated list of JAR file names
(without any path info) that must be scanned for TLDs.
Catalina will continue to traverse the classloader delegation chain,
but only consider those JARs that match the names in the
comma-separated list.
If a JAR appears more than once in the classloader delegation chain,
we will pick its first occurrence.
If the "tldJarNames" property is not set, Catalina will continue to scan
all JARs in the classloader delegation chain for TLDs.
Comments?
 

Same as Yoav. -0. much pain, no gain.
   

Seeing as how it's already been committed, +0.

Has it? I saw some commits in the area of jar scanning, but not this one.

As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too agree that limiting the number of jars scanned could substantially 
improve first start performance, however I am worried that the solution 
as suggested by Jan will make it too easy for the users to shoot 
themselves to the foot. Also, unless the user does some manual setup, 
there will be no performance gain,right? So wouldn't it be better to 
have a hardcoded list of well-known jar files that should be excluded 
from scanning? This would include all jars found in the Tomcat installation.

I also think that under no circumstances the jar files in WEB-INF/lib 
should be excluded from scanning, as that is in conflict with the spec.

Or is there something I am missing about the proposal?

Petr

 

Remy

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

 



This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.

 



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


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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[remm]

remm2003/09/23 00:09:55

  Modified:util/java/org/apache/tomcat/util/net Tag: coyote_10
PoolTcpEndpoint.java
  Log:
  - Port patch.
  - Don't catch SocketException when setting the socket options, so that when
it happens the socket is discarded right away. The exception will also be
properly logged.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.12.2.3  +10 -14
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.12.2.2
  retrieving revision 1.12.2.3
  diff -u -r1.12.2.2 -r1.12.2.3
  --- PoolTcpEndpoint.java  13 Sep 2003 04:01:24 -  1.12.2.2
  +++ PoolTcpEndpoint.java  23 Sep 2003 07:09:54 -  1.12.2.3
  @@ -460,17 +460,13 @@
   }
   
   void setSocketOptions(Socket socket)
  -{
  - try {
  - if(linger >= 0 ) 
  - socket.setSoLinger( true, linger);
  - if( tcpNoDelay )
  - socket.setTcpNoDelay(tcpNoDelay);
  - if( socketTimeout > 0 )
  - socket.setSoTimeout( socketTimeout );
  - } catch(  SocketException se ) {
  - se.printStackTrace();
  - }
  +throws SocketException {
  +if(linger >= 0 ) 
  +socket.setSoLinger( true, linger);
  +if( tcpNoDelay )
  +socket.setTcpNoDelay(tcpNoDelay);
  +if( socketTimeout > 0 )
  +socket.setSoTimeout( socketTimeout );
   }
   
   }
  
  
  

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

DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect

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

Calling socket.setTcpNoDelay causes connector to disconnect





--- Additional Comments From [EMAIL PROTECTED]  2003-09-23 07:06 ---
Previously, the socket was not thrown away right away, but passed along for
normal processing. It's sort of unpredictable what happened after that, so I
think I will port the change to Tomcat 4.1.x.

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