DO NOT REPLY [Bug 14515] - Documents are transmitted twice when calling via POST from external source

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

Documents are transmitted twice when calling via POST from external source





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 07:58 ---
There is no way Coyote HTTP/1.1 can be made to generate two responses to only
one HTTP request. I encourage you to investigate further, as this is too complex
to reproduce, and I will not have time to look into it.

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

DO NOT REPLY [Bug 14537] New: - PATCH: Fix for NPE with JSPC and tag library references

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

PATCH: Fix for NPE with JSPC and tag library references

   Summary: PATCH: Fix for NPE with JSPC and tag library references
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


This patch fixes a NullPointerException error with JSPC compiling JSP files 
with tag library references.

Regards,
Petteri Stenius

--- 
C:\Projects\jasper\src\share\org\apache\jasper\compiler\TagLibraryInfoImpl.java
.bakMon Sep 23 10:23:16 2002
+++ 
C:\Projects\jasper\src\share\org\apache\jasper\compiler\TagLibraryInfoImpl.java
Thu Nov 14 08:48:06 2002
@@ -189,10 +189,6 @@
InputStream stream = null;
try {
 String path = location[0] ;
-if(ctxt.getClassLoader() != null &&
-   URLClassLoader.class.equals(ctxt.getClassLoader().getClass
())
-   && path.startsWith("/"))
-   path = path.substring(1,path.length()) ;
 url = ctxt.getResource(path);
 if (url == null) return;
url = new URL("jar:" + url.toString() + "!/");
@@ -211,7 +207,7 @@
} catch (Exception ex) {
Constants.message(
 "jsp.error.taglib.jarFileException",
-   new Object[] {url.toString(), ex.getMessage()},
+   new Object[] {path, ex.getMessage()},
Logger.ERROR);
if (stream != null) {
try {

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

RE: JK2 unixsocket: Can't create apr

[Costin Manolache]

A quick test: put commons-logging.jar and log4j.jar in common/lib.

Most classloader problems are due to the loader hierarchy. 

It is possible ( at least with 5.0 - I'm running it this way ) to
put all the jars in the same place ( like common/lib or just in CLASSPATH)
and run tomcat with delegation and a simple class loader hierarchy.

I would bet the same works with 4.1.x - jboss for example is using
embeded tocmat with all the jars in the main loader.

Regarding the unix channel - you need to be able to load libjkjni.so 
and libapr.so. It may be a good idea ( at least for testing ) to place
them in the JRE_HOME/lib dir - that's a place where java will certainly
look for .so files. ( at least with JDK1.4 I had some problems with loading
jars, and the LD_LIBRARY_PATH may create some problems ).

Costin



Brzezinski, Paul J wrote:

> Original post came from Tomcat Users, replying/cross-posting...
> 
> 
> 
> : -Original Message-
> : From: Costin Manolache [mailto:cmanolache@;yahoo.com]
> : Sent: Wednesday, November 13, 2002 3:16 PM
> : To: Tomcat Developers List
> : Subject: RE: JK2 unixsocket: Can't create apr
> : 
> : 
> : Very weird.
> : 
> : Are you using the latest commons-logging.jar ? JDK1.4 or 1.3
> : ? Do you have log4j ?
> 
> Yes -- *I* get this error on 4.1.12/5.0 on Solaris 8, hopefully Robert
> Williams can provide details about his specfic config:
> 
> 
> I have:
> 
> j2sdk1.4.1
> commons-logging-1.0.2
> jakarta-log4j-1.2.6
> 
> Tried this against:
> jakarta-tomcat-4.1.12
> jakarta-tomcat-4.1.12-LE-jdk14
> jakarta-tomcat-5
> 
> I get the same error -- can't create apr...
> 
> java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>  at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
> 
> : The problem seems releated to class loading ( as usual :-).
> 
> Yeah, but how do we work-around it or solve it permanently.  I've tried
> massaging the catalina.sh startup script to include commons-logging.jar in
> CLASSPATH that gets passed to the JVM at startup.
> 
> I've put commons-logging.jar in $CATALINA_HOME/server/lib even though
> commons-logging-api.jar exists there.
> 
> I see in the -LE-jdk14 that there's a log4j.rename-to-jar.  What's the
> confidence level that this will resolve this problem?
> 
> Is this a problem on other platforms?
> 
> Is this NOT a problem on Linux?
> 
> : Costin
> : 
> : 
> : Brzezinski, Paul J wrote:
> : 
> : > I wonder if a better question is:
> : > 
> : > Is anyone using the ChannelUnix (AF_UNIX socket) connector on any
> : > platform?
> : > 
> : > On what platforms is the ChannelUnix (AF_UNIX socket) connector
> : > actually known to function?
> : > 
> : > 
> : > 
> : > : -Original Message-
> : > : From: Robert Williams [mailto:rcw1@;pacbell.net]
> : > : Sent: Wednesday, November 13, 2002 1:05 PM
> : > : To: Tomcat User
> : > : Subject: JK2 unixsocket: Can't create apr
> : > :
> : > : 
> : > : Hi all,
> : > : I am trying to implement the unixsocket on JK2. While the
> : > : channelSocket
> : > : works fine I was hoping to get the speed benefits of a
> : > : unixsocket. I am
> : > : using the example setups in the JK2 documentation. And since
> : > : it seems to
> : > : be looking for  the LogFactory I have made sure that
> : > : commons-logging-api.jar  was in the Tomcat common/lib and I
> : > : also put it
> : > : in java/jre/lib/ext as well. All to no avail. I am
> : stumped. I haven't
> : > : been able to find anything in the list or on google
> : addressing this
> : > : problem. Some docs regarding channelSocket say disable
> : apr for this
> : > : error but apparently unixsocket won't work without apr
> : > : enabled. Any help
> : > : would be appreciated.
> : > : Thanks Robert
> : > : 
> : > : jakarta-tomcat-4.1.12
> : > : jakarta-tomcat-connectors-4.1.12
> : > : Apache/2.0.43
> : > : Solaris 9
> : > : 
> : > : Nov 13, 2002 9:29:04 AM org.apache.jk.server.JkMain newHandler
> : > : SEVERE: Can't create apr
> : > : java.lang.NoClassDefFoundError:
> : org/apache/commons/logging/LogFactory
> : > : at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
> : > : at java.lang.Class.forName0(Native Method)
> : > : at java.lang.Class.forName(Class.java:130)
> : > : at org.apache.jk.server.JkMain.newHandler(JkMain.java:494)
> : > : at org.apache.jk.server.JkMain.start(JkMain.java:316)
> : > : at
> : > : org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.jav
> : > : 
> : > : workers2.properties
> : > : 
> : > : [shm]
> : > : file=${serverRoot}/logs/shm.file
> : > : size=1048576
> : > : 
> : > : # Example unixsocket channel.
> : > : [channel.un:unixsocket]
> : > : file=/usr/local/tomcat/work/jk2.socket
> : > : 
> : > : # define the worker
> : > : [ajp13:unixsocket]
> : > : channel=channel.un:unixsocket
> : > : 
> : > : # Uri mapping
> : > : [uri:/examples/*]
> : > : worker=ajp13:unixsocket
> : > : 
> : > : jk2.properties
> : > : # list of needed handlers.
> : > : handler.list=apr,channelUn

DO NOT REPLY [Bug 14530] New: - wrong parsing of web.xml

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

wrong parsing of web.xml

   Summary: wrong parsing of web.xml
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I had an error in my web.xml of a webapp:
after several ... entries, I had the
... entry followed by a
...

this was parsed correctly, allthough according to the web_app_2_3.dtd it is not
and jasper only complained after I hadded a ... entry in the
correct page.

As you can see the error message is not too correct :( and it took me quite some
time to find the error in the dtd

Error message from the log was:
2002-11-13 22:31:43 Exception initializing TldLocationsCache: XML parsing error
on file /WEB-INF/web.xml: (line 39, col -1): Element "web-app" does not allow
"context-param" here.
2002-11-13 22:31:43 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp
threw exception
org.apache.jasper.JasperException: null(-1,-1) This absolute uri
(http://jakarta.apache.org/taglibs/mailer-1.0) cannot be resolved in either
web.xml or the jar files deployed with this application
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:417)
at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:154)
at
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:159)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:354)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:381)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:799)
at org.apache.jasper.compiler.Parser.parse(Parser.java:122)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:199)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:153)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:219)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(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.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(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.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineV

DO NOT REPLY [Bug 14526] - not supported in standard syntax

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

 not supported in standard syntax

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 14526] New: - not supported in standard syntax

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

 not supported in standard syntax

   Summary:  not supported in standard syntax
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


 currently is supported in XML syntax only. According to the spec,
which has been clarified in this respect, it also must be supported in standard
syntax.

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

RE: JK2 unixsocket: Can't create apr

[Brzezinski, Paul J]

: -Original Message-
: From: Costin Manolache [mailto:cmanolache@;yahoo.com] 
: Sent: Wednesday, November 13, 2002 3:16 PM
: To: Tomcat Developers List
: Subject: RE: JK2 unixsocket: Can't create apr
: 
: 
: Very weird. 
: 
: Are you using the latest commons-logging.jar ? JDK1.4 or 1.3 
: ? Do you have log4j ?

Do I need a .properties file or .xml file log4j or Apr?

With log4j in $CATALINA_HOME/server/lib:

This is the $CATALINA_HOME/logs/catalina.out:

Exception during startup processing
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout
at
org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory
.java:153)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory
Impl.java:281)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:400)
at org.apache.commons.digester.Digester.(Digester.java:345)
at org.apache.catalina.startup.Catalina.createStartDigester(Unknown
Sour
ce)
at org.apache.catalina.startup.Catalina.start(Unknown Source)
at org.apache.catalina.startup.Catalina.execute(Unknown Source)
at org.apache.catalina.startup.Catalina.process(Unknown Source)
... 5 more

: The problem seems releated to class loading ( as usual :-).
: 
: Costin
: 
: 
: Brzezinski, Paul J wrote:
: 
: > I wonder if a better question is:
: > 
: > Is anyone using the ChannelUnix (AF_UNIX socket) connector on any 
: > platform?
: > 
: > On what platforms is the ChannelUnix (AF_UNIX socket) connector 
: > actually known to function?
: > 
: > 
: > 
: > : -Original Message-
: > : From: Robert Williams [mailto:rcw1@;pacbell.net]
: > : Sent: Wednesday, November 13, 2002 1:05 PM
: > : To: Tomcat User
: > : Subject: JK2 unixsocket: Can't create apr
: > :
: > : 
: > : Hi all,
: > : I am trying to implement the unixsocket on JK2. While the
: > : channelSocket
: > : works fine I was hoping to get the speed benefits of a
: > : unixsocket. I am
: > : using the example setups in the JK2 documentation. And since
: > : it seems to
: > : be looking for  the LogFactory I have made sure that
: > : commons-logging-api.jar  was in the Tomcat common/lib and I
: > : also put it
: > : in java/jre/lib/ext as well. All to no avail. I am 
: stumped. I haven't
: > : been able to find anything in the list or on google 
: addressing this
: > : problem. Some docs regarding channelSocket say disable 
: apr for this
: > : error but apparently unixsocket won't work without apr
: > : enabled. Any help
: > : would be appreciated.
: > : Thanks Robert
: > : 
: > : jakarta-tomcat-4.1.12
: > : jakarta-tomcat-connectors-4.1.12
: > : Apache/2.0.43
: > : Solaris 9
: > : 
: > : Nov 13, 2002 9:29:04 AM org.apache.jk.server.JkMain newHandler
: > : SEVERE: Can't create apr
: > : java.lang.NoClassDefFoundError: 
: org/apache/commons/logging/LogFactory
: > : at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
: > : at java.lang.Class.forName0(Native Method)
: > : at java.lang.Class.forName(Class.java:130)
: > : at org.apache.jk.server.JkMain.newHandler(JkMain.java:494)
: > : at org.apache.jk.server.JkMain.start(JkMain.java:316)
: > : at
: > : org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.jav
: > : 
: > : workers2.properties
: > : 
: > : [shm]
: > : file=${serverRoot}/logs/shm.file
: > : size=1048576
: > : 
: > : # Example unixsocket channel.
: > : [channel.un:unixsocket]
: > : file=/usr/local/tomcat/work/jk2.socket
: > : 
: > : # define the worker
: > : [ajp13:unixsocket]
: > : channel=channel.un:unixsocket
: > : 
: > : # Uri mapping
: > : [uri:/examples/*]
: > : worker=ajp13:unixsocket
: > : 
: > : jk2.properties
: > : # list of needed handlers.
: > : handler.list=apr,channelUnix,request
: > : 
: > : # Location of the socket.
: > : channelUnix.file=${jkHome}/work/jk2.socket
: > : 
: > : # Dynamic library
: > : apr.NativeSo=${jkHome}/lib/jkjni.so
: > : 
: > : jk2.properties.save
: > : #AUTOMATICALLY GENERATED
: > : #Wed Nov 13 09:38:33 PST 2002
: > : handler.list=apr,channelUnix,request
: > : secure=false
: > : soTimeout=2
: > : port=8009
: > : jkHome=/usr/local/jakarta-tomcat-4.1.12
: > : maxThreads=75
: > : backlog=10
: > : apr.NativeSo=${jkHome}/lib/jkjni.so
: > : timeout=2
: > : channelUnix.file=${jkHome}/work/jk2.socket
: > : tcpNoDelay=true
: > : 
: > : 
: > : Build Apache
: > : ./configure --with-mpm=worker --enable-so --enable-layout=Apache
: > : --enable-module=most --enable-mods-shared=most
: > : make
: > : make install
: > : 
: > : Bu

RE: JK2 unixsocket: Can't create apr

[Brzezinski, Paul J]

Original post came from Tomcat Users, replying/cross-posting...



: -Original Message-
: From: Costin Manolache [mailto:cmanolache@;yahoo.com] 
: Sent: Wednesday, November 13, 2002 3:16 PM
: To: Tomcat Developers List
: Subject: RE: JK2 unixsocket: Can't create apr
: 
: 
: Very weird. 
: 
: Are you using the latest commons-logging.jar ? JDK1.4 or 1.3 
: ? Do you have log4j ?

Yes -- *I* get this error on 4.1.12/5.0 on Solaris 8, hopefully Robert
Williams can provide details about his specfic config:


I have:

j2sdk1.4.1
commons-logging-1.0.2
jakarta-log4j-1.2.6

Tried this against:
jakarta-tomcat-4.1.12
jakarta-tomcat-4.1.12-LE-jdk14
jakarta-tomcat-5

I get the same error -- can't create apr...

java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
 at org.apache.jk.apr.AprImpl.(AprImpl.java:340)

: The problem seems releated to class loading ( as usual :-).

Yeah, but how do we work-around it or solve it permanently.  I've tried
massaging the catalina.sh startup script to include commons-logging.jar in
CLASSPATH that gets passed to the JVM at startup.

I've put commons-logging.jar in $CATALINA_HOME/server/lib even though
commons-logging-api.jar exists there.

I see in the -LE-jdk14 that there's a log4j.rename-to-jar.  What's the
confidence level that this will resolve this problem?

Is this a problem on other platforms?

Is this NOT a problem on Linux?

: Costin
: 
: 
: Brzezinski, Paul J wrote:
: 
: > I wonder if a better question is:
: > 
: > Is anyone using the ChannelUnix (AF_UNIX socket) connector on any 
: > platform?
: > 
: > On what platforms is the ChannelUnix (AF_UNIX socket) connector 
: > actually known to function?
: > 
: > 
: > 
: > : -Original Message-
: > : From: Robert Williams [mailto:rcw1@;pacbell.net]
: > : Sent: Wednesday, November 13, 2002 1:05 PM
: > : To: Tomcat User
: > : Subject: JK2 unixsocket: Can't create apr
: > :
: > : 
: > : Hi all,
: > : I am trying to implement the unixsocket on JK2. While the
: > : channelSocket
: > : works fine I was hoping to get the speed benefits of a
: > : unixsocket. I am
: > : using the example setups in the JK2 documentation. And since
: > : it seems to
: > : be looking for  the LogFactory I have made sure that
: > : commons-logging-api.jar  was in the Tomcat common/lib and I
: > : also put it
: > : in java/jre/lib/ext as well. All to no avail. I am 
: stumped. I haven't
: > : been able to find anything in the list or on google 
: addressing this
: > : problem. Some docs regarding channelSocket say disable 
: apr for this
: > : error but apparently unixsocket won't work without apr
: > : enabled. Any help
: > : would be appreciated.
: > : Thanks Robert
: > : 
: > : jakarta-tomcat-4.1.12
: > : jakarta-tomcat-connectors-4.1.12
: > : Apache/2.0.43
: > : Solaris 9
: > : 
: > : Nov 13, 2002 9:29:04 AM org.apache.jk.server.JkMain newHandler
: > : SEVERE: Can't create apr
: > : java.lang.NoClassDefFoundError: 
: org/apache/commons/logging/LogFactory
: > : at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
: > : at java.lang.Class.forName0(Native Method)
: > : at java.lang.Class.forName(Class.java:130)
: > : at org.apache.jk.server.JkMain.newHandler(JkMain.java:494)
: > : at org.apache.jk.server.JkMain.start(JkMain.java:316)
: > : at
: > : org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.jav
: > : 
: > : workers2.properties
: > : 
: > : [shm]
: > : file=${serverRoot}/logs/shm.file
: > : size=1048576
: > : 
: > : # Example unixsocket channel.
: > : [channel.un:unixsocket]
: > : file=/usr/local/tomcat/work/jk2.socket
: > : 
: > : # define the worker
: > : [ajp13:unixsocket]
: > : channel=channel.un:unixsocket
: > : 
: > : # Uri mapping
: > : [uri:/examples/*]
: > : worker=ajp13:unixsocket
: > : 
: > : jk2.properties
: > : # list of needed handlers.
: > : handler.list=apr,channelUnix,request
: > : 
: > : # Location of the socket.
: > : channelUnix.file=${jkHome}/work/jk2.socket
: > : 
: > : # Dynamic library
: > : apr.NativeSo=${jkHome}/lib/jkjni.so
: > : 
: > : jk2.properties.save
: > : #AUTOMATICALLY GENERATED
: > : #Wed Nov 13 09:38:33 PST 2002
: > : handler.list=apr,channelUnix,request
: > : secure=false
: > : soTimeout=2
: > : port=8009
: > : jkHome=/usr/local/jakarta-tomcat-4.1.12
: > : maxThreads=75
: > : backlog=10
: > : apr.NativeSo=${jkHome}/lib/jkjni.so
: > : timeout=2
: > : channelUnix.file=${jkHome}/work/jk2.socket
: > : tcpNoDelay=true
: > : 
: > : 
: > : Build Apache
: > : ./configure --with-mpm=worker --enable-so --enable-layout=Apache
: > : --enable-module=most --enable-mods-shared=most
: > : make
: > : make install
: > : 
: > : Build jk2 Conector
: > : cd ${conector.home}/jk/native2
: > : sh ./buildconf.sh
: > : 
: > : cp  /usr/java/include/solaris to /usr/java/include/
: > : 
: > : CPPFLAGS=-DBSD_COMP  ./configure \
: > : --with-apxs2=/usr/local/apache2/bin/apxs \
: > : --with-tomcat41=/usr/local/tomcat \
: > : --with-java-home=${JAVA_

Re: JSPC refactoring/documentation

[Fredrik Westermarck]

Costin Manolache wrote:


The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.

You have to keep pushing.


Well I did, but the next person might not. In that case the community as 
a whole may miss important features or ideas.

> If you send patches and proposals you can
become a committer - and then you'll start ignoring patches and proposals  
:-)

If I was a committer I wouldn't feel good about ignoring patches and 
proposals. By the way isn't ignoring patches/proposals the opposite of 
what a committer is supposed to do?

I'm sorry - but everyone is very short on time.


Yes, I do know that and respect that.


Is there any concrete feature that you need in 4.1 but is not implemented ?


Not anymore. :)


What's important ( IMO ) is that at the moment it seems more people are
actively working on 5.0, so its easier to get things changed there. 
4.1 is stable - and it's normal to be a high resistence to bigger changes.

I didn't know that Tomcat 4 (as it seems now) wasn't to be actively 
maintained and improved. I thought Tomcat 5 goal was to improve Tomcat 4 
and implement the new Servlet- and JSP-specs.

Maybe the community has to be told that 4.1 is in 'high resistence'-mode 
so that ppl know that they should test their apps with 5.0 if they want 
or is waiting for new features that have been proposed.


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

RE: JK2 unixsocket: Can't create apr

[Costin Manolache]

Very weird. 

Are you using the latest commons-logging.jar ? JDK1.4 or 1.3 ? Do you have
log4j ?

The problem seems releated to class loading ( as usual :-).

Costin


Brzezinski, Paul J wrote:

> I wonder if a better question is:
> 
> Is anyone using the ChannelUnix (AF_UNIX socket) connector on any
> platform?
> 
> On what platforms is the ChannelUnix (AF_UNIX socket) connector actually
> known to function?
> 
> 
> 
> : -Original Message-
> : From: Robert Williams [mailto:rcw1@;pacbell.net]
> : Sent: Wednesday, November 13, 2002 1:05 PM
> : To: Tomcat User
> : Subject: JK2 unixsocket: Can't create apr
> : 
> : 
> : Hi all,
> : I am trying to implement the unixsocket on JK2. While the
> : channelSocket
> : works fine I was hoping to get the speed benefits of a
> : unixsocket. I am
> : using the example setups in the JK2 documentation. And since
> : it seems to
> : be looking for  the LogFactory I have made sure that
> : commons-logging-api.jar  was in the Tomcat common/lib and I
> : also put it
> : in java/jre/lib/ext as well. All to no avail. I am stumped. I haven't
> : been able to find anything in the list or on google addressing this
> : problem. Some docs regarding channelSocket say disable apr for this
> : error but apparently unixsocket won't work without apr
> : enabled. Any help
> : would be appreciated.
> : Thanks Robert
> : 
> : jakarta-tomcat-4.1.12
> : jakarta-tomcat-connectors-4.1.12
> : Apache/2.0.43
> : Solaris 9
> : 
> : Nov 13, 2002 9:29:04 AM org.apache.jk.server.JkMain newHandler
> : SEVERE: Can't create apr
> : java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> : at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
> : at java.lang.Class.forName0(Native Method)
> : at java.lang.Class.forName(Class.java:130)
> : at org.apache.jk.server.JkMain.newHandler(JkMain.java:494)
> : at org.apache.jk.server.JkMain.start(JkMain.java:316)
> : at
> : org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.jav
> : 
> : workers2.properties
> : 
> : [shm]
> : file=${serverRoot}/logs/shm.file
> : size=1048576
> : 
> : # Example unixsocket channel.
> : [channel.un:unixsocket]
> : file=/usr/local/tomcat/work/jk2.socket
> : 
> : # define the worker
> : [ajp13:unixsocket]
> : channel=channel.un:unixsocket
> : 
> : # Uri mapping
> : [uri:/examples/*]
> : worker=ajp13:unixsocket
> : 
> : jk2.properties
> : # list of needed handlers.
> : handler.list=apr,channelUnix,request
> : 
> : # Location of the socket.
> : channelUnix.file=${jkHome}/work/jk2.socket
> : 
> : # Dynamic library
> : apr.NativeSo=${jkHome}/lib/jkjni.so
> : 
> : jk2.properties.save
> : #AUTOMATICALLY GENERATED
> : #Wed Nov 13 09:38:33 PST 2002
> : handler.list=apr,channelUnix,request
> : secure=false
> : soTimeout=2
> : port=8009
> : jkHome=/usr/local/jakarta-tomcat-4.1.12
> : maxThreads=75
> : backlog=10
> : apr.NativeSo=${jkHome}/lib/jkjni.so
> : timeout=2
> : channelUnix.file=${jkHome}/work/jk2.socket
> : tcpNoDelay=true
> : 
> : 
> : Build Apache
> : ./configure --with-mpm=worker --enable-so --enable-layout=Apache
> : --enable-module=most --enable-mods-shared=most
> : make
> : make install
> : 
> : Build jk2 Conector
> : cd ${conector.home}/jk/native2
> : sh ./buildconf.sh
> : 
> : cp  /usr/java/include/solaris to /usr/java/include/
> : 
> : CPPFLAGS=-DBSD_COMP  ./configure \
> : --with-apxs2=/usr/local/apache2/bin/apxs \
> : --with-tomcat41=/usr/local/tomcat \
> : --with-java-home=${JAVA_HOME} \
> : --with-java-platform=2 \
> : --with-jni
> : 
> : make CPPFLAGS=-DBSD_COMP
> : 
> : cd ${conector.home}/jk/build/jk2/apache2
> : mkdir /usr/local/tomcat/lib/
> : cp * /usr/local/tomcat/lib/
> : cp mod_jk2.so /usr/local/apache2/modules/
> : 
> : installed GNU Tools
> : autoconf-2.54-sol9-sparc-local.gz
> : tar-1.13.19-sol9-sparc-local.gz
> : m4-1.4-sol9-sparc-local
> : automake-1.7.1-sol9-sparc-local
> : make-3.80-sol9-sparc-local.gz
> : libtool-1.4
> :  
> : 
> : 
> : 
> : --
> : To unsubscribe, e-mail:
> : 
> : For
> : additional commands,
> : e-mail: 
> :


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

Re: Release notes

[Amy Roh]

Fredrik Westermarck wrote:

Hi!

If the patch which enables JNDIRealms to use SSL will make it into the 
next release of TC 4.1 it might be a good idea to add it in the release 
notes too.

Done.  Thanks for the reminder.

Amy



Regards,
Fredrik Westermarck


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 






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

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

[amyroh]

amyroh  2002/11/13 12:13:15

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  Document the newly supported SSL with JNDIRealm in the RELEASE-NOTES.
  
  Revision  ChangesPath
  1.31  +4 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- RELEASE-NOTES-4.1.txt 13 Nov 2002 14:36:20 -  1.30
  +++ RELEASE-NOTES-4.1.txt 13 Nov 2002 20:13:15 -  1.31
  @@ -91,6 +91,9 @@
   [4.1.8] BootstrapService:
   Allow passing parameters to the BootstrapService.
   
  +[4.1.15] JNDIRealm:
  + Add support for SSL with the JNDIRealm.
  +
   
   ---
   Jasper New Features:
  
  
  

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

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

[kinman]

kinman  2002/11/13 11:50:42

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  - Add  in the standard systex.
  
  Revision  ChangesPath
  1.39  +16 -3 
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.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- Parser.java   8 Nov 2002 19:42:55 -   1.38
  +++ Parser.java   13 Nov 2002 19:50:42 -  1.39
  @@ -854,6 +854,16 @@
   parseEmptyBody(doBodyNode, "jsp:doBody");
   }
   
  +private void parseElement(Node parent) throws JasperException {
  + Attributes attrs = parseAttributes();
  + reader.skipSpaces();
  +
  +Node elementNode = new Node.JspElement(attrs, start, parent);
  +
  +parseOptionalBody( elementNode, "jsp:element", 
  +TagInfo.BODY_CONTENT_JSP );
  +}
  +
   /*
* For GetProperty:
* StdActionContent ::= Attributes EmptyBody
  @@ -1132,6 +1142,7 @@
*| 'setProperty'   StdActionContent
*| 'useBean'   StdActionContent
*| 'plugin'StdActionContent
  + *| 'element'   StdActionContent
*/
   private void parseAction(Node parent) throws JasperException {
Mark start = reader.mark();
  @@ -1162,6 +1173,8 @@
parseUseBean(parent);
} else if (reader.matches("plugin")) {
parsePlugin(parent);
  + } else if (reader.matches("element")) {
  + parseElement(parent);
} else {
err.jspError(start, "jsp.error.badaction");
}
  
  
  

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

RE: JK2 unixsocket: Can't create apr

[Brzezinski, Paul J]

I wonder if a better question is:

Is anyone using the ChannelUnix (AF_UNIX socket) connector on any platform?

On what platforms is the ChannelUnix (AF_UNIX socket) connector actually
known to function?



: -Original Message-
: From: Robert Williams [mailto:rcw1@;pacbell.net] 
: Sent: Wednesday, November 13, 2002 1:05 PM
: To: Tomcat User
: Subject: JK2 unixsocket: Can't create apr
: 
: 
: Hi all,
: I am trying to implement the unixsocket on JK2. While the 
: channelSocket
: works fine I was hoping to get the speed benefits of a 
: unixsocket. I am
: using the example setups in the JK2 documentation. And since 
: it seems to
: be looking for  the LogFactory I have made sure that
: commons-logging-api.jar  was in the Tomcat common/lib and I 
: also put it
: in java/jre/lib/ext as well. All to no avail. I am stumped. I haven't
: been able to find anything in the list or on google addressing this
: problem. Some docs regarding channelSocket say disable apr for this
: error but apparently unixsocket won't work without apr 
: enabled. Any help
: would be appreciated.
: Thanks Robert
: 
: jakarta-tomcat-4.1.12
: jakarta-tomcat-connectors-4.1.12
: Apache/2.0.43
: Solaris 9
: 
: Nov 13, 2002 9:29:04 AM org.apache.jk.server.JkMain newHandler
: SEVERE: Can't create apr
: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
: at org.apache.jk.apr.AprImpl.(AprImpl.java:340)
: at java.lang.Class.forName0(Native Method)
: at java.lang.Class.forName(Class.java:130)
: at org.apache.jk.server.JkMain.newHandler(JkMain.java:494)
: at org.apache.jk.server.JkMain.start(JkMain.java:316)
: at
: org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.jav
: 
: workers2.properties
: 
:   [shm]
:   file=${serverRoot}/logs/shm.file
:   size=1048576
: 
:   # Example unixsocket channel.
:   [channel.un:unixsocket]
:   file=/usr/local/tomcat/work/jk2.socket
: 
:   # define the worker
:   [ajp13:unixsocket]
:   channel=channel.un:unixsocket
: 
:   # Uri mapping
:   [uri:/examples/*]
:   worker=ajp13:unixsocket
: 
: jk2.properties
:   # list of needed handlers.
:   handler.list=apr,channelUnix,request
: 
:   # Location of the socket.
:   channelUnix.file=${jkHome}/work/jk2.socket
: 
:   # Dynamic library
:   apr.NativeSo=${jkHome}/lib/jkjni.so
: 
: jk2.properties.save
:   #AUTOMATICALLY GENERATED
:   #Wed Nov 13 09:38:33 PST 2002
:   handler.list=apr,channelUnix,request
:   secure=false
:   soTimeout=2
:   port=8009
:   jkHome=/usr/local/jakarta-tomcat-4.1.12
:   maxThreads=75
:   backlog=10
:   apr.NativeSo=${jkHome}/lib/jkjni.so
:   timeout=2
:   channelUnix.file=${jkHome}/work/jk2.socket
:   tcpNoDelay=true
: 
: 
: Build Apache
:   ./configure --with-mpm=worker --enable-so --enable-layout=Apache
: --enable-module=most --enable-mods-shared=most
:   make 
:   make install
: 
: Build jk2 Conector 
:   cd ${conector.home}/jk/native2
:   sh ./buildconf.sh
: 
:   cp  /usr/java/include/solaris to /usr/java/include/
: 
:   CPPFLAGS=-DBSD_COMP  ./configure \
: --with-apxs2=/usr/local/apache2/bin/apxs \
: --with-tomcat41=/usr/local/tomcat \
: --with-java-home=${JAVA_HOME} \
: --with-java-platform=2 \
: --with-jni
: 
:   make CPPFLAGS=-DBSD_COMP
: 
:   cd ${conector.home}/jk/build/jk2/apache2
:   mkdir /usr/local/tomcat/lib/
:   cp * /usr/local/tomcat/lib/
:   cp mod_jk2.so /usr/local/apache2/modules/
: 
: installed GNU Tools
:   autoconf-2.54-sol9-sparc-local.gz
:   tar-1.13.19-sol9-sparc-local.gz
:   m4-1.4-sol9-sparc-local
:   automake-1.7.1-sol9-sparc-local
:   make-3.80-sol9-sparc-local.gz
:   libtool-1.4
:  
: 
: 
: 
: --
: To unsubscribe, e-mail:   
: 
: For 
: additional commands, 
: e-mail: 
: 

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

Release notes

[Fredrik Westermarck]

Hi!

If the patch which enables JNDIRealms to use SSL will make it into the 
next release of TC 4.1 it might be a good idea to add it in the release 
notes too.

Regards,
Fredrik Westermarck


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

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

[bugzilla]

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

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

Resubmit to j_security_check mistakenly fetches a page of that name





--- Additional Comments From [EMAIL PROTECTED]  2002-11-13 18:53 ---
That sounds great to me!

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

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

[kinman]

kinman  2002/11/13 10:38:11

  Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
  Log:
  - Remove unused fields and methods.
  
  Revision  ChangesPath
  1.24  +3 -14 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- TagLibraryInfoImpl.java   30 Oct 2002 17:41:22 -  1.23
  +++ TagLibraryInfoImpl.java   13 Nov 2002 18:38:11 -  1.24
  @@ -82,9 +82,6 @@
*/
   class TagLibraryInfoImpl extends TagLibraryInfo {
   
  -private static final String TAGLIB_TLD = "META-INF/taglib.tld";
  -private static final String WEB_XML = "/WEB-INF/web.xml";
  -
   private Hashtable jarEntries;
   private JspCompilationContext ctxt;
   private ErrorDispatcher err;
  @@ -241,14 +238,6 @@
}
   }
   
  -/*
  - * Returns true if the given URI is relative in this web application,
  - * false if it is an internet URI.
  - */
  -private boolean isRelativeURI(String uri) {
  -return (uri.indexOf(':') == -1);
  -}
  -  
   private void parseTLD(JspCompilationContext ctxt,
 String uri, InputStream in, JarFile jarFile) 
   throws JasperException
  
  
  

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

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

[luehe]

luehe   2002/11/13 09:40:43

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
   jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
  Log:
  JspContextWrapper: Allocate vectors for nested, at_begin, and at_end
  variables only if needed.
  
  Revision  ChangesPath
  1.125 +22 -6 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.124
  retrieving revision 1.125
  diff -u -r1.124 -r1.125
  --- Generator.java8 Nov 2002 19:55:47 -   1.124
  +++ Generator.java13 Nov 2002 17:40:38 -  1.125
  @@ -3031,19 +3031,35 @@
   out.printil("public void setJspContext( JspContext ctx ) {");
   out.pushIndent();
   out.printil("super.setJspContext(ctx);");
  - out.printil("java.util.Vector _jspx_nested = new java.util.Vector();");
  - out.printil("java.util.Vector _jspx_at_begin = new java.util.Vector();");
  - out.printil("java.util.Vector _jspx_at_end = new java.util.Vector();");
TagVariableInfo[] tagVars = tagInfo.getTagVariableInfos();
  + out.printil("java.util.Vector _jspx_nested = null;");
  + out.printil("java.util.Vector _jspx_at_begin = null;");
  + out.printil("java.util.Vector _jspx_at_end = null;");
  +
for (int i=0; i@ -124,8 +124,9 @@
this.atBeginVars = atBeginVars;
this.atEndVars = atEndVars;
this.pageAttributes = new Hashtable(16);
  - this.originalNestedVars = new Hashtable(nestedVars.size());
  -
  + if (nestedVars != null) {
  + this.originalNestedVars = new Hashtable(nestedVars.size());
  + }
copyPageToTagScope(VariableInfo.AT_BEGIN);
saveNestedVariables();
   }
  @@ -326,14 +327,18 @@
   
switch (scope) {
case VariableInfo.NESTED:
  - iter = nestedVars.iterator();
  + if (nestedVars != null) {
  + iter = nestedVars.iterator();
  + }
break;
case VariableInfo.AT_BEGIN:
  - iter = atBeginVars.iterator();
  + if (atBeginVars != null) {
  + iter = atBeginVars.iterator();
  + }
break;
}
   
  - while (iter.hasNext()) {
  + while ((iter != null) && iter.hasNext()) {
String varName = (String) iter.next();
Object obj = invokingJspCtxt.getAttribute(varName);
if (obj != null) {
  @@ -353,17 +358,23 @@
   
switch (scope) {
case VariableInfo.NESTED:
  - iter = nestedVars.iterator();
  + if (nestedVars != null) {
  + iter = nestedVars.iterator();
  + }
break;
case VariableInfo.AT_BEGIN:
  - iter = atBeginVars.iterator();
  + if (atBeginVars != null) {
  + iter = atBeginVars.iterator();
  + }
break;
case VariableInfo.AT_END:
  - iter = atEndVars.iterator();
  + if (atEndVars != null) {
  + iter = atEndVars.iterator();
  + }
break;
}
   
  - while (iter.hasNext()) {
  + while ((iter != null) && iter.hasNext()) {
String varName = (String) iter.next();
Object obj = getAttribute(varName);
if (obj != null) {
  @@ -379,12 +390,14 @@
* the invoking JSP context, so they can later be restored.
*/
   public void saveNestedVariables() {
  - Iterator iter = nestedVars.iterator();
  - while (iter.hasNext()) {
  - String varName = (String) iter.next();
  - Object obj = invokingJspCtxt.getAttribute(varName);
  - if (obj != null) {
  - originalNestedVars.put(varName, obj);
  + if (nestedVars != null) {
  + Iterator iter = nestedVars.iterator();
  + while (iter.hasNext()) {
  + String varName = (String) iter.next();
  + Object obj = invokingJspCtxt.getAttribute(varName);
  + if (obj != null) {
  + originalNestedVars.put(varName, obj);
  + }
}
}
   }
  @@ -394,14 +407,16 @@
* context.
*/
   public void restoreNestedVariables() {
  - Iterator iter = nestedVars.iterator();
  - while (iter.hasNext()) {
  - String varName = (String) iter.next();
  - Object obj = originalNestedVars.get(varName);
  - if (obj != null) {
  - invokingJspCtxt.setAttribute(varName, obj);
  - } else {
  - invokingJspCtxt.removeAttribute(varName, PAGE_SCOPE);
  + if (nestedVars != null) {
  + Iterator iter = nestedVars.iterator();
  + while (iter.hasNext()) {
  + String varName = (String) iter.

DO NOT REPLY [Bug 14515] New: - Documents are transmitted twice when calling via POST from external source

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

Documents are transmitted twice when calling via POST from external source

   Summary: Documents are transmitted twice when calling via POST
from external source
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following configuration makes tomcat (or the http-Connector?) transmit
the document (html page or jsp) twice. 
This causes the page to be shown twice on the client:

- An external site (not hosted on tomcat) has a form which is sent via
  POST on a tomcat page.

- The document on the tomcat server is the index document for that web 
  application.

- There is a filter for that web application which reads the parameters given
  by the post request and sets some session parameters and a cookie.
  It also wraps the request to overload getRemoteUser and isUserInRole.
  (That filter is actually used for single-sign-on authentication.)

- The referring site is hosted on the same machine, but on an Apache web server:
  http://www/apostform.html --[http-post]---> http://www:8081/myapp/index.jsp


According to tcpdump, the page is transmitted twice as a reply for a single
post request. The reply is also transmitted in a single packet (if it's small
enough) which may indicate that the output buffers on tomcat have nut been flushed.

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

Re: Client-cert authentication.

[jean-frederic clere]

Moisés Serrano Martínez wrote:



- Original Message -
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 13, 2002 4:58 PM
Subject: Re: Client-cert authentication.


Moisés Serrano Martínez wrote:


Thanks a lot. At the end I got it.



Great!



A new question:

Does anybody know how to access to the data in a certificate from a client
browser.
In order to sign a document in a client who doesn´t have the Java
environment.



I am not sure I understand what you want to do: import a certificate in the
browser?

No. This is quite clear, thanks a lot.

What I need to do is to access the data included in a certificate in the
client side. In order to develop a work-flow process signing/verifying the
document in every step of the work-flow. All these in a client withour J2EE
environment.

As far as I know, when you sign something in a asymetric encryption mode you
sign the document with your private key and the receiver can verify the sign
with the public key included in the certificate.

The question is : How can I manage to access the private key included in the
client keystore (.pfx or .p12 certificate) in order to allow the client to
sign something. I suppose this is something similar than a client mail do
when you sign an e-mail attaching the certificate to the e-mail and the
receiver can read it only if he has the certificate associated to the
address with the correct email in the address book.

is the question more clear now?


Yes. But it has only very little to do with Tomcat... (WebDAV to transfer the 
documents).


Thank´s a lot in advance








any idea for beginning to investigate.
javasript?
browser api?



--
To unsubscribe, e-mail:





For additional commands, e-mail:











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




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







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

Re: Client-cert authentication.

[Moisés Serrano Martínez]

- Original Message -
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 13, 2002 4:58 PM
Subject: Re: Client-cert authentication.


Moisés Serrano Martínez wrote:
> Thanks a lot. At the end I got it.

Great!

>
> A new question:
>
> Does anybody know how to access to the data in a certificate from a client
> browser.
> In order to sign a document in a client who doesn´t have the Java
> environment.

I am not sure I understand what you want to do: import a certificate in the
browser?

No. This is quite clear, thanks a lot.

What I need to do is to access the data included in a certificate in the
client side. In order to develop a work-flow process signing/verifying the
document in every step of the work-flow. All these in a client withour J2EE
environment.

As far as I know, when you sign something in a asymetric encryption mode you
sign the document with your private key and the receiver can verify the sign
with the public key included in the certificate.

The question is : How can I manage to access the private key included in the
client keystore (.pfx or .p12 certificate) in order to allow the client to
sign something. I suppose this is something similar than a client mail do
when you sign an e-mail attaching the certificate to the e-mail and the
receiver can read it only if he has the certificate associated to the
address with the correct email in the address book.

is the question more clear now?

Thank´s a lot in advance






>
> any idea for beginning to investigate.
> javasript?
> browser api?
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>




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




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

Re: Client-cert authentication.

[jean-frederic clere]

Moisés Serrano Martínez wrote:

Thanks a lot. At the end I got it.


Great!



A new question:

Does anybody know how to access to the data in a certificate from a client
browser.
In order to sign a document in a client who doesn´t have the Java
environment.


I am not sure I understand what you want to do: import a certificate in the browser?



any idea for beginning to investigate.
javasript?
browser api?



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







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

Re: JSPC refactoring/documentation

[Donald Ball]

On 11/12/2002 at 4:03 PM Costin Manolache wrote:

>Fredrik Westermarck wrote:
>
>> The problem that I and others have experienced is that proposals and/or
>> patches, by non-committers, don't get discussed or voted about.
>
>You have to keep pushing. If you send patches and proposals you can
>become a committer - and then you'll start ignoring patches and proposals

>:-)

I know you mean that in jest, but I have two big problems with what you
said:

1. Simply sending patches and proposals is enough to become a committer? On
the other apache projects on which I've worked, several months of
consistent quality patches and involvement on the lists is necessary to
achieve committer status.

2. Committers ignore patches and proposals from non-committers - though
said with smilies, does seem to be the status quo, from my personal
experience and that of others. Do you not see this as a problem?

Not every guy who finds (and patches!) a bug in tomcat has the time or
interest to become a committer (nor should they), and I don't think you
should require that before their patches have a chance to get in. I know
that no one ever has enough time to do everything, and staying on top of
patch submissions can be a chore, yes. With enough committers, and tomcat
certainly seems to have enough, you can manage - make it a rotating chore
to scan the developers list, tell patchers that they should contact the
module authors directly, use bugzilla to manage the patch queue, etc.,
etc., etc.

>I'm sorry - but everyone is very short on time. If you have a real
interest
>in tomcat the best solution is to send patches, insist on getting them
>accepted and become a committer. I think many people here will tell you
>it's not that hard.

Therein lies the rub. Not every joe that comes up with a patch for tomcat
should get committer access, in my eyes. Nor should the tomcat developers
ignore contributed patches. There's got to be a better way.

- donald


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

Re: Client-cert authentication.

[Moisés Serrano Martínez]

Thanks a lot. At the end I got it.

A new question:

Does anybody know how to access to the data in a certificate from a client
browser.
In order to sign a document in a client who doesn´t have the Java
environment.

any idea for beginning to investigate.
javasript?
browser api?



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

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

[Glenn Nielsen]

Remy Maucherat wrote:

Glenn Nielsen wrote:


Remy Maucherat wrote:

> [EMAIL PROTECTED] wrote:
>
>> glenn   2002/11/12 18:23:11
>>
>>   Modified:catalina/src/share/org/apache/catalina/core
>> NamingContextListener.java 
StandardContext.java
>>catalina/src/share/org/apache/naming 
ContextBindings.java
>>   Log:
>>   Bug fix for BUG #13364
>>
>>   A Web Application Context reload by the manager web application
>>   was causing named JNDI resources to disappear.
>>
>>   A webapp reload needs to dump the webapp classloader, then
>>   recreate. The CL is bound to the naming context so the
>>   reload was issing a NamingContext STOP_EVENT and then a
>>   START_EVENT.  This removed all the JNDI named resources
>>   but the code which runs at webapp startup which creates
>>   the JNDI named resources is not run on a reload.
>>
>>   I fixed this by removing the START and STOP events and
>>   adding BEFORE_STOP_EVENT and AFTER_START_EVENT
>>   lifecycle events whose only purpose is to bind or unbind the
>>   ClassLoader to the JNDI context.
>
>
>
>
> This fix seems incorrect to me. The naming context must be destroyed,
> as the references which are bound in it have been created by the old
> classloader.
>

Hmmm.  You may have something here. But this would only affect resources
which are created who's classes exist within /WEB-INF/lib or
/WEB-INF/classes
and are loaded by the WebappClassLoader rather than a parent class 
loader.



Yes, but this might happen. I thought about it more, and although it is 
unlikely, it is a possibility. The main factory uses the context CL to 
load the object factory, so it's legal to have it here.

After more investigation (and realizing I had missed the 
"DefaultContext" keyword in the bug description. duh ! I suppose the 
current mail lag caused me to waste a couple hours :-( ), I was able to 
reproduce the bug. I have just committed a much simpler fix. It looks 
safer, I think (the reload event is interpreted by the default context 
as a stop/start, and that's it).

Sorry for the trouble.

Remy


Thats ok.  I am glad you reviewed the patch.

I caught that the Context had to be unbound from the old CL and rebound to
the new CL but didn't consider that some of the resources may have been
created using classess loaded by the old CL.

I tested your patch and it works fine.

Thanks,

Glenn


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

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

[remm]

remm2002/11/13 06:36:20

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Update status.
  
  Revision  ChangesPath
  1.30  +6 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- RELEASE-NOTES-4.1.txt 11 Nov 2002 11:53:01 -  1.29
  +++ RELEASE-NOTES-4.1.txt 13 Nov 2002 14:36:20 -  1.30
  @@ -508,6 +508,11 @@
allowLinking will also disable case sensitivity checks (which are
relatively similar).
   
  +[4.1.15] #13364
  + StandardDefaultContext:
  + Properly refresh naming entries defined in the DefaultContext after a
  + reload.
  +
   
   
   Coyote Bug Fixes:
  
  
  

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

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

[remm]

remm2002/11/13 06:35:55

  Modified:catalina/src/share/org/apache/catalina/core
StandardDefaultContext.java
  Log:
  - Port patch.
  - Reload is the equivalent of stop/start for naming purposes.
  - Fixes bug 13364, while still doing a refresh of the naming context (which is
needed as it might contain instances loaded by the old classloader).
  
  Revision  ChangesPath
  1.3   +22 -16
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
  
  Index: StandardDefaultContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- StandardDefaultContext.java   20 Sep 2002 21:22:31 -  1.2
  +++ StandardDefaultContext.java   13 Nov 2002 14:35:55 -  1.3
  @@ -1240,7 +1240,24 @@
   return;
   }
   
  -if (event.getType().equals(Lifecycle.AFTER_START_EVENT)) {
  +if ((event.getType().equals(Lifecycle.BEFORE_STOP_EVENT))
  +|| (event.getType().equals(Context.RELOAD_EVENT))) {
  +
  +// Remove context
  +contexts.remove(context);
  +
  +// Remove listener from the NamingResource listener list
  +namingResources.removePropertyChangeListener(listener);
  +
  +// Remove listener from lifecycle listeners
  +if (!(event.getType().equals(Context.RELOAD_EVENT))) {
  +context.removeLifecycleListener(this);
  +}
  +
  +}
  +
  +if ((event.getType().equals(Lifecycle.AFTER_START_EVENT))
  +|| (event.getType().equals(Context.RELOAD_EVENT))) {
   
   // Add context
   contexts.put(context, context);
  @@ -1290,17 +1307,6 @@
   
   // Add listener to the NamingResources listener list
   namingResources.addPropertyChangeListener(listener);
  -
  -} else if (event.getType().equals(Lifecycle.BEFORE_STOP_EVENT)) {
  -
  -// Remove context
  -contexts.remove(context);
  -
  -// Remove listener from the NamingResource listener list
  -namingResources.removePropertyChangeListener(listener);
  -
  -// Remove listener from lifecycle listeners
  -context.removeLifecycleListener(this);
   
   }
   
  
  
  

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

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

[Remy Maucherat]

Glenn Nielsen wrote:


Remy Maucherat wrote:

> [EMAIL PROTECTED] wrote:
>
>> glenn   2002/11/12 18:23:11
>>
>>   Modified:catalina/src/share/org/apache/catalina/core
>> NamingContextListener.java StandardContext.java
>>catalina/src/share/org/apache/naming 
ContextBindings.java
>>   Log:
>>   Bug fix for BUG #13364
>>
>>   A Web Application Context reload by the manager web application
>>   was causing named JNDI resources to disappear.
>>
>>   A webapp reload needs to dump the webapp classloader, then
>>   recreate. The CL is bound to the naming context so the
>>   reload was issing a NamingContext STOP_EVENT and then a
>>   START_EVENT.  This removed all the JNDI named resources
>>   but the code which runs at webapp startup which creates
>>   the JNDI named resources is not run on a reload.
>>
>>   I fixed this by removing the START and STOP events and
>>   adding BEFORE_STOP_EVENT and AFTER_START_EVENT
>>   lifecycle events whose only purpose is to bind or unbind the
>>   ClassLoader to the JNDI context.
>
>
>
>
> This fix seems incorrect to me. The naming context must be destroyed,
> as the references which are bound in it have been created by the old
> classloader.
>

Hmmm.  You may have something here. But this would only affect resources
which are created who's classes exist within /WEB-INF/lib or
/WEB-INF/classes
and are loaded by the WebappClassLoader rather than a parent class loader.


Yes, but this might happen. I thought about it more, and although it is 
unlikely, it is a possibility. The main factory uses the context CL to 
load the object factory, so it's legal to have it here.

After more investigation (and realizing I had missed the 
"DefaultContext" keyword in the bug description. duh ! I suppose the 
current mail lag caused me to waste a couple hours :-( ), I was able to 
reproduce the bug. I have just committed a much simpler fix. It looks 
safer, I think (the reload event is interpreted by the default context 
as a stop/start, and that's it).

Sorry for the trouble.

Remy


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

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

[Glenn Nielsen]

Remy Maucherat wrote:

Remy Maucherat wrote:


[EMAIL PROTECTED] wrote:

> glenn   2002/11/12 18:23:11
>
>   Modified:catalina/src/share/org/apache/catalina/core
> NamingContextListener.java StandardContext.java
>catalina/src/share/org/apache/naming 
ContextBindings.java
>   Log:
>   Bug fix for BUG #13364
>
>   A Web Application Context reload by the manager web application
>   was causing named JNDI resources to disappear.
>
>   A webapp reload needs to dump the webapp classloader, then
>   recreate. The CL is bound to the naming context so the
>   reload was issing a NamingContext STOP_EVENT and then a
>   START_EVENT.  This removed all the JNDI named resources
>   but the code which runs at webapp startup which creates
>   the JNDI named resources is not run on a reload.
>
>   I fixed this by removing the START and STOP events and
>   adding BEFORE_STOP_EVENT and AFTER_START_EVENT
>   lifecycle events whose only purpose is to bind or unbind the
>   ClassLoader to the JNDI context.



This fix seems incorrect to me. The naming context must be destroyed, as
the references which are bound in it have been created by the old
classloader.

The NamingResources object is supposed to contain all the necessary data
to recrate the JNDI context. The question, and what I was planning to
investigate, is why it doesn't work. I think it did in the past.

I'll revert this patch when I find a better fix for the bug.



I investigated the problem as much as I could, and I cannot reproduce 
the original bug.
The patch introduces wrong behavior as explained, so I am -1 for it, and 
will revert it.

The original report was that the JNDI resources were disappearing after 
a reload of a context using the manager.
Here is what I did to try to reproduce it:
- full recompile and start of Tomcat 4.1, after adding a user for the 
manager webapp
- use of the JNDI servlet to display the naming environment of the 
"examples" context (http://127.0.0.1:8080/examples/servlet/JndiServlet)
- use of the HTML interface to the manager to reload the "examples" 
context (http://127.0.0.1:8080/manager/html/reload?path=/examples)
- reload was successful
- use JNDI servlet in a different browser (Moz, the first one was in 
IE); result is the same as the first attempt

So I would like detailed information on:
- what is actually failing
- how to reproduce it


I can reproduce the bug every time when the resource is defined in the
DefaultContext.

Regards,

Glenn


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

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

[remm]

remm2002/11/13 06:16:24

  Modified:catalina/src/share/org/apache/catalina/core
StandardDefaultContext.java
  Log:
  - Reload is the equivalent of stop/start for naming purposes.
  - Fixes bug 13364, while still doing a refresh of the naming context (which is
needed as it might contain instances loaded by the old classloader).
  
  Revision  ChangesPath
  1.9   +22 -16
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
  
  Index: StandardDefaultContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- StandardDefaultContext.java   19 Sep 2002 22:55:48 -  1.8
  +++ StandardDefaultContext.java   13 Nov 2002 14:16:24 -  1.9
  @@ -1268,7 +1268,24 @@
   return;
   }
   
  -if (event.getType().equals(Lifecycle.AFTER_START_EVENT)) {
  +if ((event.getType().equals(Lifecycle.BEFORE_STOP_EVENT))
  +|| (event.getType().equals(Context.RELOAD_EVENT))) {
  +
  +// Remove context
  +contexts.remove(context);
  +
  +// Remove listener from the NamingResource listener list
  +namingResources.removePropertyChangeListener(listener);
  +
  +// Remove listener from lifecycle listeners
  +if (!(event.getType().equals(Context.RELOAD_EVENT))) {
  +context.removeLifecycleListener(this);
  +}
  +
  +}
  +
  +if ((event.getType().equals(Lifecycle.AFTER_START_EVENT))
  +|| (event.getType().equals(Context.RELOAD_EVENT))) {
   
   // Add context
   contexts.put(context, context);
  @@ -1318,17 +1335,6 @@
   
   // Add listener to the NamingResources listener list
   namingResources.addPropertyChangeListener(listener);
  -
  -} else if (event.getType().equals(Lifecycle.BEFORE_STOP_EVENT)) {
  -
  -// Remove context
  -contexts.remove(context);
  -
  -// Remove listener from the NamingResource listener list
  -namingResources.removePropertyChangeListener(listener);
  -
  -// Remove listener from lifecycle listeners
  -context.removeLifecycleListener(this);
   
   }
   
  
  
  

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

Re: OT: XForms Becomes a W3C Candidate Recommendation

[V. Cekvenich]

Also:

2. J2EE server has pre-view:

*  http://help.silverstream.com/help/XFormsTutorial/ *

3. Here is a plug in for IE:
http://www.FormsPlayer.com

just fyi, anyone planing long term direction.

.V

V. Cekvenich wrote:

V. Cekvenich wrote:

 IMO, one day we will do forms processing like this:

 Original Message 
Subject: XForms Becomes a W3C Candidate Recommendation
Resent-Date: Tue, 12 Nov 2002 14:07:28 -0500 (EST)
Resent-From: [EMAIL PROTECTED]
Date: Tue, 12 Nov 2002 19:59:34 +0100
From: Sebastian Schnitzenbaumer <[EMAIL PROTECTED]>



Ladies and Gentlemen,

as the co-chair of the W3C XForms Working Group, I constantly happen to 
find myself in the position of having to say:

XForms 1.0 has become a W3C Candidate Recommendation!

Thank you, www-forms! You've been great. Together we made this happen. 
Spread the news: XForms is now safe to implement and build upon. The 
working group is seeking final implementation feedback.

Now let's enjoy this moment after years of hard work trying to bring the 
Web to its full potential together...

- Sebastian :-)




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

Re: OT: XForms Becomes a W3C Candidate Recommendation

[V. Cekvenich]

V. Cekvenich wrote:

 IMO, one day we will do forms processing like this:

 Original Message 
Subject: XForms Becomes a W3C Candidate Recommendation
Resent-Date: Tue, 12 Nov 2002 14:07:28 -0500 (EST)
Resent-From: [EMAIL PROTECTED]
Date: Tue, 12 Nov 2002 19:59:34 +0100
From: Sebastian Schnitzenbaumer <[EMAIL PROTECTED]>



Ladies and Gentlemen,

as the co-chair of the W3C XForms Working Group, I constantly happen to 
find myself in the position of having to say:

XForms 1.0 has become a W3C Candidate Recommendation!

Thank you, www-forms! You've been great. Together we made this happen. 
Spread the news: XForms is now safe to implement and build upon. The 
working group is seeking final implementation feedback.

Now let's enjoy this moment after years of hard work trying to bring the 
Web to its full potential together...

- Sebastian :-)







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

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

[remm]

remm2002/11/13 01:20:33

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Revert patch (see explanation).
  
  Revision  ChangesPath
  1.115 +2 -2  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.114
  retrieving revision 1.115
  diff -u -r1.114 -r1.115
  --- StandardContext.java  13 Nov 2002 02:23:10 -  1.114
  +++ StandardContext.java  13 Nov 2002 09:20:32 -  1.115
  @@ -2486,7 +2486,7 @@
   if (isUseNaming()) {
   // Start
   namingContextListener.lifecycleEvent
  -(new LifecycleEvent(this, Lifecycle.BEFORE_STOP_EVENT));
  +(new LifecycleEvent(this, Lifecycle.STOP_EVENT));
   }
   
   // Binding thread
  @@ -2522,7 +2522,7 @@
   if (isUseNaming()) {
   // Start
   namingContextListener.lifecycleEvent
  -(new LifecycleEvent(this, Lifecycle.AFTER_START_EVENT));
  +(new LifecycleEvent(this, Lifecycle.START_EVENT));
   }
   
   // Binding thread
  
  
  

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

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

[remm]

remm2002/11/13 01:19:31

  Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java
  Log:
  - Revert patch (see explanation).
  
  Revision  ChangesPath
  1.21  +14 -39
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
  
  Index: NamingContextListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- NamingContextListener.java13 Nov 2002 02:23:10 -  1.20
  +++ NamingContextListener.java13 Nov 2002 09:19:31 -  1.21
  @@ -293,62 +293,37 @@
   log(sm.getString("naming.namingContextCreationFailed", e));
   }
   
  -if (container instanceof Server) {
  -namingResources.addPropertyChangeListener(this);
  -org.apache.naming.factory.ResourceLinkFactory.setGlobalContext
  -(namingContext);
  -try {
  -ContextBindings.bindClassLoader
  -(container, container,
  - this.getClass().getClassLoader());
  -} catch (NamingException e) {
  -log(sm.getString("naming.bindFailed", e));
  -}
  -if (container instanceof StandardServer) {
  -((StandardServer) container).setGlobalNamingContext
  -(namingContext);
  -}
  -} else if (container instanceof Context) {
  +// Binding the naming context to the class loader
  +if (container instanceof Context) {
   // Setting the context in read only mode
   ContextAccessController.setReadOnly(getName());
   try {
   ContextBindings.bindClassLoader
  -(container, container,
  +(container, container, 
((Container) container).getLoader().getClassLoader());
   } catch (NamingException e) {
   log(sm.getString("naming.bindFailed", e));
   }
   }
   
  -initialized = true;
  -
  -} else if (event.getType() == Lifecycle.AFTER_START_EVENT ) {
  -// Used at end of a Web Application Context reload
  -if (container instanceof Context) {
  -// Setting the context in read only mode
  -ContextAccessController.setReadOnly(getName());
  +if (container instanceof Server) {
  +namingResources.addPropertyChangeListener(this);
  +org.apache.naming.factory.ResourceLinkFactory.setGlobalContext
  +(namingContext);
   try {
   ContextBindings.bindClassLoader
  -(container, container,
  - ((Container) container).getLoader().getClassLoader());
  +(container, container, 
  + this.getClass().getClassLoader());
   } catch (NamingException e) {
   log(sm.getString("naming.bindFailed", e));
   }
  +if (container instanceof StandardServer) {
  +((StandardServer) container).setGlobalNamingContext
  +(namingContext);
  +}
   }
   
  -} else if (event.getType() == Lifecycle.BEFORE_STOP_EVENT) {
  -// Used when starting a Web Application Context reload
  -if (!initialized)
  -return;
  -
  -// Setting the context in read/write mode
  -ContextAccessController.setWritable(getName(), container);
  -
  -if (container instanceof Context) {
  -ContextBindings.unbindClassLoader
  -(container, container,
  - ((Container) container).getLoader().getClassLoader());
  -}
  +initialized = true;
   
   } else if (event.getType() == Lifecycle.STOP_EVENT) {
   
  
  
  

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

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

[Remy Maucherat]

Remy Maucherat wrote:


[EMAIL PROTECTED] wrote:

> glenn   2002/11/12 18:23:11
>
>   Modified:catalina/src/share/org/apache/catalina/core
> NamingContextListener.java StandardContext.java
>catalina/src/share/org/apache/naming ContextBindings.java
>   Log:
>   Bug fix for BUG #13364
>
>   A Web Application Context reload by the manager web application
>   was causing named JNDI resources to disappear.
>
>   A webapp reload needs to dump the webapp classloader, then
>   recreate. The CL is bound to the naming context so the
>   reload was issing a NamingContext STOP_EVENT and then a
>   START_EVENT.  This removed all the JNDI named resources
>   but the code which runs at webapp startup which creates
>   the JNDI named resources is not run on a reload.
>
>   I fixed this by removing the START and STOP events and
>   adding BEFORE_STOP_EVENT and AFTER_START_EVENT
>   lifecycle events whose only purpose is to bind or unbind the
>   ClassLoader to the JNDI context.



This fix seems incorrect to me. The naming context must be destroyed, as
the references which are bound in it have been created by the old
classloader.

The NamingResources object is supposed to contain all the necessary data
to recrate the JNDI context. The question, and what I was planning to
investigate, is why it doesn't work. I think it did in the past.

I'll revert this patch when I find a better fix for the bug.



I investigated the problem as much as I could, and I cannot reproduce 
the original bug.
The patch introduces wrong behavior as explained, so I am -1 for it, and 
will revert it.

The original report was that the JNDI resources were disappearing after 
a reload of a context using the manager.
Here is what I did to try to reproduce it:
- full recompile and start of Tomcat 4.1, after adding a user for the 
manager webapp
- use of the JNDI servlet to display the naming environment of the 
"examples" context (http://127.0.0.1:8080/examples/servlet/JndiServlet)
- use of the HTML interface to the manager to reload the "examples" 
context (http://127.0.0.1:8080/manager/html/reload?path=/examples)
- reload was successful
- use JNDI servlet in a different browser (Moz, the first one was in 
IE); result is the same as the first attempt

So I would like detailed information on:
- what is actually failing
- how to reproduce it

Thanks,
Remy


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

Re: tomcat suddenly stops

[Scott Stirling]

Hi, 

> If you have any idea about problem, like setting of TOMCAT,
> could you tell me the solution ?
Set MAKE_MY_PROBLEM_GO_AWAY=true in your startup script.  ;-> 

Your question really belongs on the user list, not dev. 

Your best piece of debugging would be to use stack traces (search Google
or Javasoft's site for info on generating JVM stack traces on demand) on
the hung JVM to find out where the problem is.  For the tiny bit of info
you've provided below, no one can tell you whether there's a bug in your
code (like a memory leak or thread deadlock or starvation from improper
use of database connections), your environment, or Tomcat. 

Some advice from experience: upgrade to Tomcat 3.3.1.  I can tell you
that 3.2.4 (which is the latest of the 3.2.x series) performs about 20%
slower than 3.3.1, and also has some bugs that affect reliability and
scalability under load.  While you're at it, upgrade your JVM to
1.3.1_06 -- it seems to be the stablest in the line of 1.3.1 JVMs, at
least on Solaris (I see you're on Win32). Aside from that
recommendation, after you upgrade and if there's still a problem, get
some stack traces and more information and bring it to the tomcat-user
list.

Scott Stirling 

On Wed, 2002-11-13 at 03:33, Sanjay Kashyap wrote: 
> Environment  is following
> 
> Server:NT4 sp6
> jdk1.3.1
> tomcat3.2.3
> 
> My system has been using Oracle8.1.7 IIS4.0 and  Javamail1.2,
> but tomcat suddenly stops one time a day these days.
> When it's stopped, if try to connect to URL, it says "Page is not found".
> Without rebooting the tomcat, it will be connected URL correctly after few
> minute later.
> If you have any idea about problem, like setting of TOMCAT,
> could you tell me the solution ?
> 
> Thanks


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

tomcat suddenly stops

[Sanjay Kashyap]

Environment  is following
(B
(BServer:NT4 sp6
(Bjdk1.3.1
(Btomcat3.2.3
(B
(BMy system has been using Oracle8.1.7 IIS4.0 and  Javamail1.2,
(Bbut tomcat suddenly stops one time a day these days.
(BWhen it's stopped, if try to connect to URL, it says "Page is not found".
(BWithout rebooting the tomcat, it will be connected URL correctly after few
(Bminute later.
(BIf you have any idea about problem, like setting of TOMCAT,
(Bcould you tell me the solution ?
(B
(BThanks

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

[Remy Maucherat]

[EMAIL PROTECTED] wrote:


glenn   2002/11/12 18:23:11

  Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java StandardContext.java
   catalina/src/share/org/apache/naming ContextBindings.java
  Log:
  Bug fix for BUG #13364

  A Web Application Context reload by the manager web application
  was causing named JNDI resources to disappear.

  A webapp reload needs to dump the webapp classloader, then
  recreate. The CL is bound to the naming context so the
  reload was issing a NamingContext STOP_EVENT and then a
  START_EVENT.  This removed all the JNDI named resources
  but the code which runs at webapp startup which creates
  the JNDI named resources is not run on a reload.

  I fixed this by removing the START and STOP events and
  adding BEFORE_STOP_EVENT and AFTER_START_EVENT
  lifecycle events whose only purpose is to bind or unbind the
  ClassLoader to the JNDI context.



This fix seems incorrect to me. The naming context must be destroyed, as 
the references which are bound in it have been created by the old 
classloader.

The NamingResources object is supposed to contain all the necessary data 
to recrate the JNDI context. The question, and what I was planning to 
investigate, is why it doesn't work. I think it did in the past.

I'll revert this patch when I find a better fix for the bug.

Remy


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