Xalan Tomcat: sealing violation

[Robert Petersen]

First - I may have posted this to the wrong list, if so please let me know a more 
appropriate place to post this.

I think there is a bug in the way Tomcat (or the JVM) handles class loading of 
classes.  The problem is this, I have a servlet (filter actually) that attempts to do 
some XSLT transformations.  When the filter tries to get a TransformerFactory a 
security exception is thrown, java.lang.SecurityException: sealing violation.  (The 
entire stack trace is at the bottom)
The root of the problem is when the class loader is trying to load a 
org.xml.sax.SAXException.  The resource is correct in that the code source url 
returned is "file:C:/Program Files/Apache 
Group/tomcat/webapps/jdst/WEB-INF/lib/xalan.jar"  the is the xalan.jar file bundled 
with my webapp.  The problem arises when the class loader tries to get the package 
with a call to "getPackage(pkgname);"  The class loader doesn't have this package and 
asks it's parent to see if it can find the package, and sure enough the parent has a 
package object from org.xml.sax.  The problem is this package was loaded earlier and 
it's url is "file:C:/Program Files/Apache Group/tomcat/lib/crimson.jar", so when the 
class loader is checking if the package is sealed it compares the two urls, finds they 
are not the same and throws the exception.  

A big assumption I have is that what I am doing is legal, I assume that the intention 
of the class loading systems is so that the base tomcat code can access it's classes 
with out worry, using whatever version of the classes it likes and that web apps can 
load their own version of classes without effecting the behavior of tomcat or other 
web apps.  Is this correct?

Now you can avoid this problem simply by not asking the package if it is sealed 
against the code source url.  Is this safe?

If you do that though another sort of configuration separation problem happens, in the 
crimson.jar file the property "javax.xml.parsers.DocumentBuilderFactory" is set to 
"org.apache.crimson.jaxp.DocumentBuilderFactoryImpl", so if I ask for a new 
TransformerFactory then I get an instance of 
"org.apache.crimson.jaxp.DocumentBuilderFactoryImpl", if I don't want that type of 
object I can set the property to my own class, e.g. 
"org.apache.xalan.processor.TransformerFactoryImpl" but now all the other web apps are 
forced to deal with my class.  Worse yet, some other webapp could come along and 
switch the property on me.  So it appears that there is no sort of "configuration 
layering" which I think is a problem.

Any help would be appreciated.

Thanks,
Robert Petersen

Stack Trace:
java.lang.SecurityException: sealing violation
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:217)
at 
org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:648)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:987)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:906)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at com.orangefood.xsltfilter.Filter.doFilter(Filter.java:40)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)

2 web app

[Oren Deri, Nice-Eye]

Hi,
I put 2 web apps on the same tomcat(under apache).
App1 is defualt and App2 isn't.
when tring reference App2 from App1 the page not fount.
in App1 I write: http//:App2IP/App2Name/test.jsp
and get the error - page not found.
-
Oren Deri
Cellular: 972-53-79
Mail: [EMAIL PROTECTED]
--

Re: mod_webapp status?

[Punky Tse]

Henri,

To see if APR could run on AS/400, you just need to download the
Apache2.0alpha drop and build it.  If the httpd could run properly than APR
works on AS/400!

Have fun!

Punky

- Original Message -
From: "GOMEZ Henri" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 26, 2001 3:27 PM
Subject: RE: mod_webapp status?


I subscribed to apr-list to start learning more on APR.
Having a cross system IO portable library is really a good
thing.

I'm also working on AS/400 and if APR could run on this
OS it will be a very good thing for my works developpements.
May be something to investigate since AS/400 is really very
posix (may be the most posix implementation I ever see).

:)

Si la fortune vient en dormant, a n'empche pas les emmerdements de venir
au rveil.
-- Pierre Dac

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 7:00 PM
To: [EMAIL PROTECTED]
Subject: RE: mod_webapp status?


On Fri, 23 Mar 2001, GOMEZ Henri wrote:

 Since mod_jk is using just a few APR-like functions, the transition
 woulnd't be difficult - but it's important to do it at the
right time.
 
 And IMHO that should come as a decision from tomcat-dev - I
would feel
 very bad if Henri or Dan would decide to switch to APR without
 a serious  discussion on tomcat-dev.

 Don't worry, I never said I'll modify mod_jk to use APR, and I
 didn't remember Dan speak about it. We're correcting the remaining
 bugs.

Henri, I didn't said I'm worried that you would modify mod_jk
to APR, but
do so without discussing it on tomcat-dev.

I think APR is clearly the future for mod_jk, and that was the original
intention ( as I remember from the old discussions ).


 You may read the various discussions between I and Dan about mod_jk
 and everybody known what we're doing.

And that's more important than the code itself - the fact that
we are all
involved and can give feedback.

Costin

RE: mod_webapp status?

[GOMEZ Henri]

To see if APR could run on AS/400, you just need to download the
Apache2.0alpha drop and build it.  If the httpd could run 
properly than APR works on AS/400!

I've take a look at APR and there is no reference to AS/400.
There is nothing related to OS/400 in config.guess.

AS/400 is a very different system. 
For example, Make didn't exist natively ;-)

There is a port of some gnu tools, maybe 

RE: Xalan Tomcat: sealing violation

[Kevin Jones]

Robert,

this is a well known issue that is being worked on. Check back on the list
over the last couple of days for another discussion of this :-)

Kevin Jones
DevelopMentor
www.develop.com

 -Original Message-
 From: Robert Petersen [mailto:[EMAIL PROTECTED]]
 Sent: 26 March 2001 11:20
 To: [EMAIL PROTECTED]
 Subject: Xalan  Tomcat: sealing violation


 First - I may have posted this to the wrong list, if so please
 let me know a more appropriate place to post this.

 I think there is a bug in the way Tomcat (or the JVM) handles
 class loading of classes.  The problem is this, I have a servlet
 (filter actually) that attempts to do some XSLT transformations.
 When the filter tries to get a TransformerFactory a security
 exception is thrown, java.lang.SecurityException: sealing
 violation.  (The entire stack trace is at the bottom)
 The root of the problem is when the class loader is trying to
 load a org.xml.sax.SAXException.  The resource is correct in that
 the code source url returned is "file:C:/Program Files/Apache
 Group/tomcat/webapps/jdst/WEB-INF/lib/xalan.jar"  the is the
 xalan.jar file bundled with my webapp.  The problem arises when
 the class loader tries to get the package with a call to
 "getPackage(pkgname);"  The class loader doesn't have this
 package and asks it's parent to see if it can find the package,
 and sure enough the parent has a package object from org.xml.sax.
  The problem is this package was loaded earlier and it's url is
 "file:C:/Program Files/Apache Group/tomcat/lib/crimson.jar", so
 when the class loader is checking if the package is sealed it
 compares the two urls, finds they are not the same and throws the
 exception.

 A big assumption I have is that what I am doing is legal, I
 assume that the intention of the class loading systems is so that
 the base tomcat code can access it's classes with out worry,
 using whatever version of the classes it likes and that web apps
 can load their own version of classes without effecting the
 behavior of tomcat or other web apps.  Is this correct?

 Now you can avoid this problem simply by not asking the package
 if it is sealed against the code source url.  Is this safe?

 If you do that though another sort of configuration separation
 problem happens, in the crimson.jar file the property
 "javax.xml.parsers.DocumentBuilderFactory" is set to
 "org.apache.crimson.jaxp.DocumentBuilderFactoryImpl", so if I ask
 for a new TransformerFactory then I get an instance of
 "org.apache.crimson.jaxp.DocumentBuilderFactoryImpl", if I don't
 want that type of object I can set the property to my own class,
 e.g. "org.apache.xalan.processor.TransformerFactoryImpl" but now
 all the other web apps are forced to deal with my class.  Worse
 yet, some other webapp could come along and switch the property
 on me.  So it appears that there is no sort of "configuration
 layering" which I think is a problem.

 Any help would be appreciated.

 Thanks,
 Robert Petersen

 Stack Trace:
 java.lang.SecurityException: sealing violation
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
   at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:217)
   at
 org.apache.catalina.loader.StandardClassLoader.findClass(StandardC
 lassLoader.java:648)
   at
 org.apache.catalina.loader.StandardClassLoader.loadClass(StandardC
 lassLoader.java:987)
   at
 org.apache.catalina.loader.StandardClassLoader.loadClass(StandardC
 lassLoader.java:906)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
   at com.orangefood.xsltfilter.Filter.doFilter(Filter.java:40)
   at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
onFilterChain.java:180)
   at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
 erValve.java:251)
   at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
   at
 org.apache.catalina.core.StandardContextValve.invoke(StandardConte
 xtValve.java:196)
   at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
   at
 org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
   at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv
 e.java:161)
   at
 org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
   at
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
   at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
   at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine
 Valve.java:159)
   at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
   at
 org.apache.catalina.connector.http.HttpProcessor.process(HttpProce
 ssor.java:818)
   at
 

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[GOMEZ Henri]

Could you send us the pushlet code example.
I could help here (mod_jk) :-)

"Entre truands, les bnfices, a se partage, la rclusion, a
s'additionne."
-- Michel Audiard
 

-Original Message-
From: Jestin Jean-Francois 
[mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 4:01 PM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: apache 1.3.12 and tomcat 3.3-m2 connection problem ??


Hello,

I'm currently using apache 1.3.12(mod_jk) and tomcat 3.3-m2 
under solaris 2.6 talking ajp13

Everything works fine except that I encounter sometime an 
Internal Server Error if I don't restart Apache each time I 
restart tomcat. Is there a fix for that problem ?

On the other hand I use a server push mechanism (called 
pushlet) - that's why I use milestone build of 3.3 (not 
working under 3.2.1)- it works also fine (what a beautiful 
life !) except that sometime (!!??) the servlet (pushlet) 
doesn't detect the end of the connection (Browser killed) 
between tomcat and apache

looking at the mod_jk log gives the following :

[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
jk_tcp_socket_recvfull failed
[jk_ajp13_worker.c (623)]: Error reading request
[jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
jk_tcp_socket_recvfull failed
[jk_ajp13_worker.c (623)]: Error reading request
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed

Is there also a fix for that or these problems ?

Thank you very for your answer and your great job !



Jean-Franois JESTIN

apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[Jestin Jean-Francois]

Hello,

I'm currently using apache 1.3.12(mod_jk) and tomcat 3.3-m2 under solaris 2.6 talking 
ajp13

Everything works fine except that I encounter sometime an Internal Server Error if I 
don't restart Apache each time I restart tomcat. Is there a fix for that problem ?

On the other hand I use a server push mechanism (called pushlet) - that's why I use 
milestone build of 3.3 (not working under 3.2.1)- it works also fine (what a beautiful 
life !) except that sometime (!!??) the servlet (pushlet) doesn't detect the end of 
the connection (Browser killed) between tomcat and apache

looking at the mod_jk log gives the following :

[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull 
failed
[jk_ajp13_worker.c (623)]: Error reading request
[jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull 
failed
[jk_ajp13_worker.c (623)]: Error reading request
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
[jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed

Is there also a fix for that or these problems ?

Thank you very for your answer and your great job !



Jean-Franois JESTIN

Re: trouble compiling mod_jk.so

[Brian P Millett]

Pilho Kim wrote:

 Hi,

 Retry with Apache 1.3.14 or 1.3.17

 On Fri, 23 Mar 2001, Jim Yiu wrote:

 
  Hi,
I am trying to compile the Tomcat-Apache plugin for Solaris and am 
unsuccessful,, I
  am trying
  to follow the mod_jk faq but it does not explain what to do when there are compile
  errors.


[snip]

  apxs:Break: Command failed with rc=16711680
 
 
  I am running the apxs script from within the apache directory [path to
  apache]/apache/bin  and I have Perl 5.004_04 installed, i am using
  SunOS 5.7 with a SPARC station 20 ..
 
  Could someone point out the problem ?  Any help is appreciated.

The real problem here is that the apache supplied apxs is not correct.  You need to 
edit it and fix
the
$CFG_CFLAGS_SHLIB, $CFG_LD_SHLIB  $CFG_LDFLAGS_SHLIB variables as follows:

vlad: gdiff -Nu0 /var/tmp/bpm/apxs.~1~ /opt/apache/bin/apxs
--- /var/tmp/bpm/apxs.~1~   Fri Mar 16 09:29:33 2001
+++ /opt/apache/bin/apxsFri Mar 16 15:44:42 2001
@@ -77,3 +77,3 @@
-my $CFG_CFLAGS_SHLIB  = q();  # substituted via Makefile.tmpl
-my $CFG_LD_SHLIB  = q();  # substituted via Makefile.tmpl
-my $CFG_LDFLAGS_SHLIB = q(); # substituted via Makefile.tmpl
+my $CFG_CFLAGS_SHLIB  = q(-fPIC -DSHARED_MODULE);  # substituted via Makefile.tmpl
+my $CFG_LD_SHLIB  = q(ld);  # substituted via Makefile.tmpl
+my $CFG_LDFLAGS_SHLIB = q(-G); # substituted via Makefile.tmpl

--
Brian Millett
Enterprise Consulting Group   "Shifts in paradigms
(314) 205-9030   often cause nose bleeds."
[EMAIL PROTECTED]   Greg Glenn

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java

[melaquias]

melaquias01/03/26 06:47:58

  Modified:src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
  Log:
  Temporary(?) fix to stop crashes when creating a new Session in embedded use of 
Jasper (i.e. as standalone JspServlet ).  Problem may occur in other situations as 
well, I'm not sure.
  
  Problem:  When SimpleSessionStore.SimpleSessionManager.getNewSession() is called (as 
a result of a call to request.getSession(), the session ID of the new session has not 
been set.  Since it is implemented as a MessageBytes object, the .toString() method to 
get a string representation of the session id returns null.  When getNewSession() 
tries to use this value as a key into the sessions hashtable, a NullPointerException 
is thrown.
  
  Fix:  To stop the crashing, I've added a line to "getNewSession()" to replace a null 
value for the string representation with the literal "null".  This should NOTbe 
considered a fix of the underlying problem:  Why is newId == null (i.e. why is the new 
session's id not initialized)?  The implication is that request.getSession() is broken 
in jasper right now, at least when using Jasper independent of tomcat.
  
  Revision  ChangesPath
  1.15  +5 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
  
  Index: SimpleSessionStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- SimpleSessionStore.java   2001/03/23 02:24:36 1.14
  +++ SimpleSessionStore.java   2001/03/26 14:47:58 1.15
  @@ -337,6 +337,11 @@
// The id will be set by one of the modules
String newId=session.getId().toString();

  +//X - the following is a temporary fix only!  Underlying problem
  +//is:  Why is the newId==null?
  +
  + newId=(newId==null)?"null":newId;
  + 
// What if the newId belongs to an existing session ?
// This shouldn't happen ( maybe we can try again ? )
ServerSession oldS=findSession( newId );
  @@ -344,7 +349,6 @@
// that's what the original code did
oldS.setState( ServerSession.STATE_EXPIRED );
}
  - 
sessions.put( newId, session );
return (session);
}
  
  
  

RE: Is Apache web server 1.3.x multithreaded

[Stubenrauch,Andreas]

This is a little bit offtopic for the tomcat-dev list so I'll answer
personally:
Apache 1.3.x ist a classic unix-fork apllication. To minimize the overhead
a park of processes is started at startuptime.
If running on Win32 these processes are mapped more or less on NT-Threads.

Apache 2.x is designed to bypass these Problems and can be configured to run
with
several different run-modes

Reagards,
Andreas

 -Original Message-
 From: chu luk [mailto:[EMAIL PROTECTED]]
 Sent: Friday, March 23, 2001 8:10 PM
 To: [EMAIL PROTECTED]
 Subject: Is Apache web server 1.3.x multithreaded
 
 
 Hi,
 Is Apache web server 1.3.x multithreaded?  that's each
 request and handle by a thread. OR each request is
 handle by a child process fork by parent?
 
 thanks.
 
 
 __
 Do You Yahoo!?
 Get email at your own domain with Yahoo! Mail. 
 http://personal.mail.yahoo.com/
 

Re: TC3.3 - building javadoc

[Arieh Markel]

 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 list-help: mailto:[EMAIL PROTECTED]
 list-unsubscribe: mailto:[EMAIL PROTECTED]
 list-post: mailto:[EMAIL PROTECTED]
 Delivered-To: mailing list [EMAIL PROTECTED]
 From: Mel Martinez [EMAIL PROTECTED]
 Subject: TC3.3 - building javadoc
 To: [EMAIL PROTECTED]
 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
 
 Currently, when you run the build script (for TC 3.3),
 build.xml has 'dist' dependent on the 'javadoc'
 target.  The 'javadoc' target compiles javadoc pages
 for org.apache.tomcat.core and
 org.apache.tomcat.modules.*.
 
 I dunno about you, but this seems insufficient for
 'dist'.  Shouldn't the javadoc set for distribution
 include all or most of the packages?  
 
 Also, it would probably be useful for dev
 documentation purposes to have some secondary javadoc
 targets like javadoc.tomcat.core',
 'javadoc.tomcat.util', 'javadoc.tomcat.modules',
 'javadoc.jasper', etc.  That way when you work on the
 javadocs for a package you can rapidly compile just
 that section.  This MIGHT encourage better documenting
 of code than is currently happening... :-)
 
 Anybody else think this is a good (or bad) idea?

I think this is a good idea.

Here is a snipped of a modified generatedocs.sh script that I built to
create the javadocs (it is not updated but a snapshot of 3.3 at the time):

javadoc -verbose -sourcepath src/share -d 
/ws/sx1.0-tools/jakarta/v3.2-4/dist/jakarta-tomcat/doc/api -use -version -author 
-windowtitle "Jakarta/Java Servlet API Reference, v2.2" -doctitle "Jakarta/Java 
Servlet API Reference, v2.2" \
javax.servlet \
javax.servlet.http \
javax.servlet.jsp \
javax.servlet.jsp.tagext \
org.apache.jasper \
org.apache.jasper.compiler \
org.apache.jasper.runtime \
org.apache.jasper.servlet \
org.apache.tomcat.context \
org.apache.tomcat.core \
org.apache.tomcat.helper \
org.apache.tomcat.logging \
org.apache.tomcat.modules.server \
org.apache.tomcat.request \
org.apache.tomcat.service \
org.apache.tomcat.service.connector \
org.apache.tomcat.service.http \
org.apache.tomcat.session \
org.apache.tomcat.startup \
org.apache.tomcat.task \
org.apache.tomcat.util \
org.apache.tomcat.util.depend \
org.apache.tomcat.util.net \
org.apache.tomcat.util.pattern \
org.apache.tomcat.util.threads \
org.apache.tomcat.util.xml 

(the package list need to be updated).

Arieh
 
 Mel
 
 
 __
 Do You Yahoo!?
 Get email at your own domain with Yahoo! Mail. 
 http://personal.mail.yahoo.com/

--
 Arieh Markel   Sun Microsystems Inc.
 Network Storage500 Eldorado Blvd. MS UBRM11-194
 e-mail: [EMAIL PROTECTED]   Broomfield, CO 80021
 Pray for snow  Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)

RE: TC3.3 - building javadoc

[GOMEZ Henri]

Currently, when you run the build script (for TC 3.3),
build.xml has 'dist' dependent on the 'javadoc'
target.  The 'javadoc' target compiles javadoc pages
for org.apache.tomcat.core and
org.apache.tomcat.modules.*.

I dunno about you, but this seems insufficient for
'dist'.  Shouldn't the javadoc set for distribution
include all or most of the packages?  

Also, it would probably be useful for dev
documentation purposes to have some secondary javadoc
targets like javadoc.tomcat.core',
'javadoc.tomcat.util', 'javadoc.tomcat.modules',
'javadoc.jasper', etc.  That way when you work on the
javadocs for a package you can rapidly compile just
that section.  This MIGHT encourage better documenting
of code than is currently happening... :-)

Anybody else think this is a good (or bad) idea?

+1 for build.xml 

I use ant dist in my RPM

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[Jestin Jean-Francois]

here are 2 articles speaking about the pushlet

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet-2.html

here is a very simple sample pushlet :


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

public class SimplePushlet extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)  
throws ServletException, IOException {

ObjectOutputStream out = new ObjectOutputStream (response.getOutputStream());
response.setContentType("text/plain");   

String start = "Http connection opened";

out.write(start.getBytes());
out.flush();
   
try {
for (int cnt=1; cnt  0; cnt++) {
Thread.sleep(1000);

String iter = "event=" + cnt + "\n";
out.write(iter.getBytes());
out.flush();
System.out.println("event=" + cnt + "pushed.\n");
}
} catch (Exception e) {
System.out.println("error:"+e);
}

out.close();
}
}

You may use netscape as browser or ie if you don't care about waiting 15 pushes.

Thank you for your help.







 -Original Message-
 From: Jestin Jean-Francois 
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 4:01 PM
 To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
 Subject: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
 
 
 Hello,
 
 I'm currently using apache 1.3.12(mod_jk) and tomcat 3.3-m2 
 under solaris 2.6 talking ajp13
 
 Everything works fine except that I encounter sometime an 
 Internal Server Error if I don't restart Apache each time I 
 restart tomcat. Is there a fix for that problem ?
 
 On the other hand I use a server push mechanism (called 
 pushlet) - that's why I use milestone build of 3.3 (not 
 working under 3.2.1)- it works also fine (what a beautiful 
 life !) except that sometime (!!??) the servlet (pushlet) 
 doesn't detect the end of the connection (Browser killed) 
 between tomcat and apache
 
 looking at the mod_jk log gives the following :
 
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
 jk_tcp_socket_recvfull failed
 [jk_ajp13_worker.c (623)]: Error reading request
 [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
 jk_tcp_socket_recvfull failed
 [jk_ajp13_worker.c (623)]: Error reading request
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - write failed
 
 Is there also a fix for that or these problems ?
 
 Thank you very for your answer and your great job !
 
 
 
 Jean-Fran ois JESTIN
 
 
 
 

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[GOMEZ Henri]

Hi,

I take a look at pushlet and find it very bad design.

Using opened http connections to do real-time job is
not realist.

In that case you keep an :

- one OS (job/thread)
- one ajp13 connection
- one tomcat thread.

Imagine if you got  256 concurrents connexions !

A better alternative will be to use a custom made network
protocol.

BTW, I'll see where the problem could be in mod_jk ;-)


"Entre truands, les bnfices, a se partage, la rclusion, a
s'additionne."
-- Michel Audiard
 

-Original Message-
From: Jestin Jean-Francois 
[mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 5:34 PM
To: '[EMAIL PROTECTED]'
Subject: RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??


here are 2 articles speaking about the pushlet

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet-2.html

here is a very simple sample pushlet :


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

public class SimplePushlet extends HttpServlet
{
public void doGet(HttpServletRequest request, 
HttpServletResponse response)  throws ServletException, IOException {

ObjectOutputStream out = new ObjectOutputStream 
(response.getOutputStream());
response.setContentType("text/plain");   

String start = "Http connection opened";

out.write(start.getBytes());
out.flush();
   
try {
for (int cnt=1; cnt  0; cnt++) {
Thread.sleep(1000);

String iter = "event=" + cnt + "\n";
out.write(iter.getBytes());
out.flush();
System.out.println("event=" + cnt + "pushed.\n");
}
} catch (Exception e) {
System.out.println("error:"+e);
}

out.close();
}
}

You may use netscape as browser or ie if you don't care about 
waiting 15 pushes.

Thank you for your help.







 -Original Message-
 From: Jestin Jean-Francois 
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 4:01 PM
 To: '[EMAIL PROTECTED]'; 
'[EMAIL PROTECTED]'
 Subject: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
 
 
 Hello,
 
 I'm currently using apache 1.3.12(mod_jk) and tomcat 3.3-m2 
 under solaris 2.6 talking ajp13
 
 Everything works fine except that I encounter sometime an 
 Internal Server Error if I don't restart Apache each time I 
 restart tomcat. Is there a fix for that problem ?
 
 On the other hand I use a server push mechanism (called 
 pushlet) - that's why I use milestone build of 3.3 (not 
 working under 3.2.1)- it works also fine (what a beautiful 
 life !) except that sometime (!!??) the servlet (pushlet) 
 doesn't detect the end of the connection (Browser killed) 
 between tomcat and apache
 
 looking at the mod_jk log gives the following :
 
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
 jk_tcp_socket_recvfull failed
 [jk_ajp13_worker.c (623)]: Error reading request
 [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
 jk_tcp_socket_recvfull failed
 [jk_ajp13_worker.c (623)]: Error reading request
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
write failed
 
 Is there also a fix for that or these problems ?
 
 Thank you very for your answer and your great job !
 
 
 
 Jean-Fran ois JESTIN
 
 
 
 

TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

As hinted at last week, I'd like to propose
refactoring some of the classes in Jasper to improve
the OO model a bit, make maintenance/extendability a
bit easier and hopefully help the performance a bit as
well for those of us using jasper as the JSP engine in
other servlet engines (other than tomcat, that is). 
There are problems with using the current Jasper in
other ServletEngines that do not show up with the
tomcat JspIntercepter that need to be addressed.

I'd like to refactor JspServlet, JspServletWrapper,
JasperLoader, JasperEngineContext and JasperCompiler
to better divide responsibilities along the following
lines:

JspServlet - entry point for JSP page (*.jsp),
initialize Jasper and maintain cache of jsp servlet
wrapper/handlers, otherwise do very little but pass on
the request to the handler.  I.E. represents the scope
of the jasper engine.  Possibly rename this to
JasperServlet or just 'Jasper'.

JspServletWrapper - rename as 'JspServlet/PageHandler'
(or similar) and make this a full class (i.e. take it
out of JspServlet).  This class manages the life cycle
of a single Jsp file, including methods to resolve
relevant file paths (i.e. to .jsp file, .java file,
.class file), package/class name mangling and
modification checking.  This class would be
responsible for managing dynamic reloading of an
out-of-date page.  Only one instance of this class is
created per page for the life JVM (or more accurately,
for the life of the JspServlet).

JspRequestWrapper/Handler/Context - encapsulate
information relevant to one request - this would
implement JspCompilationContext, since a compilation
would be one possible event during the request. 
However, we'd remove some of the current behavior in
JasperEngineContext that is really page-lifecycle
behavior that belongs in the JspServlet/PageHandler.  
 This class should be a lightweight information
payload used by the page handler, loader and compiler
for fullfillment of the request.  By reducing the
number of fields to only those that are
request-specific and possibly by object pooling, the
impact of instance creation (necessary for each
request) can be greatly reduced.

JasperLoader, Compiler, and a few other classes would
be refactored (actually simply extended slightly
through subclassing) to support these mods.  Some of
the current behavior would be refactored out to the
page life-cycle handler.  Compilers can probably be
pooled for reuse.

Along with the above class refactoring, we would add
recursive modification checking and dynamic reloading
to JspServlet, miscelaneous bug and performance fixes
(ex: mangled filename caching), and factory methods to
make it easier to  modify behavior by pluging in
replacement classes (such as the name mangler, loader
and compiler).  I'd like to improve the way classpaths
are handled to make things more apparent to the
developer using Jasper standalone how to set things
up.

The beauty of this is that this can all be done
without rewriting much if any of the existing code in
TC3.3. We can simply create a separate implementation
of JspServlet, called 'Jasper' (or JasperServlet or
whatever) or place the changes in a separate package
and thus folks working with the current version would
not be impacted by API changes.  We can then deprecate
the current classes gradually.

It is imporant to note that this proposed refactoring
would be to the standalone JspServlet page and request
life-cycle management.  This does not address any
possibly needed refactoring of the actual Jasper
compiler, which will remain the common element used by
all three entry points: JspInterceptor, the current
JspServlet and the proposed new jsp servlet.

Maintaining runtime compatibility with JspInterceptor
is, of course, mandatory.  No changes should cause
JspInterceptor to break.  Maintaining consistency with
JspInterceptor in terms of how it might do some
ancillary things (name mangling, caching
optimizations, classpath resolution etc.) should also
be desired, but not required since, after all,
JspInterceptor represents value-added for the tomcat
servlet engine.

To facilitate development, I can donate the bulk of
this as finished code I've already written that simply
needs to have appropriate package and class renaming
applied.

This proposal should be considered a rough draft.  I
need feedback, especially from others also using
Jasper as standalone in other servlet engines (such as
WebLogic Server, JRun, Jserv, etc.) on what problems
they'd like to see solved.  I'd also like suggestions
on whether to put this into a separate package in
Jasper (ex: org.apache.jasper.embedded) or to simply
insert it into the existing org.apache.jasper.servlet
package using new class names.  I think I'm in favor
of the latter approach.  I don't think there will be
much conflict or confusion with the approach I'd like
to take.

That said, I will have actually some time later this
week to actually implement most of this.  So feedback
now is better than feedback later.

Internal Server Errors while/after restarting Tomcat with mod_jk

[Jan Ploski]

Hi,

I have two questions regarding mod_jk's way of dealing with Tomcat
going away.

(1)

Can mod_jk be extended safely to retry connecting for a certain
time instead of immediately reporting an Internal Server Error if
a Tomcat process is temporarily unavailable? I have modified the
function jk_open_socket to do just that (keep trying for a minute
in 2 second intervals before giving up). However, I am not sure
if this is the correct place and whether it would have negative
side effects in some configurations (for example, I can imagine
that in a clustered setup, mod_jk should not wait for Tomcat to
recover, but fail over to another instance). Any ideas whether this
feature could be made optional or what a better place to implement
it would be?

The purpose of all that is to make Tomcat restarts (which are inevitable,
as we develop our applications; automatic class reloading doesn't always
do the trick) transparent to the web server.

(2)

I observed that stopping and restarting Tomcat while Apache with mod_jk
is running results in Internal Server Errors starting to appear randomly
in further requests. I guess that this is caused by mod_jk trying to
use a now dead Tomcat instance to service a request. However, I looked
into mod_jk code (jk_ajp13_worker.c) and it seems that it should attempt
reconnecting if it detects a bad socket. Perhaps it ought to also remove
the worker from its pool and fail over to the next available one instead
of spitting out an Internal Server Error. I am not sure because I don't
know how workers announce their presence to mod_jk and have not found
any tech docs for mod_jk besides of install/configuration issues.
Here is a snippet from the log illustrating what happens:

[jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker
[jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match 
ajp13
[jk_worker.c (123)]: Into wc_get_worker_for_name ajp13
[jk_worker.c (127)]: wc_get_worker_for_name, done  found a worker
[jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint
[jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service
[jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb
[jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done
[jk_ajp13_worker.c (606)]: Error sending request body
[jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done

Can someone confirm that restarting a Tomcat worker is unsupported by
mod_jk and will lead to problems? If so, could someone knowledgeable
in this code advise how to work around this problem or whether it would
be a major effort to implement a transparent failover? It seems silly
to restart Apache every time (one of) Tomcats needs to be reinitialized,
just for mod_jk's sake.

Thanks in advance for any hints.

-JPL

Custom tags: Request-time values unimplemented?

[rajeev]

Can someone confirm that request-time attribute values is not
implemented in the latest version of Jakarta?

Here's what I want to do:
  foo:bar customer="%= customer.getID() %"/

But instead of customer id, what actually gets passed to 
BarTag.setCustomer() is the string "%= customer.getID() %"

My code should have worked, based on sample code I saw in Sun's 
J2EE blueprints, and also here:
 http://java.sun.com/products/jsp/tutorial/TagLibraries6.html#62006


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

IIS redirector error handling

[Jens Mønster Sørensen]

Hi

We have been using JServ now Tomcat for some years now and are quite happy
about it. But alas some of our customers want thier stuff running on Win NT
or Win 2000, so we have also been using the IIS redirector.

And we have found it pretty unsatisfactory that when the tomcat/java process
for some reason dies, the only thing client recives is a broken connection
and no response. Which for instance by the MS Internet Explorer is
interpreted as a DNS error.

So we wanted to change the redirector to write some kind of configurable
response to the client before cutting the connection.

Without beeing an expert on IIS, it is my impression that IIS has a standard
way of handling this. For each site and its "virtual dirs" you can for each
http error code set up a response (a local file, a URI or a URL).

Therefore my first idea was to change the redirector to just set the error
code to 503 "Service Unavailable" when it failed to connect to the Tomcat
process, and thus utilising the IIS standard way of doing it. But I was not
able to get this working.

So instead I changed the redirector to read a new string value "error_uri"
from the "Jakarta Isapi Redirector/1.0" registry key (i.e. similar to the
"extension_uri" setting), and then send this URI to the client when it is
unable to connect to the Tomcat Process. I made the change in the
jk_isapi_plugin.c which I have attached to this mail.

It has been tested and works fine on Win 2000 Server.

I regretfully haven't got the time to get very much more involved than this,
and trust that sending this mail to the tomcat-dev list should be enough to
get this change proposal (or somthing similar to it) considered for addition
to the code-base.

Thanks in advance

/Jens


 jk_isapi_plugin.c

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

Hi Mel,

In my view, jasper is composed from at least 5 big components:

1. The jsp-java translator. 

2. The java-class compiler

3. The Mangler ( managing name mappings )

4. Runtime - that should be completely independent of all other pieces, 
since jasper-generated servlets should run without jasper ( as simple 
servlets ) 

5. Interface with the serlvet container ( JspServlet, JspInterceptor and
the associated classes). ( putting all other components togheter )

My understanding is that your proposal is related with (5), and it seems
it has the great property that it can be done as a proper refactoring -
without chaning any functionality, just by providing better communication
and code organization ( as the first stage ), and then by creating one
module ( that will eventually replace JspServlet ).

Since this is my favorite "modus operandis" I can't say anything than a
big +1...

There are few issues:

- Impact on 3.3 release cycle. I hate delaying it - it's clear we
need another milestone, but I believe in the "release early and often"
( and on schedule :-). I tried very hard to decouple the components as
much as possible, so development on any component shouldn't affect the
overall release ( and the rest of the code ). 

That would be resolved by your proposal to use a separate package name -
the new ( "in development mode" ) code can be developed in a proposal
space and released separately and be included in a 3.3.1 for example. 

I think keeping "old, stable" code in paralel with "new,
better" implementations and doing a gradual replacement is a very good
strategy ( AJP1.1 - AJP1.2 - Ajp1.3 - Ajp1.4, mod_jserv - mod_jk -
mod_jk+webapp,  facade22 - facade23, etc ).

- The other 4 components of jasper are also in a big need for a
refactoring. I think we'll see a lot of improvements in jsp-java
generation, and it would help a lot to be able to modularize it even more.

We clearly need a refactoring to allow you to plug the new JspServlet, and
we should extend it to at least the point where we cleanly separate the
components.

- Jasper 4. This will increase the divergence between jasper3 and jasper4. 
I spent some time trying to find a way to merge the 2, and I gave up
because of the current complexity. If a similar refactoring is done in
both sides ( since at least 90% of the code is still common ), and as
result of refactoring we can merge the common code in a set of common
components - then we might get more people involved and avoid a lot of
time waste. 

- Class loading and other interfacing problems. As I said many times, I
don't think JspServlet is the right way to plug jasper in a container, but
a richer interface exposing more of jasper. Having a working JspServlet
for quick-plugin is great, but I think we should rather focus on keeping
it just a small facade to a  better designed and more powerfull internal
API.  

In any case, a refactoring can only help, and you have my +1 ( i.e. I
think it's a good idea and I'll help !).

( BTW, I'm looking into an alternative/experimental implementation for the
jsp-java component, probably after 3.3 - as a standalone add-on
module. I have few ideas - but I want to first do a prototype )


Costin  


On Mon, 26 Mar 2001, Mel Martinez wrote:

 As hinted at last week, I'd like to propose
 refactoring some of the classes in Jasper to improve
 the OO model a bit, make maintenance/extendability a
 bit easier and hopefully help the performance a bit as
 well for those of us using jasper as the JSP engine in
 other servlet engines (other than tomcat, that is). 
 There are problems with using the current Jasper in
 other ServletEngines that do not show up with the
 tomcat JspIntercepter that need to be addressed.
 
 I'd like to refactor JspServlet, JspServletWrapper,
 JasperLoader, JasperEngineContext and JasperCompiler
 to better divide responsibilities along the following
 lines:
 
 JspServlet - entry point for JSP page (*.jsp),
 initialize Jasper and maintain cache of jsp servlet
 wrapper/handlers, otherwise do very little but pass on
 the request to the handler.  I.E. represents the scope
 of the jasper engine.  Possibly rename this to
 JasperServlet or just 'Jasper'.
 
 JspServletWrapper - rename as 'JspServlet/PageHandler'
 (or similar) and make this a full class (i.e. take it
 out of JspServlet).  This class manages the life cycle
 of a single Jsp file, including methods to resolve
 relevant file paths (i.e. to .jsp file, .java file,
 .class file), package/class name mangling and
 modification checking.  This class would be
 responsible for managing dynamic reloading of an
 out-of-date page.  Only one instance of this class is
 created per page for the life JVM (or more accurately,
 for the life of the JspServlet).
 
 JspRequestWrapper/Handler/Context - encapsulate
 information relevant to one request - this would
 implement JspCompilationContext, since a compilation
 would be one possible event during the request. 
 However, we'd remove some of the 

Re: Custom tags: Request-time values unimplemented?

[Craig R. McClanahan]

This question should really be addressed to the TOMCAT-USER
list.  TOMCAT-DEV is for discussions of the development of Tomcat itself.

On Sun, 25 Mar 2001, rajeev wrote:

 Can someone confirm that request-time attribute values is not
 implemented in the latest version of Jakarta?
 

Which version are you actually running.  "The latest version" is somewhat
ambiguous?

 Here's what I want to do:
   foo:bar customer="%= customer.getID() %"/
 
 But instead of customer id, what actually gets passed to 
 BarTag.setCustomer() is the string "%= customer.getID() %"
 

This should work fine in any version of Java, as long as you have declared
in your tag library descriptor that the "customer" attribute can accept
runtime expressions:

attribute
namecustomer/name
requiredfalse/required !-- or true if needed --
rtexprvaluetrue/rtexprvalue
/attribute

 My code should have worked, based on sample code I saw in Sun's 
 J2EE blueprints, and also here:
  http://java.sun.com/products/jsp/tutorial/TagLibraries6.html#62006
 

Craig McClanahan

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[Mel Martinez]

--- Jestin Jean-Francois
[EMAIL PROTECTED] wrote:
 here are 2 articles speaking about the pushlet
 

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html
 

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet-2.html
 
 here is a very simple sample pushlet :
 
 
 {
 public void doGet(HttpServletRequest request,
 HttpServletResponse response)  throws
 ServletException, IOException {
 
 ObjectOutputStream out = new
 ObjectOutputStream (response.getOutputStream());
 response.setContentType("text/plain");   
 
 String start = "Http connection opened";
 
 out.write(start.getBytes());
 out.flush();

 try {
 for (int cnt=1; cnt  0; cnt++) {
 Thread.sleep(1000);
 
 String iter = "event=" + cnt + "\n";
 out.write(iter.getBytes());
 out.flush();
 System.out.println("event=" + cnt +
 "pushed.\n");
 }
 } catch (Exception e) {
 System.out.println("error:"+e);
 }
 
 out.close();
 }
 }
 

This looks like a VERY bad idea - this will lock up a
connection to the server (and possibly a web server
process)!  This will definitely not scale well.  Also,
it is vulnerable to server crash, something likely to
happen if you had even a moderate amount of traffic
going to 'pushlets'.

It might be best to have the browser redirected over
to a separate, dedicated pushlet server (on a separate
box) for this.  I sure wouldn't want it sharing
resources with the rest of my 'normal' servlets.

NitPick: You should send error messages to System.err,
not System.out.  :-)

Cheers,

mel







__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

How do I use a non-apache naming service with tomcat 4?

[T. Park]

Hello,

I'm attempting to use an alternative naming service with tomcat 4.x and
running into some difficulties.
This may be a result of my lack of understanding on how to go about this
but please read on...


I start tomcat 4 with both -nonaming and -Dcatalina.useNaming=false
added as parameters to the catalina run batch procedure.

I have added my own naming jar files to the system class path.

When tomcat starts up it fails in StandardContext with the reflection
error complaining about the signature of the method
call "createNamingContext" (Follows later).

If I remove the jar file containing my naming support all works are
normal.

e.g.::

Exception during startup processing
java.lang.reflect.InvocationTargetException: java.lang.VerifyError:
(class: org/
apache/catalina/core/StandardContext, method: createNamingContext
signature: ()V
) Incompatible argument to function
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:120)
at
org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
at
org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)

at
org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91
)
at
org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter.ja
va:329)
at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1444)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1695)
at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1695)
at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1695)
at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1695)
at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461)
at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:499)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:304)
at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433)

at
org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223)

at javax.xml.parsers.SAXParser.parse(SAXParser.java:300)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:245)
at
org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228)
at org.apache.catalina.startup.Catalina.start(Catalina.java:625)

at
org.apache.catalina.startup.Catalina.execute(Catalina.java:595)
at
org.apache.catalina.startup.Catalina.process(Catalina.java:176)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:157)


I would have thought with naming disabled then the routine wouldn't be
called, however, I noticed a further
scary thing - there are references throughout StandardContext.java that
refer to the org.apache.naming service provider -

Is this part of the problem? Could it be that somehow the JVM is finding
references to the 'native' naming servive that conflict with the one I'm

trying to use and I'm getting burned.

If so how do I 'plug in' an alternative naming service to
org.apache.naming with tomcat 4?

-Thom

--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html

Re: How do I use a non-apache naming service with tomcat 4?

[Remy Maucherat]

- Original Message - 
From: "T. Park" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 26, 2001 11:07 AM
Subject: How do I use a non-apache naming service with tomcat 4?


 When tomcat starts up it fails in StandardContext with the reflection
 error complaining about the signature of the method
 call "createNamingContext" (Follows later).
 
 If I remove the jar file containing my naming support all works are
 normal.
 
 e.g.::
 
 Exception during startup processing
 java.lang.reflect.InvocationTargetException: java.lang.VerifyError:
 (class: org/
 apache/catalina/core/StandardContext, method: createNamingContext
 signature: ()V
 ) Incompatible argument to function
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:120)
 at
 org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
 at
 org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)

I can't figure out why createNamingContext() is invoked by the XML mapper.

Remy

Re: How do I use a non-apache naming service with tomcat 4?

[Craig R. McClanahan]

On Mon, 26 Mar 2001, Remy Maucherat wrote:

 - Original Message - 
 From: "T. Park" [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, March 26, 2001 11:07 AM
 Subject: How do I use a non-apache naming service with tomcat 4?
 
 
  When tomcat starts up it fails in StandardContext with the reflection
  error complaining about the signature of the method
  call "createNamingContext" (Follows later).
  
  If I remove the jar file containing my naming support all works are
  normal.
  
  e.g.::
  
  Exception during startup processing
  java.lang.reflect.InvocationTargetException: java.lang.VerifyError:
  (class: org/
  apache/catalina/core/StandardContext, method: createNamingContext
  signature: ()V
  ) Incompatible argument to function
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:120)
  at
  org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
  at
  org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)
 
 I can't figure out why createNamingContext() is invoked by the XML mapper.
 

The only way that would happen is if you set up a rule to call it.  Thom,
what rule is being executed when this happens?

 Remy
 
 

Craig

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpRequestBase.java

[craigmcc]

craigmcc01/03/26 12:02:17

  Modified:catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java
  Log:
  Correct the implementation of HttpServletRequest.isUserInRole() so that it
  properly respects role name aliases defined with security-role-ref.
  
  PR: Bugzilla #1086
  Submitted by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.18  +22 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java
  
  Index: HttpRequestBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- HttpRequestBase.java  2001/03/14 02:17:21 1.17
  +++ HttpRequestBase.java  2001/03/26 20:02:17 1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.17 2001/03/14 02:17:21 craigmcc Exp $
  - * $Revision: 1.17 $
  - * $Date: 2001/03/14 02:17:21 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.18 2001/03/26 20:02:17 craigmcc Exp $
  + * $Revision: 1.18 $
  + * $Date: 2001/03/26 20:02:17 $
*
* 
*
  @@ -100,7 +100,7 @@
* be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.17 $ $Date: 2001/03/14 02:17:21 $
  + * @version $Revision: 1.18 $ $Date: 2001/03/26 20:02:17 $
*/
   
   public class HttpRequestBase
  @@ -1135,20 +1135,30 @@
*/
   public boolean isUserInRole(String role) {
   
  -if (context == null)
  +// Have we got an authenticated principal at all?
  +if (userPrincipal == null)
   return (false);
  -
  - // Respect role name translations in the deployment descriptor
  - String realRole = context.findRoleMapping(role);
   
  - // Determine whether the current user has this role
  - if (userPrincipal == null)
  - return (false);
  +// Identify the Realm we will use for checking role assignmenets
  +if (context == null)
  +return (false);
Realm realm = context.getRealm();
if (realm == null)
return (false);
   
  - return (realm.hasRole(userPrincipal, realRole));
  +// See if this role is assigned directly to the authenticated user
  +if (realm.hasRole(userPrincipal, role))
  +return (true);
  +
  +// Map the specified role if it is an alias defined in a
  +// security-role-ref element
  +if (wrapper == null)
  +return (false);
  +String realRole = wrapper.findSecurityReference(role);
  +if (realRole != null)
  +return (realm.hasRole(userPrincipal, realRole));
  +else
  +return (false);
   
   }
   
  
  
  

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

[craigmcc]

craigmcc01/03/26 12:04:41

  Modified:tester/src/bin tester.xml
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester Authentication03.java
  Log:
  Add a new unit test to validate correct behavior of isUserInRole() for
  three circumstances:
  * Role name mapped directly to a user -- true
  * Role name specified in a security-role-ref element for a role name
mapped directly to a user -- true
  * Role name not mapped to a user -- false
  
  PR: Bugzilla #1086
  Submitted by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.24  +33 -22jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- tester.xml2001/03/21 20:28:24 1.23
  +++ tester.xml2001/03/26 20:04:37 1.24
  @@ -12,7 +12,7 @@
 taskdef  name="tester" classname="org.apache.tester.TestClient"/
   
   
  -  target name="all" 
depends="ROOT,CaseSensitive,ErrorPage,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest"/
  +  target name="all" 
depends="ROOT,Authentication,CaseSensitive,ErrorPage,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest"/
   
   
 target name="ROOT"
  @@ -37,6 +37,38 @@
 /target
   
   
  +  target name="Authentication"
  +
  +!-- == Authentication  --
  +
  +!-- Once a user has been authenticated, the corresponding user identity
  + should be visible to all other requests in this web application, even
  + for URIs that are not protected by security constraints.  This is
  + tested by invoking a protected URI followed by a non-protected URI
  +--
  +
  +tester host="${host}" port="${port}" protocol="${protocol}"
  +  debug="${debug}"
  + request="${context.path}/protected/Authentication01"
  +   inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
  +  outContent="Authentication01 PASSED"/
  +
  +tester host="${host}" port="${port}" protocol="${protocol}"
  +  debug="${debug}"
  + request="${context.path}/protected/Authentication02"
  +   inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
  +  outContent="Authentication02 PASSED"/
  +
  +!-- Test isUserInRole() on actual role and on an alias --
  +tester host="${host}" port="${port}" protocol="${protocol}"
  +  debug="${debug}"
  + request="${context.path}/protected/Authentication03"
  +   inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
  +  outContent="Authentication03 PASSED"/
  +
  +  /target
  +
  +
 target name="CaseSensitive"
   
   !-- == Case Sensitive Request URI Matching === --
  @@ -489,27 +521,6 @@
   tester host="${host}" port="${port}" protocol="${protocol}"
request="${context.path}/WrappedGetInputStream01" debug="${debug}"
 outContent="GetInputStream01 PASSED"/
  -
  -
  -!-- == Authentication  --
  -
  -!-- Once a user has been authenticated, the corresponding user identity
  - should be visible to all other requests in this web application, even
  - for URIs that are not protected by security constraints.  This is
  - tested by invoking a protected URI followed by a non-protected URI
  ---
  -
  -tester host="${host}" port="${port}" protocol="${protocol}"
  -  debug="${debug}"
  - request="${context.path}/protected/Authentication01"
  -   inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
  -  outContent="Authentication01 PASSED"/
  -
  -tester host="${host}" port="${port}" protocol="${protocol}"
  -  debug="${debug}"
  - request="${context.path}/protected/Authentication02"
  -   inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
  -  outContent="Authentication02 PASSED"/
   
   
 /target
  
  
  
  1.1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Authentication03.java
  
  Index: Authentication03.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999, 2000, 2001  The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * 

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/sessionSimpleSessionStore.java

[cmanolache]

   Temporary(?) fix to stop crashes when creating a new Session in
 embedded use of Jasper (i.e. as standalone JspServlet ).  Problem may
 occur in other situations as well, I'm not sure.
   
   Problem:  When
 SimpleSessionStore.SimpleSessionManager.getNewSession() is called (as a
 result of a call to request.getSession(), the session ID of the new
 session has not been set.  Since it is implemented as a MessageBytes

Hi Mel, 

I looked at that and I couldn't reproduce it - are you sure you have the 
right configuration ( i.e. SessionIdGenerator included in server.xml ) ?

getNewSession is calling setState( STATE_NEW ), that calls the
sessionState callback that allows modules to initialize the new session
object - and SessionIdGenerator is setting the id ( using whatever
random). 

I can't understand what's wrong - my only guess is that SessionIdGenerator
is not included.

I didn't had too much time this weekend ( to restart the nightly tests ),
but I hope to resolve those issues soon.

Costin



 object, the .toString() method to get a string representation of the
 session id returns null.  When getNewSession() tries to use this value
 as a key into the sessions hashtable, a NullPointerException is thrown.

cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/security/protected index.jsp

[craigmcc]

craigmcc01/03/26 12:50:48

  Modified:webapps/examples/jsp/security/protected index.jsp
  Log:
  Explicitly identify the destination of the form submit, so that this page
  works correctly when used in a form-based login environment.
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-tomcat-4.0/webapps/examples/jsp/security/protected/index.jsp
  
  Index: index.jsp
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/security/protected/index.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.jsp 2000/08/17 00:58:17 1.1
  +++ index.jsp 2001/03/26 20:50:47 1.2
  @@ -37,7 +37,7 @@
   
   To check whether your username has been granted a particular role,
   enter it here:
  -form method="GET"
  +form method="GET" action="index.jsp"
   input type="text" name="role" value="%= role %"
   /form
   
  
  
  

RE: Internal Server Errors while/after restarting Tomcat with mod_jk

[GOMEZ Henri]

Jan,

Henri Gomez is working on a patch to solve this very problem 
as we speak --
he is setting it up so that the mod_jk plugin will detect that 
TC has died,
and will attempt to open new connections.

Hopefully, that will be testable within a week or two...

-Dan


Just sent to list ;)

Re: ajp13 and tomcat restart - next (final) release

[Dan Milstein]

Henri (+ Larry),

Looks about ready for more general testing.  I like the new
ajp13_operation.  Two things:

 1) l. 672 (op-recoverable = JK_FALSE).

I believe that should be outside of the if statement (i.e. immediately after
the connection_tcp_send_message).  The whole thing becomes unrecoverable as
soon as the 2nd buffer of data gets sent over to TC (at line 669), not just
if there was an error during that send.  


 2) Larry -- what's your feeling about putting this in the next 3.3
milestone?  It's certainly a very heavily requested feature, but I wouldn't
want to swear to its correctness/robustness just yet. 

-Dan

GOMEZ Henri wrote:
 
 Hi,
 
 You could find here the latest patch for ajp13/mod_jk
 when tc is restarted.
 
 Seems fine and ready to be commited.
 
 PS: I'll add timestamp in mod_jk logs but I'd like
 also to remove the datasync in log since it's just
 to much I/O consuming in debug mode (Ok ?)
 
   
  Name: jk_ajp13_worker.c.diff
jk_ajp13_worker.c.diffType: unspecified type (application/octet-stream)
  Encoding: quoted-printable

-- 

Dan Milstein // [EMAIL PROTECTED]

RE: ajp13 and tomcat restart - next (final) release

[GOMEZ Henri]

Henri (+ Larry),

Looks about ready for more general testing.  I like the new
ajp13_operation.  Two things:

 1) l. 672 (op-recoverable = JK_FALSE).

I'll check that.

I believe that should be outside of the if statement (i.e. 
immediately after
the connection_tcp_send_message).  The whole thing becomes 
unrecoverable as
soon as the 2nd buffer of data gets sent over to TC (at line 
669), not just
if there was an error during that send.  

Ok


 2) Larry -- what's your feeling about putting this in the next 3.3
milestone?  It's certainly a very heavily requested feature, 
but I wouldn't
want to swear to its correctness/robustness just yet. 

I'd like to have it in m3. After all mx are also here to test fixes.
All in one the previous code was seriously damaged.
I strongly think we must commit it to have report on it and fixes
before beta 1.

RE: ajp13 and tomcat restart - next (final) release

[Larry Isaacs]

I don't anticipate a TC3.3 Milestone 3 this week.  Maybe
next week.  I'm okay to commit it since there will some
time before TC 3.3 Beta 1.  We can review then whether
it is working well enough to be kept for Beta 1.

Larry

 -Original Message-
 From: Dan Milstein [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 4:05 PM
 To: [EMAIL PROTECTED]
 Subject: Re: ajp13 and tomcat restart - next (final) release
 
 
 Henri (+ Larry),
 
 Looks about ready for more general testing.  I like the new
 ajp13_operation.  Two things:
 
  1) l. 672 (op-recoverable = JK_FALSE).
 
 I believe that should be outside of the if statement (i.e. 
 immediately after
 the connection_tcp_send_message).  The whole thing becomes 
 unrecoverable as
 soon as the 2nd buffer of data gets sent over to TC (at line 
 669), not just
 if there was an error during that send.  
 
 
  2) Larry -- what's your feeling about putting this in the next 3.3
 milestone?  It's certainly a very heavily requested feature, 
 but I wouldn't
 want to swear to its correctness/robustness just yet. 
 
 -Dan
 
 GOMEZ Henri wrote:
  
  Hi,
  
  You could find here the latest patch for ajp13/mod_jk
  when tc is restarted.
  
  Seems fine and ready to be commited.
  
  PS: I'll add timestamp in mod_jk logs but I'd like
  also to remove the datasync in log since it's just
  to much I/O consuming in debug mode (Ok ?)
  

 --
 --
   Name: jk_ajp13_worker.c.diff
 jk_ajp13_worker.c.diffType: unspecified type 
 (application/octet-stream)
   Encoding: quoted-printable
 
 -- 
 
 Dan Milstein // [EMAIL PROTECTED]
 

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 1:08 PM
 To: [EMAIL PROTECTED]
 Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
 
 
 Hi Mel,
 
 In my view, jasper is composed from at least 5 big components:
 
 1. The jsp-java translator. 
 
 2. The java-class compiler
 
 3. The Mangler ( managing name mappings )
 
 4. Runtime - that should be completely independent of all 
 other pieces, 
 since jasper-generated servlets should run without jasper ( as simple 
 servlets ) 
 
 5. Interface with the serlvet container ( JspServlet, 
 JspInterceptor and
 the associated classes). ( putting all other components togheter )
 

Layer 5 has to include the JspC/CommandLineXXX components, also. They have
to provide an environment that looks to the rest of the JSP compiler like a
web context, while actually interacting more closely with the filesystem. 

Mangler needs some work, too. JspC and JspServlet have drifted in their
implementations. The bane of code sharing by cut and paste.


This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. 

JDBC-Session store

[Bip Thelin]

According to the STATUS.html(which doesn't seem to be up to date) no one seems
to have volunteered for the JDBC-Session store. If that is truly the case I
would like to volunteer for that part.

Thanks, Bip

RE: ajp13 and tomcat restart - next (final) release + AJ13 PROPOSAL

[GOMEZ Henri]

Looks about ready for more general testing.  I like the new
ajp13_operation.  Two things:

 1) l. 648 (op-recoverable = JK_FALSE).


I set op-recoverable to JK_FALSE just after  
detected upload mode (dropped var)

Find included the latest .c since I miss diff cmd
under W2K rigth now.

Where could we put code in Ajp13Interceptor which
could be informed of context load/unload ?

I'd like to add context/webapp load/unload 
 la mod_warp :)

will be new cmds in JK :

LOADEDCONTEXT + WEBAPP STRING
#define JK_AJP13_LOADED_CONTEXT   (unsigned char)8

UNLOADEDCONTEXT + WEBAPP STRING
#define JK_AJP13_UNLOADED_CONTEXT (unsigned char)9

Another proposal Strongest ACL 
(LOGIN + SECRET STRING + PROTOCOL SETS)
#define JK_AJP13_LOGIN  (unsigned char)10

Comments ?



 jk_ajp13_worker.c

Re: Multi-Byte character support.

[tttye]

I have helped work on a fix for this on 4.0 (which supports the
javax.servlet.ServletRequest.setCharacterEncoding() method).  Tomcat 3.x
does not support the new servlet 2.3 methods, so I did not look at fixing
it in Tomcat.
However, I have an easy to use object (included) which is able to process
the mangled string and convert it to the encoding that you specify.
This method will work for all Strings parsed into Tomcat (or other web
servers). 
Tim Tye


T. Park writes:

 
 Greetings,
 
 
 Tomcat 3.2[.1] doesn't seem to like static html pages (or servlets for
 that matter) that offer multi-byte (non-latin) characters.
 
 Has anyone coded a patch to fix this and/or have a workaround for the
 issue.
 
 I'd rather avoid having to re-invent the wheel.
 
 Does anyone have any insights as to how big a problem this is to fix?
 
 
 Cheers,
 
 Thom
 
 --
 http://www.borland.com/newsgroups
 http://www.borland.com/devsupport/disclaim.html
 
 




 ChangeStringEncoding.java

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

 1.  In general the Java SecurityManager implemenation in Tomcat 4
 and Jasper has significant improvements and is much cleaner.

True. The SecurityManager in 3.3 is working fine for now ( Glenn is also
the main author for the 3.x sandboxing ), with all watchdog passing - but
a refactoring will help cleaning up the code.

 2.  Jasper class loading is much simpler in the Tomcat 4 version.
 It uses a single URLClassLoader for each JSP page, this allowed
 me to simplify a great deal how Jasper handles generation of class
 and package names (no more need to do incremental .java and .class files).
 And it removed alot of overhead at both JSP translation and runtime
 when Jasper tries to figure out which incremental class file to use/check.
 This sped up JSP compiles by 33% and runtime execution by 25%.

Well, I have to disagree here :-) It is indeed much simpler than the  3.2
jsp class loading, and using URLClassLoader is a step in the right
direction.

Tomcat 3.3 is also using URLClassLoader ( for everything - except the
JDK1.1 replacement that has the same interface and replicates
URLClassLoader ). 

I would say the incremental .java is not a bad idea, and the code to
support that is reasonably simple ( and provide some unique benefits
related with reloading and avoiding some special cases ) - it should be
trivial to make it optional ( if anyone feel the need ). 

We don't use a class loader per jsp page ( since it isn't needed - given
the versioning ), but again it would be easy to add it.

In any case - at least the class loading is just fine in 3.3, no need to
fix it ( but I think everyone would be happy to have more options - like
what you mention about one class loader per jsp and no versioning - as
long as this is not mandatory and doesn't replace the other scheme ). 


 And before you ask, I just don't have the time to back port these
 changes in TC3.3.

Well, it would help a lot if you could at least take a look and review the
sandboxing for 3.3 :-) Security and sandboxing are very difficult, and you
probably have the most experience with that.

On a related issue, I would be very interested in re-commiting some of the
original patches ( defining the permissions in server.xml in addition to
the policy file ), this would help a lot in the future admin
interface. Again, we might need your help ( if you still have them
around ) :-)  

Costin

 
 Regards,
 
 Glenn
 
 Mel Martinez wrote:
  
  As hinted at last week, I'd like to propose
  refactoring some of the classes in Jasper to improve
  the OO model a bit, make maintenance/extendability a
  bit easier and hopefully help the performance a bit as
  well for those of us using jasper as the JSP engine in
  other servlet engines (other than tomcat, that is).
  There are problems with using the current Jasper in
  other ServletEngines that do not show up with the
  tomcat JspIntercepter that need to be addressed.
  
  I'd like to refactor JspServlet, JspServletWrapper,
  JasperLoader, JasperEngineContext and JasperCompiler
  to better divide responsibilities along the following
  lines:
  
  JspServlet - entry point for JSP page (*.jsp),
  initialize Jasper and maintain cache of jsp servlet
  wrapper/handlers, otherwise do very little but pass on
  the request to the handler.  I.E. represents the scope
  of the jasper engine.  Possibly rename this to
  JasperServlet or just 'Jasper'.
  
  JspServletWrapper - rename as 'JspServlet/PageHandler'
  (or similar) and make this a full class (i.e. take it
  out of JspServlet).  This class manages the life cycle
  of a single Jsp file, including methods to resolve
  relevant file paths (i.e. to .jsp file, .java file,
  .class file), package/class name mangling and
  modification checking.  This class would be
  responsible for managing dynamic reloading of an
  out-of-date page.  Only one instance of this class is
  created per page for the life JVM (or more accurately,
  for the life of the JspServlet).
  
  JspRequestWrapper/Handler/Context - encapsulate
  information relevant to one request - this would
  implement JspCompilationContext, since a compilation
  would be one possible event during the request.
  However, we'd remove some of the current behavior in
  JasperEngineContext that is really page-lifecycle
  behavior that belongs in the JspServlet/PageHandler.
   This class should be a lightweight information
  payload used by the page handler, loader and compiler
  for fullfillment of the request.  By reducing the
  number of fields to only those that are
  request-specific and possibly by object pooling, the
  impact of instance creation (necessary for each
  request) can be greatly reduced.
  
  JasperLoader, Compiler, and a few other classes would
  be refactored (actually simply extended slightly
  through subclassing) to support these mods.  Some of
  the current behavior would be refactored out to the
  page life-cycle handler.  Compilers can probably be
  pooled for reuse.
  
  Along with the 

Re: How do I use a non-apache naming service with tomcat 4?

[T. Park]

More info.
I pulled the routines I needed out of my 'big everything' jar file and
I can now get my jndi stuff to
work with tomcat4.
The problemi is that I still need to get the other stuff in that jar
file to play nice with tomcat.
but, for now, the problem looks to be in my camp.
Thanks for the support/encouragement.
-Thom
p.s. Odd error all the same don't you think?




--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html

cvs commit: jakarta-tomcat-4.0/catalina STATUS.html

[craigmcc]

craigmcc01/03/26 16:04:23

  Modified:catalina STATUS.html
  Log:
  Add Bip Thelin as a volunteer to work on the JDBC-based Store implementation.
  
  Revision  ChangesPath
  1.5   +2 -2  jakarta-tomcat-4.0/catalina/STATUS.html
  
  Index: STATUS.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/STATUS.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- STATUS.html   2000/12/07 05:15:08 1.4
  +++ STATUS.html   2001/03/27 00:04:22 1.5
  @@ -201,7 +201,7 @@
   td align="center"Medium/td
   tdDesign and implement a JDBC-based codeStore/code implementation.
   [org.apache.catalina.session]/td
  -td---/td
  +tda href="[EMAIL PROTECTED]"Bip Thelin/a/td
 /tr
 tr
   td align="center"Medium/td
  @@ -298,7 +298,7 @@
   
   br
   div align="center"hr width="75%"font size="2"
  -$Id: STATUS.html,v 1.4 2000/12/07 05:15:08 remm Exp $
  +$Id: STATUS.html,v 1.5 2001/03/27 00:04:22 craigmcc Exp $
   /font/div
   
   /body
  
  
  

Re: JDBC-Session store

[Craig R. McClanahan]

On Mon, 26 Mar 2001, Bip Thelin wrote:

 According to the STATUS.html(which doesn't seem to be up to date) no one seems
 to have volunteered for the JDBC-Session store. If that is truly the case I
 would like to volunteer for that part.
 
   Thanks, Bip
 

That is the case currently, so I have added you to the list.  Thanks for
volunteering!

Earlier, there was some discussion on refactoring the
Manager/Session/Store family of interfaces (and corresponding interface
classes) a little bit in the light of Kief's experience in adding
PersistentManager.  If you see things here that you think could be
improved, don't hesitate to suggest them.

Craig

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
Temporary(?) fix to stop crashes when creating a
 new Session in
  embedded use of Jasper (i.e. as standalone
 JspServlet ).  Problem may
  occur in other situations as well, I'm not sure.

 I looked at that and I couldn't reproduce it - are
 you sure you have the 
 right configuration ( i.e. SessionIdGenerator
 included in server.xml ) ?
 

No, SessionIdGenerator was not included, I have a
customized server.xml because I need to test both
jasper with tomcat and then jasper in weblogic (as
well as other reasons).  I'll update my server.xml and
I predict that will fix the problem.  I now see that
server.xml was beeing updated in my cvs logs, but
failed to account for the change in my own version.

However, this does point to the need for default
behavior of tomcat session generation code (or any
interceptor or module code) in the absence of expected
configuration info in server.xml.

Mel

 getNewSession is calling setState( STATE_NEW ), that
 calls the
 sessionState callback that allows modules to
 initialize the new session
 object - and SessionIdGenerator is setting the id (
 using whatever
 random). 
 
 I can't understand what's wrong - my only guess is
 that SessionIdGenerator
 is not included.
 
 I didn't had too much time this weekend ( to restart
 the nightly tests ),
 but I hope to resolve those issues soon.
 
 Costin
 
 
 
  object, the .toString() method to get a string
 representation of the
  session id returns null.  When getNewSession()
 tries to use this value
  as a key into the sessions hashtable, a
 NullPointerException is thrown.
 
 
 
 
 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/sessionSimpleSessionStore.java

[cmanolache]

 However, this does point to the need for default
 behavior of tomcat session generation code (or any
 interceptor or module code) in the absence of expected
 configuration info in server.xml.

That's a good point, but I'm wondering how could it be implemented.
The whole idea of modules is that each can be replaced with a better
version ( for example a more secure or more efficient scheme to generate
the ids ), so we can't just check for specific modules. 

Well, there is a solution ( I'm not sure how can we code it ) - have an
automated way to run watchdog and sanity to validate the config files. If
watchdog/sanity are passing  - then probably the config is valid :-)


Costin




 


 Mel
 
  getNewSession is calling setState( STATE_NEW ), that
  calls the
  sessionState callback that allows modules to
  initialize the new session
  object - and SessionIdGenerator is setting the id (
  using whatever
  random). 
  
  I can't understand what's wrong - my only guess is
  that SessionIdGenerator
  is not included.
  
  I didn't had too much time this weekend ( to restart
  the nightly tests ),
  but I hope to resolve those issues soon.
  
  Costin
  
  
  
   object, the .toString() method to get a string
  representation of the
   session id returns null.  When getNewSession()
  tries to use this value
   as a key into the sessions hashtable, a
  NullPointerException is thrown.
  
  
  
  
  
 
 
 __
 Do You Yahoo!?
 Get email at your own domain with Yahoo! Mail. 
 http://personal.mail.yahoo.com/
 

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

On Mon, 26 Mar 2001, Steve Downey wrote:

  1. The jsp-java translator. 
  
  2. The java-class compiler
  
  3. The Mangler ( managing name mappings )
  
  4. Runtime - that should be completely independent of all 
  other pieces, 
  since jasper-generated servlets should run without jasper ( as simple 
  servlets ) 
  
  5. Interface with the serlvet container ( JspServlet, 
  JspInterceptor and
  the associated classes). ( putting all other components togheter )
  
 
 Layer 5 has to include the JspC/CommandLineXXX components, also. They have
 to provide an environment that looks to the rest of the JSP compiler like a
 web context, while actually interacting more closely with the filesystem. 

Yes. In fact a lot from JspInterceptor is inspired/derived from JspC. 

But the JspC is very special because it can be use to pre-compile
applications - that would be great for special configurations or only the
jsp runtime is included ( say an embeded tomcat, or a minimal
environment).

It should be possible ( after a bit of refactoring ) to create a mini
distribution using only the core, a sub-set of the modules, jasper-runtime
( no xml parser or jasper converter or javac ), plus JspC-processed 
webapplications ( what's missing is a piece to serialize web.xml - for
server.xml there is EmbededTomcat, and it shouldn't be difficult to
automatically generate a java class that will have the same effect with
reading web.xml - maybe using serialization ).

I would bet on a result below 500K :-)
( most of the code is easy to port to J2ME, BTW - we just need
volunteers :-).


 Mangler needs some work, too. JspC and JspServlet have drifted in their
 implementations. The bane of code sharing by cut and paste.

Refactoring is the keyword :-) Merge what's duplicated, use the mistakes
to define better interfaces between components.

The mangler in 3.3 is slightly better ( forgive my lack of modesty here
), and I would also say the JspInterceptor is at least a simpler way to
plug jasper ( compared with JspServlet ).

Costin

Cause found [was Re: How do I use a non-apache naming service with tomcat 4?]

[T. Park]

Guys,

I've isolated the cause of the problem down to the inclusion of the javax.naming
package in my 'big everything' jar.
If I remove the javax.naming package from the jar file, then all works well, if
not, we get that wierd 'signature' problem with createNamingContext.
(with or without enabling naming).


Would it seem reasonable not to load naming support jars if tomcat isn't going
to be running a [native] naming service?

My problem here is I have a naming service I want to use and is packaged with
the corresponding javax.naming package that it is based on

the problem is that I'm unable (by default) to control what jndi stuff get's
stuffed on the classpath of tomcat

I'm unable to swap these (the naming support jars) around as tomcat's stuff
seems to have been compiled against a different rev of the javax.naming
stuff.


So - Do you know what version of javax.naming is in tomcat 4's jndi.jar?

I'm bundling the rev that came with j2ee 1.2.1

-Thom


--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html

Re: Cause found [was Re: How do I use a non-apache naming service with tomcat 4?]

[Remy Maucherat]

 Guys,

 I've isolated the cause of the problem down to the inclusion of the
javax.naming
 package in my 'big everything' jar.
 If I remove the javax.naming package from the jar file, then all works
well, if
 not, we get that wierd 'signature' problem with createNamingContext.
 (with or without enabling naming).


 Would it seem reasonable not to load naming support jars if tomcat isn't
going
 to be running a [native] naming service?

Which version of TC 4 are you using ?
I believe the latest nightly builds could fix those problems.

 My problem here is I have a naming service I want to use and is packaged
with
 the corresponding javax.naming package that it is based on

 the problem is that I'm unable (by default) to control what jndi stuff
get's
 stuffed on the classpath of tomcat

 I'm unable to swap these (the naming support jars) around as tomcat's
stuff
 seems to have been compiled against a different rev of the javax.naming
 stuff.


 So - Do you know what version of javax.naming is in tomcat 4's jndi.jar?

It's the same as yours, but loaded by a different classloader, so it's not
compatible anyway.

Remy

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

[craigmcc]

craigmcc01/03/26 17:54:20

  Modified:catalina/docs/dev classloaders.html
   catalina/src/share/org/apache/catalina/startup
Bootstrap.java
  Log:
  Rearrange the order in which repositories are added to each of the
  standard class loader so that the "classes" directory always overrides the
  corresponding "lib/*.jar" repositories.
  
  Revision  ChangesPath
  1.6   +25 -23jakarta-tomcat-4.0/catalina/docs/dev/classloaders.html
  
  Index: classloaders.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/dev/classloaders.html,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- classloaders.html 2001/02/23 02:32:20 1.5
  +++ classloaders.html 2001/03/27 01:54:19 1.6
  @@ -79,29 +79,31 @@
   (if present on your system)./li
   /ul
   listrongCommon/strong - This class loader is initialized to include all 
  -JAR files in the code$CATALINA_HOME/common/lib/code directory and
  -the code$CATALINA_HOME/common/classes/code directory if it exists.
  +unpacked classes in the code$CATALINA_HOME/common/classes/code
  +directory (if it exists), and all JAR files in the
  +code$CATALINA_HOME/common/lib/code directory (if it exists).  The
  +latter group normally includes the following:
   ul
  -licode$CATALINA_HOME/common/lib/servlet.jar/code - The servlet and
  -JSP API classes./li
  -licode$CATALIA_HOME/common/lib/naming.jar/code - The JNDI
  - implementation used by Tomcat 4, added only if you are running
  - in a JDK 1.2 environment (the JNDI classes are included in JDK
  - 1.3 or later)./li
  -/ul
  -listrongCatalina/strong - This class loader is initialized to include
  -all JAR files in the code$CATALINA_HOME/server/code directory, which
  -should contain Catalina itself (i.e. all classes whose fully qualified
  -names begin with codeorg.apache.catalina./code), and any JAR files
  -that it depends on and the code$CATALINA_HOME/server/classes/code
  -directory if it exists.  Because these classes are loaded from a separate
  -class loader, which is not visible to the strongWebapp/strong class
  -loader, they are emnot/em visible to web applications./li
  -listrongShared/strong - This class loader is initialized to include
  -all JAR files in the code$CATALINA_HOME/lib/code directory and the
  -code$CATALINA_HOME/classes/code directory if it exists.  All of
  -the classes in these repositories will be visible to all web applications,
  -so they may be used to share information between web apps
  +licodejndi.jar/code - The Java Naming and Directory Service API
  +classes (loaded strongonly/strong if not already included in
  +the JDK, as they are with JDK 1.3)./li
  +licodenaming.jar/code - The JNDI implementation used by
  +Tomcat 4 itself./li
  +licodeservlet.jar/code - The servlet and JSP API classes./li
  +/ul/li
  +listrongCatalina/strong - This class loader is initialized to include all
  +unpacked classes in the code$CATALINA_HOME/server/classes/code
  +directory (if it exists), and all JAR files in the
  +code$CATALINA_HOME/server/lib/code directory (if it exists).  Because
  +these classes are loaded from a separate class loader, which is not visible
  +to the strongWebapp/strong class loader, they are emnot/em visible
  +to web applications./li
  +listrongShared/strong - This class loader is initialized to include all
  +unpacked classes in the code$CATALINA_HOME/classes/code directory
  +(if it exists), and all JAR files in the code$CATALINA_HOME/lib/code
  +directory (if it exists).  All of the classes in these repositories will
  +be visible to all web applications, so they may be used to share
  +information between web apps.
   (strongNOTE/strong - this behavior is specific to Tomcat 4.0, and
   will not necessarily be portable to other containers.)/li
   listrongWebappX/strong - A class loader is created for each web
  @@ -249,7 +251,7 @@
   
   br
   div align="center"hr width="75%"font size="2"
  -$Id: classloaders.html,v 1.5 2001/02/23 02:32:20 glenn Exp $
  +$Id: classloaders.html,v 1.6 2001/03/27 01:54:19 craigmcc Exp $
   /font/div
   
   /body
  
  
  
  1.14  +64 -58
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- Bootstrap.java2001/03/06 01:42:55 1.13
  +++ Bootstrap.java2001/03/27 01:54:20 1.14
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 

Re: Cause found [was Re: How do I use a non-apache naming service with tomcat 4?]

[T. Park]

Hi Remy,

I'm running  tomcat 4 beta 1.

I'll download tonight's latest build and see how I fare with that.

Thanks so much for the support!

-Thom

p.s. is there a b2 drop in the near future - I'm trying to focus my
integration efforts on the nearest milestone build.


Remy Maucherat wrote:

  Guys,
 
  I've isolated the cause of the problem down to the inclusion of the
 javax.naming
  package in my 'big everything' jar.
  If I remove the javax.naming package from the jar file, then all works
 well, if
  not, we get that wierd 'signature' problem with createNamingContext.
  (with or without enabling naming).
 
 
  Would it seem reasonable not to load naming support jars if tomcat isn't
 going
  to be running a [native] naming service?

 Which version of TC 4 are you using ?
 I believe the latest nightly builds could fix those problems.

  My problem here is I have a naming service I want to use and is packaged
 with
  the corresponding javax.naming package that it is based on
 
  the problem is that I'm unable (by default) to control what jndi stuff
 get's
  stuffed on the classpath of tomcat
 
  I'm unable to swap these (the naming support jars) around as tomcat's
 stuff
  seems to have been compiled against a different rev of the javax.naming
  stuff.
 
 
  So - Do you know what version of javax.naming is in tomcat 4's jndi.jar?

 It's the same as yours, but loaded by a different classloader, so it's not
 compatible anyway.

 Remy

--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html

Re: Multi-byte character support.

[Kazuhiro Kazama]

Thom,

From: "T. Park" [EMAIL PROTECTED]
Subject: Multi-byte character support.
Date: Mon, 26 Mar 2001 10:32:31 -0800
Message-ID: [EMAIL PROTECTED]
 Tomcat 3.2[.1] doesn't seem to like static html pages (or servlets for
 that matter) that offer multi-byte (non-latin) characters.

Tomcat 3.2.2b2 has many i18n improvements. Would you use and check
3.2.2b3 if possible?

Of cource, a few i18n problem (for example, ServletRequest#getProperty
method don't return value in Unicode) isn't resolved in 3.2.2. But
they will resolve them in 3.3  4.0.

Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[Jestin Jean-Francois]

Hello,
I agree the idea of the pushlet is a bit confusing because it uses http (a non real 
time protocol) to do pseudo real-time job, 
but real-time is always more "hungry" than other technology (think about streaming !! 
).
On the other hand having pseudo real-time monitoring over standard http is also very 
interesting !
It's look like another dilemma ;-)
But
BTW, I'll see where the problem could be in mod_jk ;-)
Could you give me more information about the problem ?

Thank you very much



 -Original Message-
 From: GOMEZ Henri [SMTP:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 6:10 PM
 To:   [EMAIL PROTECTED]
 Subject:  RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
 
 Hi,
 
 I take a look at pushlet and find it very bad design.
 
 Using opened http connections to do real-time job is
 not realist.
 
 In that case you keep an :
 
 - one OS (job/thread)
 - one ajp13 connection
 - one tomcat thread.
 
 Imagine if you got  256 concurrents connexions !
 
 A better alternative will be to use a custom made network
 protocol.
 
 BTW, I'll see where the problem could be in mod_jk ;-)
 
 
 "Entre truands, les b nfices, a se partage, la rclusion, a
 s'additionne."
 -- Michel Audiard
  
 
 -Original Message-
 From: Jestin Jean-Francois 
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 26, 2001 5:34 PM
 To: '[EMAIL PROTECTED]'
 Subject: RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
 
 
 here are 2 articles speaking about the pushlet
 
 http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html
 
 http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet-2.html
 
 here is a very simple sample pushlet :
 
 
 import javax.servlet.*;
 import javax.servlet.http.*;
 import java.io.*;
 
 public class SimplePushlet extends HttpServlet
 {
 public void doGet(HttpServletRequest request, 
 HttpServletResponse response)  throws ServletException, IOException {
 
 ObjectOutputStream out = new ObjectOutputStream 
 (response.getOutputStream());
 response.setContentType("text/plain");   
 
 String start = "Http connection opened";
 
 out.write(start.getBytes());
 out.flush();

 try {
 for (int cnt=1; cnt  0; cnt++) {
 Thread.sleep(1000);
 
 String iter = "event=" + cnt + "\n";
 out.write(iter.getBytes());
 out.flush();
 System.out.println("event=" + cnt + "pushed.\n");
 }
 } catch (Exception e) {
 System.out.println("error:"+e);
 }
 
 out.close();
 }
 }
 
 You may use netscape as browser or ie if you don't care about 
 waiting 15 pushes.
 
 Thank you for your help.
 
 
 
 
 
 
 
  -Original Message-
  From: Jestin Jean-Francois 
  [mailto:[EMAIL PROTECTED]]
  Sent: Monday, March 26, 2001 4:01 PM
  To: '[EMAIL PROTECTED]'; 
 '[EMAIL PROTECTED]'
  Subject: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
  
  
  Hello,
  
  I'm currently using apache 1.3.12(mod_jk) and tomcat 3.3-m2 
  under solaris 2.6 talking ajp13
  
  Everything works fine except that I encounter sometime an 
  Internal Server Error if I don't restart Apache each time I 
  restart tomcat. Is there a fix for that problem ?
  
  On the other hand I use a server push mechanism (called 
  pushlet) - that's why I use milestone build of 3.3 (not 
  working under 3.2.1)- it works also fine (what a beautiful 
  life !) except that sometime (!!??) the servlet (pushlet)  
  doesn't detect the end of the connection (Browser killed) 
  between tomcat and apache
  
  looking at the mod_jk log gives the following :
  
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
  jk_tcp_socket_recvfull failed
  [jk_ajp13_worker.c (623)]: Error reading request
  [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - 
  jk_tcp_socket_recvfull failed
  [jk_ajp13_worker.c (623)]: Error reading request
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  [jk_ajp13_worker.c (325)]: Error ajp13_process_callback - 
 write failed
  
  Is there also a fix for that or these problems ?
  
  Thank you very for your answer and your great job !
  
  
  
  Jean-Fran ois JESTIN
  
  
  
  
 

RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??

[GOMEZ Henri]

I agree the idea of the pushlet is a bit confusing because it 
uses http (a non real time protocol) to do pseudo real-time job, 
but real-time is always more "hungry" than other technology 
(think about streaming !! ).

On the other hand having pseudo real-time monitoring over 
standard http is also very interesting !
It's look like another dilemma ;-)
But
BTW, I'll see where the problem could be in mod_jk ;-)
Could you give me more information about the problem ?

Argh, damn't english, I wanted to say I'll looking for where
the problem could be in mod_jk. But as you know Apache add
also timeout to requests

more log in mod_jk

[GOMEZ Henri]

Here is the patch I'll commit if there is 
no objection



 jk_util.patch